A Process Broke Down: Find the Failure Point Decision Tree

Why this matters

A job went sideways. The customer is upset, the tech is frustrated, and the easy move is to blame the last person who touched it. That blame is almost always wrong, and worse, it teaches you nothing, so the same break happens next week to a different job. The job that fails is rarely failed by the person standing over the wreck. It was set up to fail three steps earlier by a handoff that dropped something.

Finding the actual failure point - the step where the right information or material first went missing - is what lets you fix the process instead of punishing a person. This tree walks you there.

Start here: map the job as a chain of handoffs

Every job is a relay. Information and materials get passed from station to station, and a drop at any baton-pass breaks the whole run. A typical chain:

Lead comes in - intake captures it - estimate built - job scheduled - dispatched - tech does work - invoiced - paid.

Write your version of that chain on paper. You cannot find where it broke until you can see the whole track. Most shops have never drawn this, which is exactly why the same handoff keeps dropping.

Find the last good baton-pass

Walk the chain forward and ask at each handoff: did the next station get everything it needed, correct and on time?

• If yes: that handoff held. Move to the next one.
• If no: stop. You found the break, or you found a station that was already missing something handed to it. Keep tracing back until you reach the first station that received bad or missing information. That is the failure point.

The point is to find the first drop, not the last symptom. A wrong quote at the customer's door (last station) often traces to equipment details never captured at intake (first station). Fixing the tech's behavior does nothing; the intake form was the break.

Classify the failure type

Once you have the failing station, name what kind of break it was. The fix depends entirely on the type.

• Information drop. A fact existed but did not travel. The age of the unit, the gate code, the agreed price. Fix: make the field required at capture, and make it visible at the next station.
• No-owner gap. The step belonged to nobody, so everybody assumed someone else had it. Fix: assign one named owner.
• Skill or knowledge gap. The owner had the info but did not know what to do with it. Fix: training or a checklist, not a process change.
• Capacity gap. The owner knew what to do but had no time to do it. Fix: this is a workload problem, not a process problem. Do not solve it with another checklist.
• Tool gap. The system made the right action hard or impossible. Fix: change the tool or the form, not the person.

Misclassifying here is the most common mistake. A capacity gap dressed up as a "training issue" leads to retraining a person who was never confused, only buried.

The blame trap

When a job breaks, the reflex is to find who to blame. Resist it for a hard, practical reason: blame stops the investigation. The moment you name a culprit, everyone relaxes, the real failure point stays hidden, and it fires again.

Replace "who messed up" with "where did the chain drop the baton, and why was it possible to drop it there." A good process makes the right action the easy action and the wrong action hard. If a single person's mistake could sink the job with no guardrail, the process failed before the person did.

Decide the fix at the failure point only

You found the break, you classified it. Now fix that station and no other. The temptation is to add controls everywhere out of fear; that buries the team in checklists and slows every job to prevent a rare one.

• One failure point gets one targeted change.
• The change goes into the written workflow, not into a memo nobody reads.
• It gets one owner and one check (a required field, a number, a flag).

Then verify. Run a few jobs through the changed handoff and confirm the baton holds. If it drops again, you fixed the wrong station - go back and trace further upstream.

Close the loop

A process fix is not done when you make it; it is done when it survives without you watching. Set a short follow-up: in two weeks, did this break recur? Recurrence means the real failure point was further up the chain than you thought. No recurrence means the handoff is repaired, and you can take that worry off your plate for good.

References

• See related: The Recurring Firefight - Root Cause vs Bandaid Decision Tree
• See related: Daily, Weekly, Monthly, Quarterly Operating Cadence
• Value-stream mapping, standard lean operations practice for tracing handoffs
• "Five whys" root-cause analysis, trade-standard continuous-improvement method