The Recurring Firefight: Root Cause vs Bandaid Decision Tree
Why this matters
Most small shops do not have a workload problem. They have a same-problem-every-week problem. The callback that keeps coming back, the truck that is never stocked, the customer who is always surprised by the bill. Each one feels like a one-off you can put out fast, so you do, and it comes back. A firefight you solve once is work. A firefight you solve every week is a tax on the whole business, and you are paying it in lost evenings.
The skill is telling apart a true one-off from a recurring pattern, then refusing to bandaid the recurring one. This tree gives you that decision.
Start here: is this actually recurring?
Before you spend energy fixing anything, answer one question: have I handled a version of this in the last 90 days?
- If no, and you cannot recall another like it: it is probably a genuine one-off. Handle it, move on, do not build a system around a single event. Over-systemizing one-offs is its own waste.
- If yes, or you are not sure: treat it as a candidate pattern and keep going. Uncertainty here usually means yes; memory blurs the repeats together.
A fast way to check: ask your office person or lead tech "does this happen a lot?" The front line knows the repeat offenders even when the owner does not, because they live them daily.
Name the pattern in one sentence
Write the recurring problem as a plain sentence with a trigger and a result. "When we schedule a same-day add-on, the tech shows up without the right part." "When a new customer calls, nobody captures the equipment age, so the quote is wrong."
If you cannot write it in one sentence, you have not found the pattern yet, you have found a cluster of symptoms. Split it. Vague problems get vague fixes that do not hold.
Trace it to the failure point
Walk the job backward from where it blew up to where it actually went wrong. These are usually different places.
- The tech arrived unprepared. That is the symptom. Where did the prep fail? Was the part not on the truck (stocking), not on the work order (intake), or not known to be needed (diagnosis)?
- The customer was surprised by the price. Symptom. Did the quote miss scope (estimating), or did the office quote one number and the tech change it (handoff)?
- The job ran long and blew the next appointment. Symptom. Was it under-scoped at booking, or did the tech hit something nobody checked for?
Keep asking "what happened just before that?" until you reach a step a person owns. That step is the root cause. It is almost never the last person who touched the job.
Bandaid vs root-cause fix
Once you have the failure point, you have two roads.
| Bandaid | Root-cause fix | |
|---|---|---|
| What it does | Patches this instance | Changes the step so it cannot fail the same way |
| Effort now | Minutes | Hours to days |
| Effort later | You pay it again every time | Paid once |
| Example | Drive the part out to the tech | Add a stocking-check step to dispatch |
| When it is right | True one-off, or buying time | Confirmed recurring pattern |
The trap is that the bandaid always looks cheaper in the moment, because the recurring cost is spread out and invisible. Add it up. A ten-minute bandaid you do twice a week is over a full work-day a year, and it never ends.
Decision: if the pattern is confirmed recurring, you are not allowed to only bandaid it. Bandaid this instance to keep the customer happy, then schedule the root-cause fix as real work.
Make the fix stick
A root-cause fix that lives in your head is still a bandaid. To make it hold, the changed step needs three things:
- A written change to the actual workflow. A checklist line, a required field, a script. Something a new hire would follow without you.
- An owner. One named person responsible for the step going forward, not "the team."
- A check. Some way you would notice if it stopped working. A field that is now required, a number you watch, a tech who flags it.
Then close the loop: in 30 days, did the firefight come back? If yes, your fix missed the real root cause; go back to the trace step. If no, you just bought back an hour a week, permanently.
References
- See related: Process Broke Down - Find the Failure Point Decision Tree
- See related: Systemize vs Hire vs Tolerate the Bottleneck Decision Matrix
- The "five whys" root-cause method, standard lean and continuous-improvement practice
- Plan-Do-Check-Act improvement cycle, trade-standard operational practice