The Gap Between What a Customer Describes and What Is Happening

Why this matters

The gap between a customer's account and the actual fault is not noise you filter out, it is structured, and the structure is predictable enough to work with. A tech who knows the shape of the distortion can recover most of the missing information with two or three questions. A tech who does not either dismisses the customer's account entirely and arrives blind, or takes it literally and arrives looking for a fault that does not exist. Both cost a visit, and the second one costs credibility as well, because you end up telling someone their equipment is fine after they watched you fail to find anything.

The gap is structural, not a failure of the customer

A customer is a competent observer of their own house and an untrained observer of your equipment. What they report is not a bad measurement, it is a different measurement than the one you need. Three systematic distortions cover most of it, and naming them lets you undo them deliberately instead of guessing.

Salience over causality. People report the thing that got their attention, and attention goes to whatever is loud, visible, wet, or inconvenient. Causes are usually none of those. The dripping fitting gets reported; the failed seal two feet above it that is dripping onto it does not, because it is dry-looking and quiet. This is why the reported location is so often a collection point rather than an origin.

Interface over mechanism. People describe the part of the system they interact with, because it is the only part they have a name for. A complaint about a control or a switch usually means "the thing I touch is not producing the result I expect," and it says almost nothing about whether the control is involved. Treat every component name in a customer report as a location, not as a diagnosis.

Change over state. People notice transitions, not conditions. A system that has been degrading for two seasons gets reported the week it crosses a threshold, and the report will be "it started last Tuesday." That date is real, it is just the date of the crossing, not the date of the onset. Ask what changed, and hear it as the date the symptom became intolerable.

Translating a sentence into an observation

Every customer sentence has an observation buried in it and an interpretation wrapped around it. Separate them before you reason on either.

The last row is worth sitting with. That one has a hazard on one branch and a completely normal event on the other, so it is the one case where you act on the hazard first and translate afterward. Get them away from it and dispatch, then sort out which it was.

Timing is the highest-yield thing to recover

Of everything lost in translation, timing is the most recoverable and the most decisive. Customers compress time, round it, and describe frequency in adverbs. "Constantly," "all the time," "every few minutes," and "randomly" are all feelings, not measurements.

Convert every adverb into a timeline against the equipment's duty cycle:

• Does the symptom occur while it is running, only after it stops, or when it has been off for hours? This single split separates enormous families of cause. Something that appears only during and shortly after a run cycle is fed by the run cycle. Something that happens while the system is off for nine hours is fed by something that does not stop, which usually means supply pressure.
• Does it happen at a repeatable elapsed time into the run? A consistent interval means something accumulates with runtime, which is almost always heat.
• Does it happen at a repeatable time of day? That points at ambient, occupancy, or another load on the same supply, not at the equipment.

Get a number, even a rough one. "About how long after it starts?" produces a usable answer far more often than "when does it happen?" does.

The special case: correct operation reported as a fault

A real fraction of service calls are not faults at all. Something the equipment is designed to do got noticed for the first time and read as a failure. Handling these badly is expensive in both directions: replacing a part that was working, or dismissing a customer who turns out to be right.

Common families, and they cross every trade:

• Normal cycling read as short-cycling. Equipment cycles more often in mild conditions than in extreme ones, because the load is small relative to the capacity. A customer who only ever paid attention during a heat wave or a cold snap will find shoulder-season behavior alarming.
• Normal noise read as damage. Expansion and contraction ticking as metal changes temperature, a startup surge or thump, a brief flow noise as a valve opens, a defrost or purge cycle that vents vapor and looks like smoke. Almost every one of these is a transition sound, which is why "when in the cycle" is the question that identifies them.
• Normal condensation read as a leak. Any equipment that cools something below the dew point of the surrounding air will produce liquid water, in quantity, by design. Residential cooling equipment in humid conditions can shed multiple pints per hour of runtime. That is what the drain is for. Sweating pipe and a wet cabinet exterior are the same physics.
• Normal discharge read as a malfunction. Relief devices, drains, and vents exist to release something. A device doing its job on schedule looks identical to a device failing, from the outside.

The test is not whether the behavior is alarming, it is whether the behavior matches the design intent in timing, quantity, and location at once. Two out of three is not enough. Condensate at the right place, in the right quantity, but present overnight when the system has not run in nine hours is not condensate.

