How to Ask a Non-Technical Customer a Diagnostic Question

Why this matters

Most bad remote information is not the customer's fault. It is the question's fault. Ask a leading question and a helpful person will agree with you. Ask a technical question and a polite person will guess rather than admit they do not know the word. Ask two things at once and you get an answer to one of them with no way to tell which. The answers then go in the ticket as facts, a tech drives out on them, and the whole visit is built on an artifact of the phrasing. Question construction is a skill, and it is learnable in an afternoon.

Before any of it: if an answer at any point includes a smell of gas or fuel, a shock, smoke, or water near anything electrical, the interview stops and the safety instruction starts. Everyone out for fuel smells, hands off and power isolated by someone competent for water and electricity. Nothing you are trying to learn is worth continuing through that.

Step 1: Replace the trade word with a function or a place

The single biggest source of garbage answers is a word the customer does not own. They will not stop you to ask what it means. They will map it onto the nearest thing they recognize and answer about that instead.

Swap the component name for what it does or where it is:

• Not "is the condenser fan running" but "outside, at the unit next to the house, is the big fan on top spinning."
• Not "is the pilot lit" but "there is usually a small blue flame you can see through a little window near the bottom. Is it there right now."
• Not "is the breaker tripped" but "in the gray panel, are all the switches lined up the same way, or is one of them sitting differently from the rest."
• Not "is it short cycling" but "how many times does it start and stop in an hour."

Notice the third one. It does not ask them to know what tripped looks like. It asks them to compare one thing against its neighbors, which anyone can do.

Skip this step and every later answer inherits the ambiguity. You will spend the visit discovering they were describing a different device the whole time.

Step 2: Ask for the sense, not the verdict

Build the question around a sense verb: see, hear, smell, feel, or a count. Those return perceptions. Anything else returns an opinion.

"What do you hear when it starts" returns a description. "Does it sound like the motor is struggling" returns your own theory reflected back at you. Both feel like questions. Only one is.

There is a full article on refusing conclusions and converting them into observations, and it is worth reading alongside this one. The point here is narrower and it is about grammar: if your sentence contains a component name plus a state, you have written a verdict question. Rewrite it until the customer's only job is to report a perception.

Step 3: Do not put the answer inside the question

People under pressure agree. A customer who wants their system fixed, who feels slightly embarrassed about not knowing, and who is talking to an expert will say yes to a plausible-sounding suggestion far more often than the truth warrants. This is the most damaging habit in the whole interview and the easiest to fall into, because leading questions are fast.

The last-but-one row is worth dwelling on. Ask "is there a burning smell" and a meaningful share of people will say yes, because they are now smelling for one. Ask an open smell question and the ones who genuinely have an electrical odor will tell you unprompted, and that answer means something.

Step 4: When open questions stall, offer a menu with an exit

Open questions are better but they fail on people who freeze. When a question comes back with "I do not know how to describe it," give three or four distinct options, and always include an explicit way out.

"Is it more like a hum that stays steady, a rattle that comes and goes, a squeal, or a knocking? Or none of those, if none of them fit."

The exit is not politeness, it is data integrity. Without it, a four-option menu forces every answer into one of your four categories, and you have converted "I do not know" into false evidence. When someone takes the exit, that is useful too: it usually means the sound is unusual enough to be worth a recording.

Step 5: Anchor magnitude to something in their world

People are unreliable at absolute magnitude and reliable at comparison. Never ask "how hot," "how loud," or "how much." Ask relative to something they know.

• Heat: "can you hold your hand comfortably near it, yes or no." Nothing more precise, and never a touch instruction on something that may be hot.
• Sound: "can you hold a normal conversation next to it, or do you have to raise your voice."
• Water: "is it a drip you could count, a steady trickle, or a stream."
• Flow: "how long does it take to fill a container you can show me, compared to a tap somewhere else in the house."
• Change over time: "is it worse, the same, or better than a week ago."

Those all return something you can act on and none of them require an instrument.

Step 6: One variable per question

Compound questions produce uninterpretable answers. "Does it happen when it is cold or when it has been running a while" gets you "yes" from a surprising number of people, and even a thoughtful answer leaves you unsure which half they addressed.

Split them and ask in sequence. It costs ten extra seconds and it is the difference between two clean data points and one ambiguous one. This matters most on exactly the questions you care about most, because those are the ones you are tempted to compress.

Step 7: Ask the important thing twice, differently

