Skip to content
QES · worked example

The sensor that worked half the time

How one “loose cable” call became a supplier CAPA, and how each QES stage moved it forward. Read the strip below for the whole story in ten seconds; open any stage for the detail.

The lifecycle at a glance

Every QES event passes through the same five steps. Each step answers one question before the event moves on.

Why the first ticket matters

The first event was “solved” in a phone call. Whether it became a QES ticket decided whether anyone would ever see the pattern.

~90%

of field events like this one are never logged. They end as an email: “swapped the cable, all good.”

Email only pattern invisible

Call→Cable swapped→“Fixed” email→Inbox

The second site looks like a brand-new problem. Three good cables get scrapped. Nobody connects the two events, and more faulty sensors keep shipping.

QES ticket pattern found

Call→Cable swapped→QES ticket→Triage links events

The second ticket lands next to the first. The QMS manager sees the same symptom twice and asks why the “failed” cables work everywhere else.

The setup in the field

Two cables, two connections. The symptom: the sensor does not connect to the device.

PCblue cableDeviceworksred cableSensorreal fault: USB-C solder joint
PC to deviceDevice to sensor (the one being swapped)Where the fault actually was

Stage by stage

Left: what happened in this example. Right: what QES holds at the end of the stage. The diamond is the decision that moves the event on.

1

Report

Support · Sales rep

What happened, where, and what did we try?

In the example
  • Site A. Sales rep calls support: the sensor won’t connect. Support says swap the red cable. It works. Recorded as a cable issue and a QES ticket is raised.
  • Site B, later. Same symptom. Swap cable: still no connection. Second cable: no. Third: no. Fourth: works.
  • Three cables reported as failed, yet those cables work fine elsewhere. Support raises a second QES ticket.
QES holds
Ticket ASymptom, site, action (cable swap), result
Ticket BSame symptom, 3 cables “failed”, 4th worked
OriginField feedback (complaint). Fixed, never changes
Was it fixed on the call?
Log it anyway → TriageEmail and forget

In your work: raise the ticket even when the fix worked. A solved problem is still data.

2

Triage

QMS manager

Is this a one-off or a pattern, and is it reportable?

In the example
  • The QMS manager reviews incoming events and sees Tickets A and B side by side.
  • Same symptom, same “fix”, at two sites. And “bad” cables that are not bad. Something is off, but it is not yet clear what.
  • Reportability: not an adverse event, with the reason recorded. Nothing to report to the authorities; revisited if the investigation finds more.
  • Suspected type: deviation. The cables don’t explain it, so something in the product or process is likely off.
QES holds
LinkTickets A + B grouped as one event
NoteTriage reason: cable cause doesn’t add up
ReportableNo, not an adverse event + rationale
TypeSuspected: deviation
Isolated, or does it need a closer look?
Closer look → InvestigateIsolated → close
Adverse event?
Yes → vigilance reportingNo → deviation

In your work: look for repeats; two similar tickets are the strongest signal QES can give you. Decide reportability now: if it is a serious incident, the reporting clock is already running. Mark the type as suspected; Assign confirms it.

3

Investigate

QMS manager · Engineering

How far does it go, how risky is it, and what is the root cause?

In the example
  • Quick assessment: the problem is bigger than cables. Risk assessment judged not required, and that decision is documented with its reason.
  • A test task is issued. Testing shows the sensor’s USB-C connector is badly soldered to the PCB. Plug the cable in one way: works. Flip it: fails.
  • That is a 50/50 chance on every plug-in. It also explains Site B: each “new cable” was really a new coin toss. The fourth happened to go in the right way up.
  • Engineering test SOPs reviewed. Root cause: insufficient solder paste on one side of the connector during chip install at the supplier.
QES holds
AssessmentInitial scope: beyond cables
Risk“Not required” + documented rationale
TaskTest cables, devices and sensors
Root causeSolder paste, one side of USB-C
SOP reviewFinal test missed orientation
Try it: the 50/50 connectorCable up: connected
Risk assessment needed?
No, reason recordedYes → risk file
Root cause proven?
Yes → AssignNo → more testing

In your work: “not required” is a valid answer only when the reason is written down. Then keep asking why until the answer is a process step you can change, not just a broken part.

4

Assign

QMS manager → Factory · Supplier · Production

What do we change, and who owns each action?

In the example
  • Type confirmed: deviation, matching the suspected type from triage. A deviation needs a full CAPA, so the CAPA is opened and each action gets an owner.
  • Supplier: supplier issue raised to correct the solder paste process at chip install.
  • Factory: replace the faulty sensors at the affected sites.
  • Production: rewrite the production SOPs and add a cable-flip check to final test, and train the testers.
QES holds
TypeConfirmed: deviation (suspected: deviation)
CAPAOpened, owned by Factory + team
SupplierSupplier issue → supplier
CorrectionReplacement sensors → Factory
SOPProduction + final test → Production
TrainingTester training → Production
Confirmed type?
Deviation → CAPAChange request → CRNonconformity → NCFeedback only → close
Every action has an owner?
Yes → TrackNo → assign

In your work: confirm the type before you assign; it decides the path. If it differs from triage, record why. Then give every action a name and a due date: an action without an owner is a wish.

5

Track & Outcome

QMS manager · Production

Is each action done, and did it work?

In the example
  • Each action is tracked while the fix is in progress, through to its outcome.
  • Replacement sensors shipped to affected sites (luckily only a few units).
  • Production SOPs rewritten. Final test now includes flipping the cable, so both orientations are checked; testers trained.
  • Effectiveness checked, then the CAPA is closed with evidence.
QES holds
CorrectionReplacement units shipped
SOPProduction + final test revised
TrainingTesters trained on flip test
ClosureCAPA closed with evidence
Actions done and effective?
Yes → close eventNo → reopen CAPA

In your work: an event closes on evidence, not on a promise. Attach the SOP version and training records.

Use this for your own events

The same five steps apply to any QES event, whether it starts in the field, on the production line or in an audit.

StageQuestionIn this exampleMoves on when
1 · ReportWhat happened?Two tickets: “cable issue”Ticket raised with symptom, action and result
2 · TriagePattern? Reportable? Likely type?Tickets linked; not an adverse event; suspected type: deviationLinked, reportability decided, type suspected
3 · InvestigateHow far? How risky? Why?Risk assessment not required (documented); solder paste on USB-C; final-test gapRisk decision recorded, root cause proven
4 · AssignWhich path? Who owns it?Type confirmed: deviation → CAPA with supplier, Factory, Production actionsType confirmed, every action has an owner
5 · Track & OutcomeDone? Did it work?New sensors, new SOPs, flip test in trainingActions done, effective, evidence attached

Worked example for training. Names, sites and ticket details are illustrative.