When the Cheap Fix and the Right Fix Differ: Decision Tree
Why this matters
Some calls hand you a fork: there is a fast, low-cost patch that gets the equipment running today, and a more involved fix that actually removes the cause. Take the patch and call it solved, and you own the callback when it fails again. Sell the full fix when the patch was genuinely enough, and you look like the tech who upsells everything. The skill is telling the two apart on site, then being straight with the customer about which one you are recommending and why.
Start here: is the cheap fix a real fix or a reset?
Before anything, sort what the patch actually does.
- It removes the cause (replacing the worn part that failed): cheap and right are the same thing. Do it, no dilemma.
- It restores function but leaves the cause (swapping the part the cause destroyed, while the source keeps running): this is the fork. The patch buys time; it does not fix the problem.
- It only hides the symptom (clearing a fault, bleeding a system, topping up a consumable that keeps disappearing): this is not a fix at all. See the related reset-that-masks tree.
You only have a genuine cheap-vs-right decision in the middle case. Name which one you are in first.
The root-cause test
The cheap fix is the wrong fix when it leaves a cause that will take out the new part. Ask: what killed the part I am about to replace?
- A component that failed from normal age and wear: the swap is the right fix. Nothing upstream is hunting the new one.
- A component that failed because something else overstressed it (overheating, overpressure, a bad upstream part, an installation error, contamination): the swap alone is the cheap fix. The new part inherits the same killer.
When the failed part is a victim, not the culprit, the cheap fix has a clock on it.
When the cheap fix is the right call
Patching is legitimate, not a sin, in clear cases. Recommend the patch when:
- The cause is age and the rest of the system has real life left.
- The customer has a budget ceiling today and the patch is safe and disclosed (a stopgap they chose with eyes open).
- The equipment is near end of life and the right fix would be money sunk into a unit on its way out.
- The full fix needs a part, a permit, or a return trip you cannot do now, and the patch holds safely until then.
A disclosed, safe stopgap that the customer chose is good work. The failure is the undisclosed one you let them believe was permanent.
When only the right fix is honest
Push past the patch when the patch is unsafe or sets up a worse failure.
- The cause is a hazard (a gas, water-plus-electricity, overpressure, or overheating condition). Lead with the safety action, then the real fix. Do not patch a hazard.
- The new part will fail fast and visibly, turning one trip into three.
- The patch masks a fault that grows (see the fault-that-comes-back-bigger tree).
Lay it out for the customer
Whichever way you lean, give them the choice in plain terms.
| Cheap fix | Right fix | |
|---|---|---|
| What it does | Restores function now | Removes the cause |
| Holds for | Weeks to a season | Until normal wear |
| Risk | Cause keeps running | None added |
| Best when | Tight budget, unit near end | Cause will kill the new part |
Say it straight: "I can get this running today for less, but the thing that broke it is still here and it will be back. Or we fix the cause and it stays fixed. Here is what each costs and how long each lasts." Document which one they picked and that you disclosed the trade-off. That note is what protects you on the callback.
The recap
- Decide what the patch does: removes cause, leaves cause, or hides symptom.
- Ask what killed the part. Victim part means the patch has a clock.
- Never patch a hazard. Safety action first, then the real fix.
- Patch is fine when disclosed, safe, and chosen, on aging or budget-capped units.
- Give the customer both options in plain language and write down their choice.
References
- Trade-standard practice for root-cause repair vs symptomatic repair
- Manufacturer documentation on component failure modes and contributing causes
- See related: The Reset That Masks the Problem (decision tree); The Fault That Comes Back Bigger (decision tree); Fix Now or Replace Soon on an Aging System (decision tree)