For the two or three answers your whole plan rests on, ask again later in different words, from a different direction. Not to catch anyone out, but because a rephrase surfaces the misunderstanding that a repeat of the same words will not.

Early: "How long after it starts does the problem show up?" Later: "If you turned it on right now, what time should I expect your call?" Same fact, different frame. Matching answers means you can rely on it. Diverging answers means the number was never solid, and better to find that out on the phone than after a wasted long-run test.

Step 8: Treat "I do not know" as an assignment, not a dead end

It is an honest and useful answer. The move is to convert it into something they can go and find out.

"That is fine, most people would not know. Here is what I would like you to do: next time it runs, start the timer on your phone when it comes on, and text me the time on the screen when the noise changes. That is all."

Two rules for the assignment. It has to be doable standing on the floor with the covers on, and it has to return a number or a yes/no. If you find yourself writing an assignment that needs judgment, redesign it.

The worked example

A homeowner calls in early summer: "the outdoor unit is leaking water, there is a wet patch under it every day."

The wrong version of this interview takes ninety seconds. "Is it leaking from the pipe connections? Does it smell like anything? Is it a lot of water?" Three leading questions, and a helpful customer produces three agreeable answers. Ticket reads: leak at connections, some odor, significant volume. A tech is booked with a repair kit.

The right version, built on the steps above.

Location in their words, not mine: "Standing in front of it, is the wet patch under the middle of the unit, under one corner, or off to one side near where the pipes go into the house?" Answer: under one corner, the same corner every time.

Magnitude by comparison, not by number: "Is it a drip you could count, a steady trickle, or a stream?" Answer: a drip they could count, roughly one every couple of seconds.

Timing, one variable: "Is the water there when the system has been off all night?" Answer: no, the ground is dry in the morning.

Timing again, the other half, asked separately: "Does the dripping start while it is running, or after it stops?" Answer: while it is running, and it keeps going a little while after it shuts off, then stops.

Duration, converted into an assignment because they did not know: "Next time it shuts off, note the time and check the spot every ten minutes." The answer came back at about 15 minutes after shutdown before it stopped.

Neutral smell and color question: "Does the water have any color or smell?" Answer: clear, no smell.

Now the arithmetic that closes it. One drip every two seconds is 30 drips a minute and 1,800 an hour. That is a lot of drips and a modest amount of water, which is exactly what people mean by "a lot of water" when they see it as a puddle. That rate, appearing only while running, in humid weather, stopping shortly after shutdown, clear and odorless, from one corner, is the signature of normal condensate: water pulled out of the air by a system that is doing its job.

The discriminating fact is the one that would never have come out of the leading version: it is dry in the morning and it stops within about 15 minutes of shutdown. Pressurized water does not care whether the system is running. A supply leak would wet the ground overnight. This one tracks operation exactly, which means it is produced by operation.

That call closed with an explanation, a description of what to watch for that would change the answer (water present after a long off period, any color or smell, or a rate that becomes a continuous stream), and no truck. Compare the two paths: the leading version books a visit, sells a repair kit's worth of work on a system with nothing wrong with it, and creates a customer who will call again next summer with the same non-problem. The neutral version costs six minutes on the phone and buys a customer who now knows what normal looks like.

What doing this wrong looks like

The clearest tell is a ticket where every answer confirms the first theory. Real fault descriptions are messy and contain at least one thing that does not fit. A perfectly consistent set of customer answers usually means the questions did the work, not the customer.

The second tell is trade vocabulary appearing in a customer's quoted words. If the note says the customer reported "short cycling" or "a bad capacitor," those words came from somewhere, and it was probably the previous person on the phone. Record what they actually said and put your translation beside it.

The third is the interview that never produced a number. If nothing in the notes is a count, a duration, or a comparison, nothing in the notes is checkable, and the tech is going out cold with a paragraph of impressions.

How to verify the interview was any good

Read your own notes back and ask three things. Could a different tech act on this without calling the customer again? Is there at least one answer that surprised you or cut against your first theory? Can you name, for each key answer, the exact words you used to get it, and would those words survive being read out in front of the customer without embarrassment?

The last one is the honesty check. A question you would not want the customer to hear repeated is usually a leading one.

References

• Trade-standard practice for service intake and structured fault reporting
• Manufacturer documentation on normal operating behavior, condensate production, and expected noise
• See related: How to Diagnose Through a Customer Who Is Your Only Eyes
• See related: How to Question a Customer to Pin Down When a Fault Happens
• See related: What a Customer Consistently Gets Wrong Describing a Fault Remotely