Understanding a truck problem and explaining that problem to someone else are two completely different skills.
When I first started dealing with technical information, I thought giving more detail automatically meant giving a better explanation.
Usually, it didn’t.
Most customers want to understand what’s happening with their truck, what needs attention, and what happens next. They don’t necessarily want a five-minute technical lecture.
Working around MHC Kenworth taught me to make those conversations much simpler.
I Start With the Actual Problem
Before explaining anything, I make sure I understand what has actually been confirmed.
There’s an important difference between:
What the customer reported
What we’ve observed
What has been confirmed
What still needs to be checked
Keeping those separate prevents me from presenting an assumption as a final answer.
I Avoid Starting With Technical Terminology
Technical terminology is useful when I’m talking with someone who works with the same systems every day.
With a customer, I usually start with plain language.
Instead of immediately naming several components, I explain:
Here’s what we’re seeing and why it matters.
If they want more technical detail, I can always add it.
I Explain the Effect, Not Just the Component
Simply naming a component doesn’t always explain anything.
If something isn’t operating correctly, I try to connect it with the customer’s actual concern.
For example:
What isn’t working correctly?
How does that relate to the symptom?
Why does it need attention?
That creates a much clearer explanation.
I Don’t Call a Possibility a Diagnosis
This became one of my biggest rules.
If we’re still checking something, I say that.
There is a big difference between:
This is definitely the problem.
and:
This is one possibility we’re checking based on what we’ve found so far.
That difference matters.
I Ask What the Customer Has Already Noticed
Drivers and fleet customers spend much more time with their trucks than I do.
Their observations can be useful.
I might ask:
- When did it start?
- Does it happen every time?
- Is it worse under certain conditions?
- Did anything change recently?
- Has the truck had similar work before?
The answers can provide context that isn’t obvious while the truck is sitting in the shop.
I Repeat the Concern Back
If a description is complicated, I’ll summarize it.
Something like:
So the main issue happens after the truck has been running for a while, but you don’t notice it immediately after startup. Correct?
That gives the customer a chance to correct me before we build everything around a misunderstanding.
I Keep Updates Short
When there’s new information, I don’t restart the entire story from the beginning.
A useful update can be:
What we found
What we’re checking now
What happens next
That’s usually enough.
I Explain Delays Specifically
“It’s taking longer” isn’t a particularly useful explanation.
When appropriate, I try to explain what is actually creating the delay.
For example:
The initial check is complete, but another step is needed before we can confirm the cause.
or:
The correct component has been identified and we’re checking availability.
Specific information makes the situation easier to understand.
I Don’t Promise a Result I Can’t Control
This can be tempting when someone needs their truck back quickly.
But an optimistic guess can become a promise in the customer’s mind.
If something depends on:
- Additional diagnostics
- Parts availability
- Another repair step
- Unexpected findings
I make that uncertainty clear.
Accurate expectations are better than an impressive estimate that immediately changes.
I Separate the Current Issue From Additional Findings
Sometimes another concern becomes visible while work is being performed.
I try not to mix everything into one confusing explanation.
I separate:
Original Concern
Why the truck came in.
Current Finding
What has been confirmed.
Additional Finding
Something else that may require attention.
That structure makes the conversation much easier to follow.
I Use Photos or Visual Context When Helpful
Sometimes showing something is easier than explaining it.
When appropriate, a photo or visual reference can help a customer understand:
- Damage
- Wear
- Location of a component
- Difference between two conditions
I still explain what they’re looking at instead of assuming the image speaks for itself.
I Check That My Explanation Made Sense
I don’t ask:
Do you understand?
Most people will simply say yes.
A better ending is:
Is there any part of that you want me to go over in more detail?
That makes it easier to ask a question without feeling like they missed something obvious.
I Learned That More Detail Isn’t Always Better
A good explanation isn’t the longest explanation.
It’s the one that answers the customer’s real questions.
Usually:
What’s wrong?
What does that mean?
What happens next?
Is anything still uncertain?
Everything else can be added if it’s useful.
Communication Mistakes I Try to Avoid
❌ Using technical terms without explaining them.
❌ Presenting an early theory as confirmed.
❌ Giving unrealistic time expectations.
❌ Ignoring information from the driver.
❌ Mixing several unrelated findings together.
❌ Giving long explanations without saying what happens next.
❌ Assuming silence means the explanation was clear.
My Customer Update Checklist
Before giving an important update, I ask:
✅ What has actually been confirmed?
✅ What is still being checked?
✅ Can I explain it in plain language?
✅ Does the customer understand why it matters?
✅ Is there another finding that should be separated?
✅ What is the next step?
✅ Am I creating an expectation I can’t guarantee?
Clear Beats Complicated
Working around MHC Kenworth showed me that good customer communication isn’t about sounding as technical as possible.
The technical knowledge still matters.
But the customer shouldn’t need the same background I have to understand what’s happening with their truck.
Explain the confirmed problem.
Separate facts from possibilities.
Give a clear next step.
And if something is still uncertain, say that.
A straightforward explanation usually builds much more confidence than a complicated one.