Trust the Customer's Story or Not: Decision Tree

Why this matters

The customer's account of the problem is your richest diagnostic clue and your most misleading one, often at the same time. They were there when it happened and you were not, so their story holds details you cannot get any other way. But they are describing it without the vocabulary or the framework a tech has, so the words rarely map cleanly onto a fault. Take the story as literal fact and you chase the wrong part; dismiss it entirely and you throw away the only witness to an intermittent failure. The skill is knowing which parts of an account to trust as observation, which to treat as interpretation, and when to verify before you act on any of it.

Start here: separate observation from interpretation

Every customer story is a mix of two things, and they have very different reliability. An observation is what they sensed: a noise, a smell, water on the floor, the time of day, what else was running. An interpretation is their guess at the cause: "I think it's the motor," "it's probably the wiring." The observations are usually trustworthy. The interpretations are usually not, and acting on a customer's cause-guess as if it were a diagnosis is a classic error.

If the customer is reporting what they sensed, weight it heavily; it is witness testimony you cannot reproduce.

If the customer is reporting what they think caused it, treat it as a hypothesis to test, not a finding. Their guess may be right, but it has to earn it like any other.

Check whether the story is consistent

A reliable account holds together; a shaky one contradicts itself. Listen for internal consistency across the details.

If the timeline, the symptom, and the conditions all fit one coherent picture, the story is more trustworthy and a good basis to start from.

If the details contradict each other or shift as they retell it ("it only does it in the morning" then "actually it did it last night too"), the story is uncertain. Use it to generate candidates, but confirm the actual behavior yourself before committing.

Check whether trusting it is cheap or expensive

How much you need to verify depends on what acting on the story costs. A story is safe to act on directly when being wrong is cheap and reversible.

If following the story leads to a quick, cheap, reversible check, just do it. Verifying first would waste more time than the occasional miss.

If following the story leads to an expensive part, a destructive teardown, or an irreversible step, verify the symptom independently before you commit, even if the story seems solid. The cost of acting on a misread account is too high to skip confirmation.

Watch for the accounts that mislead

Some story types are known to point wrong even when the customer is being honest. Recognize them:

• "It worked yesterday." Often means "I noticed it yesterday," not that anything changed overnight. A slow degradation gets reported as a sudden event.
• "It only does it sometimes." The "sometimes" usually hides a condition (heat, load, time, another appliance running) the customer has not connected. Mine for the trigger rather than accepting randomness.
• "The last guy broke it." May be true, may be a coincidence of timing. Verify the actual fault before assigning a cause to prior work.
• "I already fixed part of it." A customer who attempted a repair may have changed the system; the current symptom may be partly their doing.

If you hear one of these, do not reject it, but do not take it literally either. Translate it into a testable condition and confirm.

The honesty question

Most customers are honest, but a few accounts are shaped by what the customer wants the outcome to be: a warranty claim, an insurance angle, a desire not to admit they caused it.

If the story conveniently supports a claim and the physical evidence does not match it, trust the evidence over the account. The part's condition, the readings, and the visible signs are not motivated; the story might be.

If nothing suggests a motive and the evidence is consistent with the account, treat it as honest, which is the normal case.

The decision

Trust the observations, test the interpretations. Act on the story directly when the verification cost is low and the account is consistent. Verify the symptom yourself before committing when the path is expensive or irreversible, when the story contradicts itself, when it is one of the known misleading patterns, or when the physical evidence disagrees with the account. When you cannot reproduce what the customer described, do not call them wrong; the fault may simply be absent right now. Document what they reported and that you could not confirm it, and treat the next occurrence as the diagnostic opportunity.

What to document

Record the customer's account in their own words, separating what they observed from what they guessed. Note which parts you verified and how, and where the physical evidence agreed or disagreed with the story. If you acted on the account without independent confirmation because the check was cheap, say so. This record protects you if the diagnosis is later questioned and helps the next tech read the same customer faster.

References

• FTC, "Auto Repair Basics" (model for translating a customer complaint into a verified diagnosis).
• Electronics Technicians Association International (ETA), customer-interview and symptom-verification practice.
• See related: It Worked but You Don't Know Why Decision Tree; Recreating the Conditions to Find the Fault; The Obvious Cause Is Wrong Decision Tree.