The Data Log Contradicts What the Customer Describes: Decision Tree

Why this matters

You pull the connected system's log and it does not match the story you were just told. The customer says it has been cutting out "every single day this week." The log shows two events, both minor, three days ago. Or the reverse: the customer says nothing has happened, and the log shows a dozen faults. Neither side is automatically right. The customer is reporting their lived experience, which is real even when imprecise; the log is reporting what the equipment's sensors captured, which is real but can miss things or misclassify them. Treating either source as automatically correct is how you end up diagnosing the wrong problem, or worse, telling a customer their experience did not happen. This tree resolves the contradiction instead of picking a side by default.

Start here: which direction is the mismatch

Sort the contradiction into one of two shapes before you do anything else, because they point in opposite directions.

• Log shows less than the customer describes (customer reports frequent or severe symptoms, log shows few or minor events).
• Log shows more than the customer describes (log shows repeated faults, customer reports nothing noticeable or only a mild issue).

If the log shows less than the customer describes

1. Confirm the log's coverage window first. Check retention (how far back it goes) and check for gaps (outages, firmware updates, connectivity drops). A short retention window or a gap during the reported period fully explains a "missing" event; this is not a contradiction, it is a blind spot in the record.
2. Ask the customer to describe the symptom in sensory terms, not conclusions. "It cuts out" can mean a dozen different actual behaviors: a full shutdown, a mode change, a sound, a temperature swing they noticed by feel. Get the raw description, then check whether the log has anything matching that raw behavior, even if it was not flagged as a fault.
3. Check for a symptom the equipment does not log at all. Some conditions, a noise, a smell, a slow performance drop, are not sensor-tracked events and will never appear in any log regardless of how real they are. If the customer's complaint is in this category, the log's silence tells you nothing either way; you are back to a live diagnostic.
4. If the customer's account and the log genuinely disagree on frequency with no gap or blind-spot explanation, consider whether the symptom is intermittent and location- or condition-specific in a way the sensor placement misses (a hot spot the sensor is not near, a vibration the sensor does not measure). Try to reproduce under the customer's stated conditions rather than generic test conditions.
5. If you cannot find any log evidence and cannot reproduce the symptom, say so plainly and set up monitoring or a follow-up rather than guessing a repair. A symptom you cannot confirm by any method is not yet a diagnosis; it is a callback risk if you invent one.

If the log shows more than the customer describes

1. Check whether the logged faults are the kind a person would actually notice. Many logged events are brief, self-correcting, or affect a secondary function the customer would not clock day to day. A dozen sub-second communications retries logging as "faults" is very different from a dozen full shutdowns.
2. Check whether the faults cluster at a time nobody is present or paying attention - overnight, while the space is unoccupied, or during a mode the customer never uses. A real fault the customer never happened to notice is still real and still worth fixing, but it changes the urgency conversation you have with them.
3. Rule out a logging artifact before you alarm the customer. A sensor that is marginal or a communications module with a weak connection can generate a stream of faults that do not reflect the actual mechanical or electrical health of the system. Verify at least one flagged event with a live reading before treating the log as proof of a real, ongoing problem.
4. If the faults are confirmed real and frequent, but the customer has not noticed, explain what you found in plain terms and what the risk is if left alone. This is a common education gap: equipment can be silently struggling and comfortably masking it (running longer to compensate, for example) right up until it cannot anymore.

When the two sources cannot be reconciled

Sometimes, after checking retention, gaps, sensor placement, and logging artifacts, the customer's account and the log genuinely still do not line up. That is a real outcome, not a failure of the tree. Document both accounts honestly, note what you checked and ruled out, and either set up short-term monitoring (a temporary logger, an app alert, a follow-up call in a few days) or schedule a return visit timed to when the symptom is more likely, rather than picking one story to believe and diagnosing against it.

Recap

1. Identify which direction the mismatch runs.
2. Check the log's coverage window and gaps before trusting its completeness.
3. Get the customer's raw sensory description, not their conclusion.
4. Verify any flagged event with a live reading before acting on it.
5. If unresolved, monitor or schedule around the pattern instead of guessing.

References

• Manufacturer documentation on connected-equipment fault classification and retention limits
• Trade-standard practice for customer-reported symptom intake and verification
• See related: Reading a Connected System's Data Log: The Discipline; What a Data Log Can Tell You That a Single Visit Can't