Say it plainly, and say it early
Every agent eventually tells a customer something that turns out to be wrong — a price, a
policy, a delivery date, a step that does not work on their setup. The error itself is rarely the
damaging part. What damages trust is the handling: the delay, the hedge, the quiet hope that it
will not come up.
Correct it as soon as you know, even if the conversation has moved on and even if raising it is
awkward. A correction offered voluntarily reads as competence. The same correction discovered by
the customer later reads as something closer to dishonesty, regardless of intent.
Be direct about what was wrong. “I need to correct something I said earlier — the
return window is thirty days, not sixty. I had that wrong, and I am sorry” is complete. It
names the error, gives the right answer, and takes responsibility in three short sentences.
Avoid the constructions people reach for when uncomfortable. “There may have been some
confusion” assigns the error to nobody and reads as evasive. “The system showed
me” blames a tool the customer cannot see. “As I mentioned” when you did not
mention it is an attempt to rewrite the conversation, and the transcript is right there. Each of
these turns a small factual error into a question about whether you can be trusted.
Apologise once, properly, and then move to the fix. Repeated apologising makes the error feel
larger than it is and pushes the customer into reassuring you, which is not their job.
When the mistake already cost them something
A correction is easy when nothing has happened yet. It is harder when the customer has acted on
what you told them — bought the wrong thing, missed a deadline, waited for something that
was never coming, or told their own customer a date you gave them.
Deal with the consequence before the explanation. The instinct is to explain how the error
happened, because explaining feels like taking responsibility. To the customer sitting with the
consequence, it reads as a preamble to being told nothing can be done. Lead with what you are
going to do about it, then explain if they want to know.
Make the remedy proportionate to what your error actually cost them, not to the value of the
original transaction. Someone who took an afternoon off work for a delivery that was never
scheduled has lost more than the shipping fee, and a refund of the shipping fee will read as
insulting rather than generous.
Where you cannot fully fix it, say so plainly rather than implying you might. “I cannot
get it there by Friday — that is not possible now, and it is our fault. What I can do
is” respects the customer more than an optimistic maybe that fails again next week. A second
broken promise on the same issue is considerably worse than an honest no.
If the error came from a policy or a system rather than from you personally, still own it as
the company. “We got this wrong” is accurate and lands well; “the system
does that” is an explanation the customer cannot use and cannot argue with.
Catch the ones nobody notices
The corrections that never happen are the expensive ones. An agent gives a wrong answer, the
customer accepts it, the conversation closes cleanly, and the error surfaces weeks later as a
complaint or a refund request that nobody connects back to the original chat.
The habit that catches these is a quick check at the moment of doubt rather than after. If you
are not certain, look it up before sending; the ten seconds is always cheaper than the correction.
Where you have already sent it and then realise, go back into the conversation even if it has
ended — a follow-up message correcting yesterday’s answer is unusual enough that
customers remember it favourably.
Build a route for agents to flag their own errors without it counting against them. Teams that
treat mistakes as performance problems get fewer reported mistakes, not fewer mistakes. The ones
that go unreported are the ones that repeat, because nobody fixes the canned response or the
documentation that caused them.
When the same wrong answer appears more than once, treat it as a content problem rather than an
agent problem. Recurring errors almost always trace back to a stale template, an ambiguous help
page or a policy that two people read differently, and fixing the source removes the whole class.
What to measure
Count corrections that were self-reported against those discovered by a customer. A healthy
team has plenty of the first kind; a team with almost none is not error-free, it is
under-reporting, and that is the more worrying state.
Track repeat errors on the same topic. One agent getting a policy wrong is an individual
coaching moment; three agents getting the same policy wrong in a month is a documentation defect
and should be routed there instead.
Watch what happens after a correction. Whether the customer stays, buys again, or escalates
tells you far more about your handling than any satisfaction score collected on the same
conversation, and it is the number that justifies correcting errors quickly rather than
quietly.