Avoiding Assumptions When Communication Is Imperfect

Why this matters

When information arrives thin, whether from a language gap, a rushed customer, a bad phone connection, or a vague complaint, your brain does something helpful and dangerous at the same time: it fills the gaps with the most familiar explanation. That is a normal shortcut and it is often right. It is also how a tech ends up diagnosing the last five calls instead of the one in front of them. The fix is not to distrust every customer. It is to notice exactly where you are guessing and treat that guess as a guess, not as data.

Where the gaps get filled without you noticing

Incomplete communication leaves holes at predictable points, and each one invites a specific bad habit.

  • Vague timing ("it's been doing this for a while") gets silently rounded to "probably worn out from age," when it could mean three days or three years.
  • Vague severity ("it's really bad") gets anchored to whatever severity you saw on your last similar call, not this one.
  • A missing cause gets assigned to the most common cause for that symptom in general, even when this specific site has an unusual layout, an unusual prior repair, or a recent change that makes the common cause less likely.
  • A hesitant or unclear answer gets read as confirmation, because a rushed brain treats "not a clear no" as a yes.

None of these fills are stated out loud. That is what makes them dangerous: an assumption you know you are making, you can check. One you do not notice, you act on.

The habit that catches it: name the gap before you fill it

Before committing to a theory built on an unclear answer, say the gap out loud to yourself: "I do not actually know how long this has been happening, I am assuming a while because the part looks old." Naming it does two things. It flags the fact as unverified rather than settled, and it usually tells you exactly what one more question or one more test would resolve.

Verify with something other than more words

If the answer itself is the unreliable part, do not just ask the question again in different words and hope for a clearer answer. Reach for a non-verbal confirmation instead:

  • Check a log, a fault history, or a date code instead of relying on a stated timeline.
  • Reproduce the condition yourself instead of relying on a described severity.
  • Look for physical evidence of the assumed cause (wear pattern, corrosion, a specific stain) instead of assuming the common cause applies here too.
  • Get a clear, closed-ended yes or no, ideally with a point or a written confirmation, instead of accepting a hesitant or ambiguous response as agreement.

The customer's silence is not always agreement

A customer who does not push back on your explanation may be confused, may not have understood a technical term, may be deferring out of politeness, or may genuinely agree. Across an imperfect channel, all four look identical from the outside. Treat unchallenged silence as neutral, not as confirmation, especially before starting billable work. Ask them to restate it back in their own words or point at what they believe is happening; a wrong restatement catches the gap before it costs anyone money.

Watch for the compounding effect

One unnoticed assumption is usually recoverable. The real damage comes from stacking several: an assumed timeline plus an assumed cause plus an assumed agreement adds up to a full diagnosis and a completed repair built on zero verified facts. Each individual gap felt small; the total is a wrong repair and a customer who never actually agreed to it.

What good looks like

You can point to which facts in your diagnosis came from direct evidence and which came from an assumption you made because the communication was thin, and for every assumption that mattered, you found a way to verify it that did not depend on more words.

References

  • Trade-standard practice for fault verification independent of customer-reported history.
  • Small Business Administration guidance on clear customer communication and informed consent before billable work.
  • See related: The Customer and Tech Don't Share a Language: Decision Tree; A Translated Symptom Description Doesn't Match What You Find.