The Fault Counter Shows More Events Than the Customer Reported, Decision Tree

Why this matters

You pull the local fault history and it shows a dozen lockouts. The customer told you on the phone this "just started happening yesterday." That gap is not a customer lying to you, most of the time, it is a real and common mismatch between what a unit's memory records and what a person actually notices, and how you handle the gap decides whether you get an honest, useful conversation or a defensive one. Handled wrong, the customer feels accused. Handled right, the count becomes the single most useful piece of information on the call.

Start here: do not lead with the number as an accusation

Never open with "your unit shows twelve lockouts, why did you tell me it just started." That framing puts the customer on the defensive immediately, and a defensive customer stops giving you useful information. Lead with curiosity about the mismatch, not a challenge to their honesty.

Step 1: Confirm the count is reading what you think it is reading

Before drawing any conclusion, verify what the counter is actually counting. Some controls count every occurrence of a fault including warning-level events that never stopped the unit or were noticeable to anyone. Others count only true lockouts that shut the system down. Reread the manufacturer documentation for exactly what increments that specific count before you treat every entry as an event the customer should have seen.

Step 2: Consider the ordinary reasons for the gap, before assuming anything unusual

Most of the time the gap has a mundane explanation:

• The fault was silent or self-clearing. Many faults trigger a brief lockout the control clears automatically on its own retry logic, with no visible alarm, no shutdown the customer would notice, and no reason for them to have called sooner. The unit kept running normally between events from the customer's perspective.
• The events happened while no one was present or paying attention. A unit in a mechanical room, a basement, an unoccupied rental, or a vacation property can fault repeatedly with nobody around to notice until a visible symptom finally appears.
• The symptom the customer describes is different from the fault in the log. They may genuinely be reporting a new, separate, noticeable problem while the history shows a long-running, unrelated intermittent that never produced a symptom they'd connect to it.
• The customer genuinely did not know how to interpret what they saw. A blinking light or minor alarm they dismissed as normal, or that reset before they could act on it, is not the same as them concealing a known problem.

Step 3: Ask the calibrated question, not the confrontational one

"I'm seeing quite a few recorded events on this unit's history going back further than yesterday. Some of these might not have been noticeable at all, would you mind walking me through what you actually noticed, and when?" This framing gives them room to say "oh, it did do that thing a few times but it always came back on by itself," which is exactly the information you need, without them feeling caught out.

Step 4: If the count reveals a genuinely longer-running problem, use it to reset the diagnosis

A high count with a recent-only complaint usually means the real issue has been building for longer than the visible symptom suggests, and today's failure is the point where it finally became noticeable, not the point where it started. Treat the full history as your actual timeline, and diagnose the root cause accordingly, rather than diagnosing only today's most recent event in isolation.

Step 5: If the customer pushes back hard on the count, do not argue, show them

If a customer insists the history must be wrong because they "would have noticed," do not debate it verbally. Walk them through pulling the history yourself if the interface allows it, or explain plainly what kind of event the count includes (including the ones that self-clear silently). Most pushback resolves once they understand the count includes events they were never meant to notice, and the conversation shifts from disbelief to genuine surprise, which is a much better place to diagnose from.

Step 6: Document the full count and your explanation, whatever it turns out to be

Whether the mismatch was mundane or revealed a real longer-running fault, record the actual count, what it appears to include, and the customer's account of what they noticed and when. If this unit comes back, that record is the baseline the next visit builds on.

Recap

1. Do not open by accusing the customer of underreporting.
2. Confirm exactly what the counter counts before drawing conclusions.
3. Consider ordinary explanations for the gap: silent self-clearing faults, unoccupied periods, mismatched symptoms, misunderstood alarms.
4. Ask a calibrated, non-confrontational question to surface what they actually noticed.
5. Use a genuinely longer history as the real timeline for diagnosis.
6. If they push back, show them the interpretation rather than arguing it.
7. Document the count and the explanation either way.

References

• Manufacturer documentation for what a specific control's fault counter includes and how it increments
• See related: Reading a Unit's Own Local Fault History, Not a Connected System; What a Lockout Count Tells You That a Single Visit Can't