How to Teach Someone to Explain Their Work to a Customer

Why this matters

A tech who can find the fault but cannot explain it costs the shop more than a tech who is slightly slower in the field. The work gets done, the customer does not understand what they paid for, the recommendation does not get approved, and the review says the tech was "nice but did not really explain anything." Worse, when the same fault comes back for an unrelated reason, the customer remembers being confused and reads it as being misled.

This is a teachable skill and it is taught badly almost everywhere: tell someone to explain it more simply, which is advice with no method attached, or let them absorb it by watching a senior tech, which teaches one person's phrasing without the structure underneath. What follows is the training method. How a good explanation is constructed and delivered is a separate article and this one deliberately does not re-derive it.

Step 1: Find out which failure you actually have

Three different problems all look like "bad at explaining" from the outside, and they need different fixes. Listen to two or three of their calls before deciding.

The jargon problem. They know the answer and say it in trade language. The customer hears words they cannot evaluate and agrees to be polite. Tell: the customer says "okay" a lot and asks no questions.

The structure problem. Their vocabulary is fine but the explanation arrives in the order they discovered it rather than the order the customer needs it. They start with what they checked first, wander through what they ruled out, and land on the finding four minutes in. Tell: the customer interrupts to ask "so what is wrong with it?"

The confidence problem. They know it, they can say it, and they hedge everything into mush because they are afraid of being wrong in front of someone. Tell: sentences that start with "it might be" and never resolve, and quotes that get walked back before the customer has objected to anything.

The fixes diverge sharply. Jargon is a vocabulary drill. Structure is a frame. Confidence is repetitions plus explicit permission to be certain about the things they are actually certain about. Applying the frame to a confidence problem produces a well-structured hedge, and applying a vocabulary drill to a structure problem produces simple words in the wrong order.

Step 2: Hand them a frame, not a script

Scripts fail in the field because the first customer question knocks them off the rails and there is nothing underneath. A frame survives being interrupted. Three sentences, in this order:

1. What the part does, in one sentence, in terms of the thing the customer already cares about.
2. What happened to it, in one sentence, cause first if the cause is known.
3. What it means for them, in one sentence: what happens if it is fixed, and what happens if it is not.

Order is the load-bearing part. Function before failure, because a customer cannot evaluate a failure in a part they do not know the purpose of. Consequence last, because that is the sentence they will actually use to make the decision, and it should be the one still in the air when they respond.

Teach the frame by having them apply it to three faults they already understand cold, out loud, before they ever use it on a customer. If they cannot do it on a fault they know backwards, the problem is not the customer.

Step 3: Rehearse in the truck, out loud, before the door

Thirty seconds before the walk-up: "How are you going to open this one?" They say it out loud. You do not correct the wording, only the order and any word a homeowner would not know.

Trainees resist this and it is the highest-return step in the method. Explanation quality collapses under mild social pressure, and the first time a sentence gets constructed should not be while a customer stands there waiting.

After the diagnosis and before the customer conversation, do it again on the actual finding. This second rehearsal is where you catch the jargon, because the real finding pulls in trade words the practice run did not.

Step 4: Listen without rescuing

Stand where you can hear and let it happen. The reflex to step in and finish the explanation is strong and it is the thing that keeps a tech from ever getting good at this, because a trainee who knows the mentor will take over never has to complete a hard sentence.

Two rules for the mentor:

• Do not correct in front of the customer unless what was said is factually wrong or creates a safety misunderstanding. A clumsy but accurate explanation is a successful attempt. Correcting it in front of the customer teaches the customer that the trainee is not the real tech, and teaches the trainee to stop trying.
• Do not answer the customer's follow-up question. If the customer turns to you, redirect once: "That is his call, he ran it." Then stay quiet. The redirect is uncomfortable exactly once and it changes the shape of every later job.

The exception, and it is not negotiable: if the explanation understates a hazard, step in immediately. A customer walking away believing a gas smell or a wet electrical panel can wait is not a teaching moment.

Step 5: Score it against something specific

"That went well" teaches nothing. Score four things, out of one point each, right after the call:

1. Function first. Did they say what the part does before what went wrong with it?
2. Plain language. Zero trade terms used without a plain-language gloss attached in the same sentence.
3. The consequence sentence. Did they state what happens if it is not addressed, in the customer's terms?
4. Check for understanding. Did they ask the customer to say back what they heard, before quoting?

Four points, scored the same way every time, and shared with the trainee immediately. The value is not the number, it is that the same four things get measured on every call, so improvement is visible on a specific axis rather than as a general feeling.

Score the first three calls yourself, then have them self-score and compare. A trainee whose self-score matches yours has internalized the standard, which is the goal.

Step 6: Make the check-for-understanding non-optional

Item 4 is the one that gets dropped first and the one that catches the most damage. Before any number is mentioned, the tech asks the customer to restate it: "Before I give you the options, can you tell me what you understand the problem to be?"

Techs resist this because it feels like a test of the customer. Reframe it as a test of the explanation and say it that way: "I want to make sure I explained that well." Almost nobody takes offense.

