The Customer Can't Reproduce It: Decision Tree

Why this matters

There is a fault, but nobody can make it happen on command, not even the customer who reported it. This is the hardest version of the intermittent call, because you have lost your best tool: a person who can show you the failure. Handled badly, it ends in a part swapped on a guess and a customer who feels brushed off. Handled well, it becomes a structured hunt that either corners the real fault or honestly identifies that the cause was a one-off the customer created. The skill is to extract a usable pattern from a customer who cannot reproduce the problem, and to know when "cannot reproduce" actually means "it was never the equipment."

Safety first if the report involves a hazard

If the original complaint named a hazard, do not let "cannot reproduce" lower your guard.

• Reported shock, arcing, burning, or a trip: treat the hazard as real and inspect for evidence before energizing and probing. An intermittent hazard that hides is still a hazard.
• Reported gas, fuel, or fume: verify with proper method; do not dismiss because nobody can recreate the smell.

Clear a reported hazard with evidence, never with the absence of a repeat.

Start here: separate "cannot reproduce" from "was never the equipment"

These are two different situations and they need different handling.

• A real intermittent that neither of you can trigger on demand: the fault is in the equipment, it just hides. You corner it with method.
• A customer-induced or one-off event that looks like an equipment fault: a tripped protection from an overload that has since cleared, a setting someone bumped, an external condition that came and went. The equipment is fine; the cause was outside it.

You decide which by gathering the pattern and reading the evidence below. Do not assume either one at the door.

Pull the pattern out of the customer

A customer who "cannot reproduce it" usually still holds the pattern; they just have not been asked the right way. Replace "can you make it happen" with specifics.

• "When was the last time it happened?" A concrete instance is easier to dissect than a general complaint.
• "What were you doing right before?" Often the trigger is an action they do not connect to the fault.
• "What time, what weather, how long had it been running?" Conditions they did not think mattered.
• "What did you do that made it stop?" Their fix often names the cause. If cycling power fixed it, that points one way; if waiting fixed it, another.
• "Has anything changed recently?" New load added, a setting touched, work done by someone else, a change in how it is used.

Write the answers as conditions. You are assembling the failure recipe even though they cannot cook it on demand.

Read the evidence the event left

The fault hides, but it likely left a trace. This often settles the equipment-versus-not question.

• A stored fault or a tripped protection tells you the equipment caught the event. That is a real intermittent to chase.
• No evidence at all, anywhere, after a thorough look, leans toward a one-off external cause, especially if the customer's "fix" was simply resetting it.
• Signs of an overload or misuse (a protection that did exactly its job under a condition that has passed) point to customer-induced, not a defect.
• Heat marks, corrosion, or movement witness point back at a genuine equipment fault.

If the evidence shows the equipment caught and held a fault, treat it as a real intermittent and corner it. If there is no equipment evidence and the cause looks external, your job shifts to explaining and preventing, not replacing.

If it is a real intermittent: corner it

Use the methods built for this. Do not guess-and-swap.

• Recreate the failure conditions on purpose from the recipe you built, watching a live reading. See related: Catching the Fault That Hides When You Arrive.
• Leave a witness or a logger so the unit reports the next event while you are gone. See related: The Witness Mark or Data Logger Method.
• Fix the evidenced probable cause and name it honestly as probable, with a follow-up.

If it was customer-induced or a one-off: explain and prevent

When the equipment is fine and the cause was external, the fix is information, not parts.

• Explain what happened in plain terms: a protection did its job, a setting got bumped, an external condition tripped it. Naming it builds trust, not blame.
• Show them how to avoid the trigger or what to do if it recurs.
• Do not invent a repair to justify the trip charge. A clear explanation of a customer-induced event is honest work. A part swapped to look busy is a future callback and a credibility loss.
• Set the line for calling back: if it happens again under different conditions, that changes the picture and is worth another look.

Recap: pattern, evidence, then the right path

1. Treat any reported hazard as real until evidence clears it.
2. Decide: real intermittent, or customer-induced one-off.
3. Pull the pattern from the customer with specific questions, not "reproduce it."
4. Read the evidence the event left; equipment evidence means real fault, none plus an external cause means one-off.
5. Real intermittent: corner it with recreation and logging. One-off: explain and prevent, do not invent a repair.

The rule to bank: "the customer cannot reproduce it" is a starting condition, not a conclusion. Find the pattern, read the evidence, and let those decide whether you are chasing a fault or explaining one that already left.

References

• Trade-standard practice for intermittent and no-fault-found diagnosis
• Manufacturer documentation on stored fault codes and protective trips
• See related: Catching the Fault That Hides When You Arrive (decision tree); The Witness Mark or Data Logger Method; Forcing an Intermittent to Show Itself
• See related: Customer-Induced Faults and How to Spot Them