The Complaint That's Actually Two Unrelated Problems: Decision Tree

Why this matters

You fix the thing the customer called about, and they call back a week later still unhappy, not because your fix failed, but because there was a second problem hiding behind the first one that nobody separated out. This happens constantly on older equipment, multi-system properties, and any complaint described in vague, combined language ("it's just not working right"). Missing the second problem does not make you wrong about the first one, it makes the visit feel incomplete to the customer, and that is the callback that costs you trust even though your actual repair was correct.

Start here: does one fix explain everything reported

Before you close out the ticket, run the original complaint back against what you found and fixed.

1. List every symptom the customer described, not just the main one. Customers often report two or three things in one sentence and you only chase the loudest.
2. Check each symptom against your diagnosis. Does the fault you found and fixed actually explain each item on the list, or only some of them?
3. If every symptom traces back to the one fault, you are done, close it out. If one or more symptoms are unexplained by your fix, continue below.

If the two symptoms are on the same system

This is the easier case. Two faults on one system often share a root cause, or one caused the other.

• Check whether the fault you already fixed could plausibly have caused the second symptom as a side effect (a restriction causing both a noise and a performance drop, for example). If so, recheck the second symptom now that the first is resolved. It may already be gone.
• If the second symptom persists after the first fix, treat it as its own fault and diagnose it independently. Do not assume it will "work itself out" once the first repair settles in.

If the two symptoms are on different systems entirely

This is the case that most often gets missed, because nobody expects a single visit to require two unrelated diagnoses.

• Confirm the systems genuinely do not share a component, power source, or supply line. If they are truly independent, you are looking at coincidental timing: two things broke close together, which happens more often on aging properties than it feels like it should.
• Diagnose the second system on its own fault tree, starting from the same "what changed" question you used on the first. See related: the diagnostic value of asking what changed recently.
• Quote and explain the second issue separately and plainly: "what I fixed addresses the noise, but the second thing you mentioned is a different system entirely and needs its own diagnosis." Customers accept two problems far better when you name them as two problems instead of letting the first repair imply you covered everything.

If you cannot tell whether it is one problem or two

Some complaints are genuinely ambiguous until you test. In that case:

1. Fix or address the clearest, most confirmable fault first.
2. Re-test the full original complaint, not just the part you touched.
3. If the complaint is fully resolved, it was one problem. If any part of it remains, you now know it was at least two, and you have already isolated one of them, so the second is easier to chase in isolation.

The trap to avoid

Do not stretch one diagnosis to cover a symptom it does not actually explain just because it would be convenient for the visit to be over. A tech under time pressure will sometimes talk themselves into "that's probably related" without verifying it. If you catch yourself explaining a symptom with a shrug instead of a mechanism, stop and treat it as its own problem. See related: diagnosis under time pressure.

What to tell the customer

Name both problems explicitly, even if you only have time or authorization to fix one today. "I found and fixed the [first issue]. Separately, I found [second issue], which is a different system and will need its own visit or authorization." This does two things: it protects you from a callback reading as a failed repair, and it gives the customer an honest picture instead of a false sense that everything is now handled.

References

• Trade-standard practice for complete-complaint verification before ticket closure
• See related: The Diagnostic Value of Asking What Changed Recently, Diagnosis Under Time Pressure, Reading What the Customer Didn't Say