Worked example: "it has been leaking constantly for a week"

Illustrative, and the arithmetic is the point.

The report is water on the floor near a cooling system, described as constant, for about a week. Translated: liquid present at a floor location, repeatedly, over roughly seven days. The word "constantly" is an adverb, so it gets converted before anything else.

The timing questions, asked over the phone:

• Is the floor wet first thing in the morning, before anything has run? No. Dry every morning.
• Roughly how long is the system running each day? Set for most of the afternoon and evening in the current weather, call it about 7 hours a day.
• When you have seen the water, had it been running? Both times she noticed it, yes, within the last hour or so.
• Overnight it is off for how long? About 9 hours, and dry every time.

Now count what that timeline eliminates. A supply-side leak is fed by system pressure, which is present whether or not the equipment is running. A supply leak that produced a visible puddle across a 7 hour run window would produce a considerably larger one across a 9 hour idle window, because it has more time and nothing interrupts it. Instead the idle window produces nothing at all. Over a week, that pattern held every night, which is seven independent negative results, not one.

So the water is on the condensate path, and it is a drainage question, not a leak question. That single conclusion changed the truck load from pipe repair materials to drain clearing and pan hardware, and it changed the diagnostic plan from a pressure test to a drain flow test.

On site it resolved further, and this is where the correct-operation family enters. The drain was flowing normally. The termination point had been changed during unrelated work and now discharged onto a floor surface a few feet from where it used to. The system was working exactly as designed and shedding exactly the volume of water it should shed for that runtime in that humidity. The repair was to re-route the termination, which is a fraction of the labor of the pipe repair that "leaking" had originally implied - roughly a quarter of the time, and with no parts of consequence.

Without the timing conversion, "leaking constantly for a week" loaded as a leak call gets a pressure test, finds nothing, and becomes a second visit. Her word was accurate about her experience and wrong about the mechanism, and the nine dry overnight hours sat in her own observation the whole time, unreported, because nobody asked about the absence.

Ask about the absence, not just the presence

Customers volunteer when a symptom happens and almost never volunteer when it does not. The negative case is frequently more diagnostic than the positive one, because it is what eliminates causes that run continuously. Always ask when the symptom is absent, and treat a confident "never in the morning" as real data.

What changes the answer

• A technically literate customer. Some customers are engineers, mechanics, or trades people in another discipline. Their vocabulary is precise but borrowed from a different domain, so the distortion changes shape rather than disappearing. They will name components confidently and sometimes wrongly. Verify the noun, trust the observation.
• A commercial site with a maintenance log. The change-over-state distortion largely disappears, because a written record gives you the real onset date instead of the noticed date.
• A rental or a property manager reporting for a tenant. Now you have a relay, and everything above compounds through a second person who did not observe it either. Get to the observer if you possibly can.
• A repeat complaint on equipment you have already serviced. The customer's description will be shaped by what you told them last time. They will use your vocabulary back at you, which sounds like confirmation and is not.

Getting it wrong, in both directions

Taking the account literally. The tech arrives, goes straight to the component the customer named, finds it healthy, and either replaces it anyway or reports no fault found. The tell is a job record whose diagnosis is a restatement of the complaint.

Dismissing the account entirely. The opposite failure, common in experienced techs. The customer's account is treated as worthless, so the observation inside it gets thrown out with the interpretation. Customers are unreliable interpreters and generally reliable witnesses to what they saw and when.

How to verify you got this right

On the next handful of jobs, check two things on the record.

1. Does the intake note contain at least one timing fact expressed as a number or an interval, rather than an adverb? If not, the translation step is being skipped.
2. Does it contain at least one negative observation, something the customer confirmed does not happen? A record with only positive symptoms means nobody asked about absence.

Then, after the fix, compare the customer's named location and named component against the actual origin. Track how often they match. In most shops the gap is wide enough that seeing the number changes how the phones get answered.

References

• See related: What a Customer Consistently Gets Wrong Describing a Fault Remotely
• See related: When to Stop Diagnosing Remotely and Roll a Truck
• Trade-standard practice for service intake and complaint documentation
• Manufacturer documentation on normal operating characteristics, cycle behavior, and condensate production