Trust the Data or the Story: A Decision Tree
Why this matters
Every service call gives you two inputs: the customer's story and your own measurements. They usually agree. When they don't, picking the wrong one sends you down a long wrong road. The customer isn't lying, but they're describing what they noticed, not what happened. Your meter doesn't lie, but a single reading taken at the wrong moment can mislead you too. This tree helps you weigh both without trusting either blindly.
Start here: gather both, commit to neither
Before you decide anything, get the story and one solid reading. Ask the customer what they saw, when it started, what changed recently, and whether it's constant or intermittent. Then take a baseline measurement of the system in its current state. Now you have something to compare.
The rule of thumb: the story tells you where to look; the data tells you what's true. Use the story to aim your tests. Use the data to make the call.
If the data and the story agree
Easy case, but don't get lazy. Agreement makes a cause likely, not certain. Confirm with a second independent check before you commit parts or labor. If the customer says "no heat" and your reading confirms the heating element is open, verify power is reaching it before you condemn the element. Agreement just means you can move faster, not skip steps.
If the data and the story disagree
This is where the tree earns its keep. Work these branches in order.
First, question your own reading.
- Did you measure at the right point, in the right mode, at the right moment? An intermittent fault reads normal when it isn't acting up.
- Is your meter set up correctly and reading a known-good reference? A meter that's lying makes the story look wrong when it isn't.
- Did you reproduce the condition the customer described, or measure a system sitting idle? Many faults only show under load, on a call, or at temperature.
If any of these is shaky, re-measure under the conditions the customer described before you doubt them.
Second, question the story for translation error.
- The customer describes effect, not cause. "It's leaking" might be condensation, not a leak. "It's making noise" might be normal operation they never noticed.
- Timing gets compressed. "It just started" often means "I just noticed." Ask what they were doing when they first saw it.
- "It's never worked right" points at install or sizing, not a recent failure. Treat it as a different problem class.
Third, look for the intermittent fault that explains both.
Often nobody is wrong. The customer saw a real failure; your meter sees a healthy system; the truth is an intermittent fault that comes and goes. A loose connection that's making contact right now reads fine. A component that fails only when hot tests good when cool. When the story and data conflict and both seem honest, suspect intermittence and try to reproduce the trigger: run the system to temperature, wiggle-test connections (after confirming it's safe to touch, see the energized-work rules), cycle it repeatedly.
Decision summary
| Situation | Trust | Next move |
|---|---|---|
| Story and data agree | Both, with one confirming check | Verify upstream cause, then fix |
| Data clean, story vague | Data | Re-question customer to pin timing/trigger |
| Data suspect, story specific | Story | Re-measure under described conditions |
| Both honest, both conflict | Neither yet | Hunt the intermittent fault that explains both |
| Data normal, fault not reproducing | Story | Document, set conditions to catch it, plan follow-up |
When you genuinely can't reproduce it
A no-fault-found visit is a real outcome, not a failure on your part, but handle it honestly. Don't replace a part to "do something." Document the customer's exact account, what you measured, and the conditions you couldn't recreate. Tell them plainly what would help next time (note the time and conditions when it recurs). A guessed part swap on an unreproduced fault is the too-simple trap wearing a different hat.
The bias to watch in yourself
Experienced techs over-trust their first reading; newer techs over-trust the customer. Know which way you lean and correct for it. The discipline is the same either way: let the story aim you, let the data decide, and respect an intermittent fault enough to chase it before you blame anyone.
References
- Trade-standard troubleshooting methodology (observe, isolate, test, verify).
- Manufacturer diagnostic flowcharts and service documentation (generic).
- OSHA safe-work practices for live and energized equipment.
- See related: The Too-Simple and Too-Complex Trap; The Diagnosis That Doesn't Add Up Decision Tree.