The Five Whys on a Service Call
Why this matters
A blown fuse, a tripped float, a failed part - fix only that and you will be back next week for the same call, because you treated the symptom and left the cause. The Five Whys is a borrowed-from-manufacturing habit: keep asking "why did that happen?" until you reach the thing that, if you fix it, stops the failure from coming back. It turns a parts-swap tech into a problem-solver, kills repeat callbacks, and protects the customer from paying twice. It costs you a few minutes of thinking and saves you a return trip.
The principle: symptom is not cause
Most failures are the last domino in a chain. The part that died is rarely the part that started it. A motor that burned out did not decide to burn out; something made it. If you replace the motor and leave the something, you have bought yourself a callback. The Five Whys walks the chain backward, one "why" at a time, until you reach a cause you can actually remove.
The "five" is a guideline, not a rule. Some chains stop at two, some run to six. You stop when the next "why" leaves your scope or when you have reached a cause whose fix prevents recurrence.
How to run it
Start at the symptom the customer reported and walk back:
- State the failure plainly. "The equipment shut off." Not "it's broken" - be specific about what was observed.
- Ask why that happened and answer with a fact you can verify, not a guess. "It shut off because a safety control opened."
- Ask why again of that answer. "The safety control opened because a value went out of range."
- Keep going. "The value went out of range because flow was restricted." "Flow was restricted because a filter was clogged." "The filter was clogged because it had not been serviced on schedule."
- Stop at an actionable root cause. Here it is the missed maintenance, not the safety control that did its job correctly.
Each answer must be evidence-backed. If you cannot verify a link, you have a hypothesis to test, not a conclusion.
A worked example
Symptom: a pump is not delivering.
- Why? The motor is not running.
- Why? Its overload tripped.
- Why? The motor was drawing too much current.
- Why? The mechanical load was too high - the shaft was binding.
- Why? A bearing failed from lack of lubrication.
Fix the motor only and the new motor meets the same binding shaft and trips again. The root cause is the bearing and the lubrication practice. Address that and the failure stops returning. Same logic applies to a tripping breaker, a leaking fitting, a fault code that keeps coming back: the first failure you see is almost never the first failure that happened.
Where it goes wrong
Run it badly and it misleads you. Watch for these:
- Stopping at "the part failed." A part failing is a symptom of why it failed. Keep going.
- Answering with blame instead of mechanism. "Because the customer abused it" is not a diagnosis unless you can show the specific mechanism and prevent it.
- Guessing the links. Each step must be something you observed or measured. An unverified chain is a story, not a root cause.
- Going past your scope into noise. "Why was the filter not serviced? Because the maintenance plan lapsed. Why did it lapse?" - at some point you have reached the cause you can act on. Hand the rest to the customer as a recommendation.
When a single root is not the whole story
Some failures have more than one contributing cause, and chasing a single line misses them. If your chain does not fully explain the failure, branch: ask "what else had to be true for this to happen?" A motor failure might trace to both a lubrication gap and an environmental contamination path. Real diagnosis sometimes needs two threads pulled, not one.
The payoff is the same either way. You leave having fixed the thing that brought you out and the thing that would have brought you back. That is the difference between a repair and a fix.
References
- Root-cause-analysis and Five Whys method (lean/manufacturing problem-solving practice)
- Reliability-centered-maintenance principles on failure modes and causes
- Manufacturer failure-mode and service documentation for the equipment class
- See related: Power Present but Nothing Happens, and Is This Safe to Leave Running