Turning Random Into a Pattern With the Right Questions

Why this matters

The fastest tool for an intermittent fault is not in your truck. It is the question you ask the customer. Most "random" faults are already solved in the customer's memory; they just do not know which detail matters, so they leave it out. The tech who asks the right questions walks in already knowing when the fault fires. The one who asks "so what's it doing?" and nods gets a shrug and a repeat visit.

The problem with how customers report faults

Customers report the symptom and drop the conditions, because to them the conditions are just normal life. "The breaker trips sometimes" leaves out that it trips every morning when the space heater and the toaster run together. They are not hiding it; they genuinely do not see the connection. Your questions have to reach past the symptom and pull the conditions out.

Two failure modes to avoid: asking open questions that invite another shrug ("when does it happen?"), and asking leading questions that plant an answer they will agree with just to be helpful ("does it happen when it's hot?"). Ask specific, answerable, non-leading questions instead.

The question set that converts random to pattern

Run these in order. Each targets a hidden-trigger bucket:

• "Walk me through the last time it happened. What were you doing right before?" Anchors them to a real event, not a generality.
• "What time of day, and what else was running or on?" Surfaces clock and concurrent-load triggers.
• "Was it hot, cold, raining, humid?" Surfaces weather and thermal triggers, asked as a menu so you are not leading to one answer.
• "Does it clear by itself, or do you have to do something?" Self-clearing versus reset separates a protective device doing its job from a hard failure.
• "When did it start, and did anything change around then?" Ties onset to a recent change (see the companion articles on recent-change triggers).
• "How often, every day, a few times a week, once a month?" Frequency tells you whether a stakeout or a log is worth it.

Give them a log sheet, not a memory test

When the fault will not reproduce on your visit, the customer becomes your instrument between now and the next visit. Do not tell them to "keep an eye on it." Give them a structured capture:

• Date and time it happened.
• What was running (appliances, HVAC, water, pool equipment).
• Weather outside.
• What they did to recover.

A phone note or a sheet on the fridge works. Three or four logged events usually make the pattern obvious. Ask them to take a photo or short video if there is anything to see or hear: a display code, a sound, a drip.

Read the log like evidence

When you come back, do not just glance at it. Line the events up and look for the shared condition. Three trips, all between six and seven in the morning, all on cold days, is not random. It is a cold-start load problem. One event that breaks the pattern is worth as much as the three that fit: it either disproves your theory or points to a second, independent fault sitting underneath the first.

What the questions cannot do

Questioning narrows the search; it does not replace measurement. A customer's report of "it sparked" tells you where to point the meter, not what the reading will be. And memory is unreliable on sequence and timing, so treat a single vivid report as a lead to verify, not a confirmed fact. The pattern you build from questions is a hypothesis you then prove with instruments.

References

• Trade-standard practice for customer intake and fault history
• Consumer-education guidance on documenting an intermittent problem
• See related: The Customer Says It Just Happens Randomly (decision tree); The Recent Change Nobody Connected to the Fault