What it catches is specific and expensive: the customer who has quietly concluded something entirely different is wrong, approves the work anyway, and is angry later when the thing they thought was being fixed is still broken.

Step 7: Fix the vocabulary once, shop-wide

Do not fix jargon one word at a time per tech. Build a short shared list: the fifteen or twenty trade terms your work actually requires, each with the plain-language sentence your shop uses. Not a glossary of definitions, a list of exact phrasings.

One list means the customer hears the same explanation from every tech, which matters on repeat visits, and a new tech inherits the shop's language instead of inventing their own. It takes an afternoon with the crew in the room.

A worked example: five calls with a second-year

Baseline, calls 1 to 5, scored on the four items: 1, 2, 1, 2, 2. Average 1.6 out of 4.

Reading the pattern matters more than the average. Item 2, plain language, scored on 4 of 5 calls, so vocabulary is not the problem. Item 1, function first, scored on 1 of 5. Item 3, consequence, scored on 3 of 5. Item 4, check for understanding, scored 0 of 5, never attempted once. Diagnosis. This is a structure problem, not a jargon problem. They speak plainly and start in the wrong place, opening with what they tested rather than what the part does. And they have never been told to check understanding, so the zero is a missing instruction rather than a skill gap.

Intervention. Two things only. The three-sentence frame, drilled on three known faults in the shop bay before the next job. And item 4 stated as a hard requirement: no number goes to a customer before the customer says the problem back.

Calls 6 to 10: 3, 3, 4, 3, 4. Average 3.4 out of 4. That is a move from 1.6 to 3.4, which is a gain of 1.8 points, or slightly better than doubling the baseline, across five calls and roughly two weeks.

Where the remaining misses are. Two of the five missed item 3, the consequence sentence, and both were on findings where the honest consequence was mild. That is worth noticing rather than drilling: on a low-consequence finding, manufacturing urgency to complete a rubric is a worse outcome than dropping the point. The correct fix is to widen item 3 to include saying plainly that it can wait, which is a consequence sentence too, and arguably the more valuable one.

What did not move and did not need to. Item 2 was already at 4 of 5 and finished at 5 of 5. Spending the intervention on vocabulary, which is the instinctive move because jargon is the stereotype, would have improved a score that was already fine and left the actual problem untouched. That is why step 1 exists.

Cost. Rehearsals ran 30 to 60 seconds, twice per job, so roughly 2 minutes per call across 10 calls. Scoring took 2 minutes per call. The frame drill was one 15-minute session. Under an hour and a half of combined time for the whole intervention, and none of it needed a slow week.

The failure version. The same trainee, told after call 3 that they "need to explain things better," with no rubric and no frame. They read it as "use simpler words," which they were already doing, so nothing changes. After call 8 the mentor starts explaining findings themselves because it is faster. By call 15 the trainee has stopped attempting the customer conversation at all, and the shop has concluded they are not a customer-facing tech. Nothing about their ability changed. The feedback was just unactionable.

What changes the answer

A tech with a confidence problem rather than a structure problem. The frame will not help much and the scoring can make it worse, because a person who is already anxious about being judged now has a number attached. Lead with repetitions on findings they are certain about, let them build a track record of being right out loud, and introduce scoring only once they are volunteering for the conversation.

Explaining to a landlord, property manager, or commercial contact. The frame holds but the third sentence changes. The consequence that matters is not comfort, it is downtime, liability, tenant complaints, or a compliance deadline. A tech trained only on homeowner consequences will deliver a technically correct explanation that lands on nothing the decision-maker cares about.

A language gap. Slow down, shorten every sentence, and lean much harder on the check-for-understanding, which stops being a quality step and becomes the primary tool. Do not simplify the content, simplify the sentences.

A tech who is genuinely uncertain about the diagnosis. Do not teach them to explain confidently around uncertainty. Teach the honest version: what is known, what is not, what the next step would cost in time. A confident explanation of a wrong diagnosis is the most expensive output of this entire skill, and a training program that rewards smooth delivery over accuracy will produce it.

How to verify you got this right

• Compare their self-score to yours. When the two match on three consecutive calls, the standard has transferred and you can stop scoring.
• Watch the approval pattern, not the compliment. Customers describing the tech as thorough or as someone who explained things is a good sign but a lagging one. The faster signal is whether recommendations get approved without a second visit to re-explain.
• Listen for the check-for-understanding when you are not there. Ask the customer on a follow-up call whether the tech asked them to say the problem back. If that step is only happening when a mentor is present, it has not been learned, it is being performed.
• The stop sign. If the trainee's explanations improve while their diagnoses get vaguer, you have trained presentation ahead of substance. Score the diagnosis separately and stop the communication work until the technical side catches up.

References

• See related: Explaining What Failed and Why to a Customer, The Teach-Back Method: Confirming They Actually Got It
• See related: Teaching Through Analogy: What Works, Confirming a Diagnosis Back to a Customer Across a Language Gap
• Trade-standard practice for technician customer-communication training
• Plain-language communication guidance for technical explanation to non-specialists