A customer contacts support with a specific problem. The agent listens, forms an impression, and tells them what to do. Confidently. The customer says thanks and hangs up.
Four hours later, the same customer is back. Angrier. The thing they were told to do didn't work. Now they have also lost four hours, and the agent who helped them is on a different shift, so they are starting from scratch with someone new.
The first ticket closed clean. The handle time was low. The agent sounded capable. Nobody noticed the follow-up was a direct consequence of the first interaction.
This is, in my experience, the most expensive failure mode in support. And it is almost never tracked.
The habit nobody names
If you watch enough support interactions, a pattern emerges among the agents who generate the most downstream work: they answer before they are sure.
It doesn't look like incompetence. It looks like confidence. Fast response, no dead air, no holding the customer on a long wait. In the moment, the interaction feels smooth. The customer seems satisfied.
What is happening underneath is that the agent has formed a hypothesis, decided the hypothesis is probably right, and told the customer to act on it. When the hypothesis is wrong, the customer pays the cost. The metric doesn't.
This is not about dishonesty. It is about the gap between knowing and guessing, and the failure to name that gap out loud before giving an answer.
Why training doesn't close it
Most support onboarding covers communication skills: empathetic openers, expectation management, de-escalation techniques, clean closes. These matter. I am not dismissing them.
What rarely gets a dedicated module is something I would call epistemic discipline: knowing the difference between the answers you actually have and the answers you are extrapolating from something that looks similar but might not be.
From the outside, a confident guess and a confirmed answer look identical. Both sound clear. Both produce a resolution. The only test is whether the customer comes back.
Training often teaches confidence as a virtue without teaching the self-awareness that makes confidence earned rather than performed. Those are very different things.
How the metrics make it worse
Support quality metrics are almost universally built around the first interaction. Average handle time. First-response time. First-contact resolution rate. CSAT score collected immediately after the call.
All of these reward speed. None of them reliably catch the cost of a confident wrong answer, because that cost arrives in the second interaction, often logged as a separate ticket, handled by a different agent, invisible to the first agent's record.
If you were designing a system to accidentally reward guessing, you couldn't do much better than this one.
An agent who takes thirty seconds to verify before answering will have a slightly longer handle time. An agent who guesses quickly will often post better numbers on the first ticket. The metrics reward the second behavior. Most managers, consciously or not, reinforce it.
The cost of a confident wrong answer is almost never felt immediately. The ticket closes. The metric records a win. The cost appears one or two days later, as a second ticket that did not need to exist.
What verification actually sounds like
The practical fix is not telling agents to become more uncertain. It is giving them the specific language to pause and confirm without sounding hesitant or incompetent.
"Let me quickly confirm this before I give you incorrect information" is a complete sentence. It takes four seconds. It reframes the pause from "agent doesn't know" to "agent cares about accuracy." Most customers respond well to it, because it implies they are about to get a correct answer, not just a fast one.
There are variations for different situations:
- "This looks like X, but let me check the account history before I confirm."
- "My instinct is Y, but I want to verify that against the current settings before I walk you through it."
- "I've seen this before, but let me confirm the exact state before giving you steps."
Each of these costs roughly fifteen to thirty seconds. Each of them prevents callback conversations that routinely run forty-five minutes to an hour. The time math is obvious once you say it out loud. The reason teams still don't train it is that the cost of guessing is invisible at the moment it happens.
The steelman: decisiveness does matter
The honest pushback is this: customers value decisiveness, and there is a version of "let me check on that" which reads as incompetence, not diligence.
An agent who says "I'm not sure, I'll have to find out" in response to every question, including the straightforward ones, creates a different problem. Support is often a sequence of fast judgment calls, and permanent uncertainty is not the answer.
I agree with this. The skill is not treating every question as uncertain. It is learning to distinguish between the questions where you actually have the answer and the questions where you are pattern-matching from incomplete information.
Password reset procedure for your platform? You know it. Walk them through it without hesitation.
Whether a third-party integration behaves in a specific edge case you have never personally configured? You don't know that. Thirty seconds of verification is correct here, not caution for its own sake.
The discipline is knowing which situation you are in. Not uniformly hesitating. Not uniformly guessing. Actually reading the difference.
The audit worth running
If you manage a support team and this pattern sounds familiar, one quick check tells you whether it is a real problem: pull your same-customer, multi-ticket sequences where a second ticket arrived within 48 hours of the first ticket closing. Read what the second ticket says.
How many of them open with some version of "I tried what your agent told me and it didn't work"?
If it is more than roughly one in ten, you have a verification problem, not a communication problem. The training your team needs is not more empathy scripting. It is the language of uncertainty, and explicit permission to use it.
The follow-up ticket is the real CSAT. It is just the one that never gets measured.
Where I land on this
I have watched very confident agents produce significantly more work for the team than quieter agents who took a few extra seconds on each ticket. The confident agents often got better feedback in the moment. The quieter agents had lower second-ticket rates and smaller escalation queues downstream.
The teams I think work best have explicitly separated these two things: the tone you carry (clear, calm, capable) from the certainty you claim (only what you have actually verified). Both can be high. But they are trained separately, and confusing them is where the expensive habit starts.
Disagree? I'd genuinely be interested in your read, especially if you have seen a team that solved this a different way. Drop me a line.
Comments