An assistant that never hands over becomes a wall between your customer and your business. One that hands over constantly is an expensive routing layer. The boundary between them is a design decision, and it should be made explicitly rather than emerging from whatever the model happens to do.
Triggers, defined in code
Leaving escalation to the model judgement is unreliable in both directions. Define the triggers.
Explicit request. The customer asks for a person. This should always work, immediately, and the path to it should be visible rather than hidden behind three attempts to deflect.
Topic boundary. Define categories outside the assistant's scope and route them to the appropriate person. A classifier can help recognise them, but its decision is also fallible. Keep restricted actions unavailable through tool permissions even if classification misses the topic.
Repeated failure. The customer has rephrased the same request twice and not got what they needed. This is the strongest signal available and it is routinely ignored. Two failed attempts on the same intent should hand over.
Low confidence. Where retrieval returned nothing relevant or the classification confidence is below a threshold, hand over rather than generating something plausible.
Value threshold. Any action above a monetary or operational threshold gets a person, regardless of how confident anything is.
Sentiment. A customer who is clearly angry is not a customer to keep in an automated flow. This one is worth being generous with.
Carry the context
The failure that undoes the value of the whole system is a handover where the person starts from nothing and the customer repeats everything.
The escalation should deliver the relevant conversation, permitted customer context, what the assistant tried and any action it prepared or took. Restrict access and exclude unrelated personal information. A person should be able to continue without receiving an unrestricted copy of every record the assistant could access.
Done well, this makes the assistant valuable even on the requests it cannot handle, because it has done the gathering.
Prepare rather than perform
A useful middle position between full automation and full handover.
The assistant determines what should happen, prepares it, and holds it for approval. The refund is calculated and ready. The reschedule is set up. The reply is drafted with the account details filled in.
A person reviews the proposal against its supporting evidence and decides whether to release it. Measure that review effort rather than assuming it is trivial. The preparation can be automated while authority remains with the responsible person.
The cost of handing over too late
Businesses tune escalation to minimise handovers because handovers cost money. That optimisation reliably goes too far.
A customer who spends four minutes with an assistant that cannot help them and then reaches a person is more expensive than one who reached the person immediately, because they are now also annoyed, and the agent spends the first two minutes on that rather than on the problem.
The metric to watch is not the containment rate. It is the resolution rate combined with the time to resolution across both paths. An assistant that contains seventy percent and takes four minutes to fail on the rest may be worse than one that contains fifty percent and hands over in twenty seconds.
Tell the customer what they are talking to
Not a legal point, a practical one. People adapt their behaviour when they know. They ask more directly, they do not test it, and they are considerably less annoyed when it cannot help, because they were not misled.
Pretending to be a person produces a worse experience the moment the illusion breaks, and it always breaks.
Review the transcripts
The escalations are where the improvement comes from. Read them, categorise what the assistant could not handle, and decide case by case whether it should be able to.
Some become new capabilities. Some are correctly outside scope and stay there. Either way the decision is informed by what customers actually asked rather than by what the team imagined they would.
Make the queue accountable after the assistant stops
An escalation is not complete when a webhook is sent. Record whether the receiving queue accepted it, assign an operational role and expose its current state. If the queue is unavailable, retain the work durably or give the customer a truthful alternative. Never display that someone is reviewing a request when no receiving system has accepted it.
Tell the customer what will happen next without inventing a response deadline. The interface can confirm that the request was recorded, show a reference and identify the available contact route. If live assistance is not available, say that rather than leaving a typing indicator running indefinitely.
Avoid restarting automation on the same issue while a person is handling it. A conversation state such as awaiting review can suppress automatic replies without preventing the customer from adding information. When a person resolves the case, their closing action should explicitly decide whether the assistant may resume or the thread should remain closed.
Test a handover with a dropped acknowledgement. The receiving queue may have created the case even though the assistant timed out. Retry using the same escalation identifier and verify that only one case exists. Then test an unavailable receiving queue and a customer asking for status before assignment. These paths determine whether the handover is an operational feature or merely a reassuring sentence.
Give staff a way to correct an inaccurate assistant summary without rewriting the original conversation. Keep the correction visible to the next reviewer, so an early misunderstanding does not become the accepted account of what the customer requested.