When an agent should hand the case to a human
The longest part of an implementation is not building the agent. It is agreeing on what the agent does not do. That is a conversation with the team, not a technical task, and its quality decides whether anyone still trusts the system a month later. Below: five escalation triggers we settle before the pilot starts, the rules for a good handover, and the two mistakes we see most often — one at each end of the scale.
- Escalation is not a system failure. It is a designed path, and the most important part of the rules.
- An agent that escalates too rarely costs more than one that escalates too often.
- A case handed to a human has to arrive with context, otherwise the implementation moves work around instead of taking it away.
Five triggers worth agreeing on before you start
Each one can be written as a rule and tested against historical cases before the agent touches live traffic.
Low answer confidence. The agent found no clear support in the data, or the sources contradict each other. You set the threshold on a historical sample: what matters is how many cases land on a human at a given threshold, and how many of them genuinely needed one.
Financial consequence above a threshold. A discount, an invoice correction, a complaint approved above an agreed amount. The threshold is a business decision, not a technical one — and usually the shortest part of the conversation, because companies already have one for people.
An unusual or new case. The enquiry does not fit any known category. The agent does not guess the category; it hands the case over with a description of what it failed to recognise, and a new category gets added deliberately.
Emotional signals or a threatened escalation. The customer is clearly unhappy, mentions cancelling, mentions a lawyer, or is writing for the third time about the same thing. These go to a human no matter how simple the message looks.
Data that does not add up. The status in the ERP contradicts what the customer is saying, or the record is missing entirely. The agent does not resolve contradictions like that — it flags them, because they usually point to a data error that needs attention in its own right.
A handover that does not create new work
An escalation that amounts to forwarding an email to the team with a note saying "not sure" is worse than having no agent, because it adds a step. A case handed to a human should arrive complete: what the agent understood, what it found in the systems, which threshold it did not cross, and what its proposed answer would be. Then a person decides in under a minute instead of starting from zero.
The second condition: the human decision has to feed back somewhere. If the team corrects the agent in the same situation every week and nobody writes that into the rules, the implementation stands still. Reviewing escalations weekly for the first month, then monthly, is enough to make the exception list shrink instead of grow.
The shift in thinking that most affects whether the team adopts the system. An agent that admits uncertainty earns trust faster than one that always has an answer.
The two extreme mistakes
The first: the agent escalates everything that is not obvious. The team gets 60% of cases back, the implementation saves no time, and a month in someone reasonably asks what the point was. This usually comes from a confidence threshold set too high "just in case", and it is fixed by measurement: how many escalated cases did a human close without changing the agent's proposal at all.
The second, and more serious: the agent almost never escalates, because there are no triggers for unusual cases. It looks excellent in the statistics — a high share of cases handled without help — right up until the first badly handled case at an important customer. The cost of that one case can wipe out a quarter of savings, and rebuilding the team's trust takes longer than the implementation did.
Frequently asked questions
What share of escalations is normal?
It depends on the process, and there is no single right number. At the start of a pilot it is high, and that is fine — it drops as rules get added. The direction matters more than the level: if it is not falling after a month, the problem is in the rules or the data, not the threshold.
Who decides the monetary thresholds?
Whoever approves those decisions in your company today, usually a department head. We do not set those thresholds for you; we move the ones that already apply to people into the rules and write them down explicitly.
Does the customer know the case went to a human?
Usually they do not need to, and they see no difference beyond response time. If a case needs longer review, the agent sends an acknowledgement with a deadline — better than silence, and one of the easier things to settle in the rules.