The Customer Reports a Fault You Can't Make Happen: Decision Tree
Why this matters
The customer is certain the system does something wrong. You arrive, run it every way you know, and it behaves perfectly. The temptation is to write "no fault found," collect for the trip, and leave. That is how you end up back on the same call in two weeks, now as the tech who could not fix it. A fault you cannot reproduce is almost never absent. It is waiting on a trigger you have not identified, a technique you have not matched, or it is genuinely random. This tree keeps you from quitting at "it works for me" and routes the non-reproduction to the right strategy.
Safety first
If the reported fault is a hazard, a gas or burning smell, a shock, a spark, a burst, treat the hazard on its own terms even though you cannot reproduce it. A hazard reported but not reproduced is not cleared; it is uninvestigated. Do not certify it safe just because it behaved during your visit. Follow the hazard-specific response before any of the triage below.
Start here: do not call it "no fault found" yet
"No fault found" means you looked and there is nothing there. "Could not reproduce" means it did not happen while you watched. Those are different, and only the first justifies leaving. Everything here is about turning a could-not-reproduce into a found trigger or a deliberate capture plan.
Step 1: pin the report down before you run anything
The interview is the diagnosis here. Get specifics, not impressions: when exactly does it happen, what else was running, who was operating it, what were they doing right before, how often, and does anything make it stop. Patterns hide in those answers. The rest of the tree is reading which pattern you got.
If the report clusters around a condition
Any grouping, time of day, weather, a load, a neighbor running, startup versus warmed up, points to a condition-dependent fault that fires only when that condition is present. Recreate the condition safely and the fault should appear on demand. This is the most common reason a real fault will not reproduce: you were testing in the wrong state. Put the system into the reported state before you conclude anything.
If only one person triggers it
If the fault follows a person, not a condition, it is technique-dependent. The customer does something you do not: a different sequence, a heavier hand, a habit, a step you skip because you know the equipment. Have them operate it exactly as they do while you watch, or match their technique yourself. Reproduce the user, not just the machine.
If it is truly random with no pattern
If you have genuinely hunted for a trigger and a technique and found neither, accept intermittency and switch to capture. Leave a recorder on the likely values, set the customer up to flag the moment it happens, or set a recheck window. You are trading the ability to force the fault for the ability to catch it, because nothing you can set brings it on command.
If something resets or clears it
If the fault stops when the system is cycled, or the customer reset it before you arrived, the evidence was wiped before you got there. Ask what they did between the fault and your visit. Also watch for the fault that clears the moment you open the system up and returns after you leave, where the act of gaining access disturbs it. Both need capture in the undisturbed state, not another look at the reset system.
If the report does not match the system
If nothing lines up, question the report itself, carefully and without calling the customer wrong. Are they describing this unit or another one on the property. Is the complaint a perception, a normal behavior they read as a fault, with nothing measurable behind it. Confirm you and the customer are even talking about the same equipment and the same symptom before you spend more time chasing it.
Recap
- Handle any reported hazard as a hazard, reproduced or not.
- Interview for specifics before running anything; the pattern is in the answers.
- Clusters around a condition mean recreate the condition. Follows a person means match the technique.
- Truly random means capture. Resets or clears on access means capture undisturbed.
- Nothing matches, confirm the unit and the symptom before chasing further.
References
- Trade-standard practice for intermittent and non-reproducible fault triage
- Manufacturer diagnostic and operating-condition guidance
- See related: Intermittent Fault Cannot Reproduce (decision tree); The Difference Between an Intermittent and a Condition-Dependent Fault