Every AIVA deployment has one question at its centre that's rarely asked out loud: when should a human take over?
Get this wrong in one direction and the agent routes everything to a person, producing no efficiency gain at all. Get it wrong in the other direction and it handles things it shouldn't, producing angry customers who feel they were denied a human when they needed one.
Getting escalation right is the single biggest determinant of deployment success:
- bigger than latency
- bigger than accuracy
- bigger than the number of languages you support
Here's how we think about it.
(If you're evaluating vendors rather than configuring one, the buyer's version of this is shorter and less technical.)
The wrong way to think about escalation
The most common failure mode is configuring the agent to escalate when it's uncertain about an answer.
The intuition is reasonable: if it doesn't know something, send it to a human who does. In practice this creates a system that handles only the most routine queries — the ones a FAQ page could answer — and routes everything moderately complex to agents. You've built an expensive FAQ search engine and paid for a voice stack to run it.
The problem is that the agent's value isn't just knowing answers. It's handling the conversation:
- managing the back-and-forth
- gathering context
- pulling data from systems
- executing actions
It can handle a complex query it doesn't immediately know the answer to by asking clarifying questions, fetching relevant data, and reasoning toward a resolution. It should do that, not escalate.
Escalation is not a solution to the agent not knowing something. It's a solution to specific human requirements the agent can't meet.
This distinction showed up starkly in our own churn data. Of the customers we've lost, a third had misconfigured escalation this exact way — threshold set so low that the agent added a step to every call without removing any work.
When to actually escalate
We've found three categories that genuinely require human involvement.
Emotional distress. When a customer is upset — genuinely upset, not mildly frustrated — the conversation needs a person.
AIVA detects distress signals: tone indicators in voice transcription, specific emotional language patterns ("this is unacceptable," "I want to speak to a manager," "I've been waiting for weeks"), and repeated unsuccessful resolution attempts in a single session.
When these fire, we escalate immediately, regardless of whether the underlying query is one the agent could technically handle.
The reason: an upset customer isn't asking a question. They're expressing a feeling. AIVA is very good at answering questions. It is not a substitute for a human who can acknowledge that someone's week has been ruined.
More on the specific mechanics in how AI handles an angry customer on the phone.
Legal, compliance, and account security. Anything involving authentication beyond standard verification, billing disputes over a configurable threshold, fraud concerns, legal requests, and regulatory queries. These require human judgment, human accountability, and in many cases documented human decision-making.
Explicit human request. If a customer says they want to speak to a person, they get a person. We don't try to talk them out of it, and there's no deflection loop. We confirm the transfer and hand off.
This one isn't only a courtesy position — it's increasingly a legal one. GDPR Article 22 establishes a right to obtain human intervention in automated decision-making, and the direction of travel in most jurisdictions is the same. Building an agent that resists handing over is building toward a compliance problem as well as an angry caller.
The three escalation triggers — emotional distress, compliance and legal, explicit request — are baked into every AIVA deployment and aren't configurable to off. They exist because getting them wrong has consequences that outweigh any efficiency gain.
The middle zone: complexity without escalation
Between "the agent can handle this" and "this needs a human" sits a large category of complex queries that should be handled, not escalated.
A customer who wants to reschedule an appointment, check insurance coverage, get directions, and confirm the fee structure is asking four things, not one. It's complex. It's not emotional — unless handled badly. AIVA can work through it with the right integrations, the right configuration, and the right patience.
The rule we use internally: escalate for who the customer needs, not for what they need. Most complex queries still just need an answer. Complex ≠ human.
The case that taught us this most expensively is written up separately in the ticket that changed how we think about escalation.
What a good handoff looks like
Deciding to escalate is half the job. The other half is what the human receives.
A handoff that dumps a cold call on an agent with no context is barely better than a transfer to the switchboard — the customer repeats their whole story, which is exactly the experience that made them ask for a human in the first place.
Every AIVA escalation carries the full conversation, the data the agent already retrieved, and the reason the handoff fired.
The practical test: your agent should be able to open with "I can see you've been trying to reschedule Thursday's appointment" rather than "how can I help you today?"
The two failure signatures
When escalation is misconfigured, it shows up in the logs as one of two recognisable shapes. Learning to spot them is most of the calibration work.
Escalating too eagerly looks like a high handoff rate concentrated in a small number of intents, with short pre-handoff conversations. The tell is the duration: transfers happening in under twenty seconds mean the agent isn't attempting resolution at all, it's triaging.
Human agents in this state report that the transfers feel pointless, which is the most reliable diagnostic available and the one nobody thinks to ask for.
Escalating too reluctantly is harder to see, because the number that looks wrong — handoff rate — looks good. The signal is in what happens after: repeat calls from the same number within a day, conversations that run long without resolving, and callers asking for a person more than once in a single session. That last one should be near zero.
If callers are having to ask twice, the agent is negotiating when it should be transferring.
The asymmetry matters: the first failure wastes money and the second one loses customers, usually quietly. If you're going to be wrong for a week, be wrong in the first direction.
Calibrating for your context
Every deployment needs its own calibration. A healthcare company's triggers differ from a logistics company's. The right distress threshold for a lending platform is not the right one for a fashion retailer.
We recommend a two-week calibration period reviewing escalation logs daily. Look for patterns in both directions: query types escalating that the agent should handle, and situations where it didn't escalate but should have.
The analytics dashboard breaks escalations down by trigger and intent so this is a reading exercise rather than an archaeology one, and our KPI guide covers what else to watch alongside it.
The goal isn't zero escalations. Some escalations are correct — a deployment with a 0% handoff rate is one that's failing distressed customers silently. The goal is that when the agent escalates, the human gets a call that actually needed them.
That's also why escalation rate should always be read next to resolution rate rather than on its own. Either number alone can be gamed; together they describe whether the system is genuinely working.
Configuration details are in the docs, or you can watch how it behaves on your own traffic — start free with ₹500 of credit and see what your first week of escalations looks like.