The Customer and Tech Don't Share a Language: Decision Tree

Why this matters

A diagnosis starts with a story: what happened, when it started, what it sounded or smelled like, what changed right before it broke. When you and the customer do not share a language, that story arrives thin, garbled, or wrong, and a thin story sends you down the wrong branch of every fault tree you own. This is not the general "how do I work politely with a language barrier" problem. It is a narrower one: how do you extract an accurate diagnostic symptom history when the words are the weakest link in the chain. Get this step wrong and you are troubleshooting a story that never happened.

Start here: what can you get without any words at all

Before you lean on language at all, gather everything the physical scene tells you. This is the highest-value, zero-risk first move.

• Walk the site and look for the fault yourself: staining, tripped devices, error lights, standing water, a burnt smell, a part sitting loose nearby.
• Check any local fault history the equipment keeps on its own display or log (see the companion article on reading local fault history).
• Note the obvious use pattern: what room, what fixture, what time of day the household is normally active there.

If the physical evidence alone gives you a clear leading suspect, you can proceed to confirm it and use language only to verify, which is a much lower bar than using language to generate the theory from scratch.

If the evidence is ambiguous or you cannot find anything wrong yet, you need the symptom history, and now the language gap actually matters. Go to the next section.

If you need the story and the words are thin

1. Pick your best channel first. A translation app with voice input, typed text on a screen, or a bridge person in the household, in roughly that order of reliability for a factual symptom history (see the companion Reference on tool accuracy). Say plainly that you are going to use it; do not try to muscle through with gestures alone if a tool is available.
2. Ask one fact at a time, closed-ended where you can. "Did this happen today or before today?" translates and answers cleanly. "Tell me everything that's been going on" does not; it produces a paragraph that garbles in translation and buries the one fact you needed.
3. Anchor every answer to something physical. Instead of trusting a translated adjective like "loud" or "a lot," walk them to the unit and have them point, mimic the sound, or hold up fingers for a count or a duration. A pointed finger and a mimicked sound survive translation; a subjective word does not.
4. Get the timeline, then the trigger. When did it start, and what was happening right before (a storm, a power blip, someone using the unit hard, new construction next door). The trigger question is worth extra translation effort because it is the single highest-yield fact for narrowing a fault tree.

If the answers keep coming back vague or contradictory

If repeated attempts at the same question keep producing different answers, stop trusting the verbal channel for that specific fact and go find it another way: test it yourself, check a log, or look for physical confirmation. A translated answer that will not hold still under two different phrasings is not a fact yet, it is noise.

If a family member is relaying answers and the answers feel suspiciously smooth or short, see the companion decision tree on filtered interpretation; an intermediary sometimes trims or softens what the customer actually said.

Confirm before you commit to a diagnosis

Once you have a working theory, translate it back in the simplest possible terms and watch for a real reaction, not a reflexive nod. "This part broke, I will replace it, it will cost about X" phrased as a closed yes/no question through your best channel, with the customer pointing at the part in question, is the confirmation that actually holds up if a dispute happens later.

Recap

1. Read the physical scene and any local fault log first; language is not always the bottleneck.
2. If you need the symptom story, use your best available channel, ask closed questions one at a time, and anchor answers to physical proof.
3. Get the timeline and the trigger event; they carry the most diagnostic weight.
4. Distrust any fact that changes between two askings; verify it another way instead.
5. Confirm the final diagnosis back in simple terms and watch for a real reaction before you start billable work.

References

• Small Business Administration guidance on clear customer communication and service agreements.
• Trade-standard practice for customer authorization and written estimates before billable work.
• See related: Using Photos, Gestures, and Translation Tools Without Losing Accuracy; Working Around a Language Barrier in the Field.