Loading
It says so and offers a person. An agent that guesses is worse than no agent, because a confident wrong answer costs more than a missed call.
Published February 17, 2026
Every deployment discovers questions nobody anticipated. The interesting design decision is not how to eliminate them, which is impossible, but what should happen when one arrives.
The agent should say it does not know and offer to have a person follow up. That is not a degraded outcome, it is the designed one, and it is better than every alternative.
The alternative people imagine they want is an agent that has a go. The problem is that a plausible-sounding wrong answer costs far more than an admission of ignorance. The customer acts on it, discovers it was wrong later, and now you have both the original problem and a trust problem. A missed call is recoverable. A confidently incorrect commitment about a refund window is not.
This is where the value is. The agent logs the questions it could not answer, which gives you something most support operations never had: a clean list of the gaps in your own documentation, ranked by how often customers hit them.
In the first two weeks this list is long and that is normal. It shortens quickly, because each entry has an obvious fix: write the answer down once, and the agent has it from then on. Teams that work this list weekly see the escalation rate fall steadily. Teams that ignore it see the same handful of gaps forever.
The moment it says it does not know is the moment the experience is most at risk, so the handoff matters more than the average interaction.
It should say plainly that it cannot answer, say what will happen next, give a timeframe, and pass the full thread to whoever picks it up. The customer should not have to repeat anything. Being told 'I don't know, but Sarah will call you before noon and she'll have everything you've told me' is a perfectly good outcome.
As documentation grows, the range of things the agent will attempt grows with it. That is intended. What needs watching is the boundary: has something been added that lets it answer a question it should still be escalating.
Reviewing the escalation rate is the practical check. If it falls faster than you added documentation, something is being answered that should not be, and the transcripts will show you what.
On the site
Keep reading