- Since 2 August 2026 the EU AI Act requires that people are told they are interacting with an AI system, unless that is obvious to a reasonably observant person.
- Disclosure is not escalation. The Act tells you to say what the thing is; nothing in it designs the exit, and the exit is what customers judge you on.
- Most escalation failures are handover failures, not detection failures. The bot correctly gives up and then hands over nothing.
- Five triggers cover almost every case worth escalating, and three of them need no sentiment analysis at all.
- Where a decision about a person is automated and significant, GDPR Article 22 gives a right to human intervention, which is a stronger obligation than a help desk convention.
The complaint is never "your bot could not answer". Customers are forgiving about that. The complaint is that it would not stop, or that when it finally stopped, the person who arrived asked them to explain the whole thing again from the beginning.
Chatbot escalation is the part of an automated support setup that nobody specifies and everybody experiences. It is also the part that is cheap to get right, because it is mostly plumbing and policy rather than model quality.
What does the law actually require of a shop chatbot?
That the customer knows it is a machine. The EU AI Act's transparency chapter states that providers must ensure AI systems intended to interact directly with natural persons are designed so that those persons are informed they are interacting with an AI system, unless that is obvious to a reasonably well informed, observant and circumspect person in the circumstances.
Two details in that sentence do real work. The obligation sits on the provider of the system, which for most shops means the vendor whose widget you embedded rather than you. And the carve out for the obvious is genuine: a bubble clearly labelled as an assistant, in a context where nobody could think otherwise, is already doing the job. The provision is not asking for a disclaimer on every message.
The European Commission's own summary of the framework puts the same point in plainer words, stating that when AI systems such as chatbots are used, people should be made aware they are interacting with a machine, and that the transparency rules come into effect in August 2026. Timing matters because this is current rather than forthcoming. The published implementation timeline puts the application of the remainder of the Act at 2 August 2026, with a further deadline of 2 December 2026 for providers of systems generating synthetic content that were already on the market. If you switched a chatbot on before August and never revisited the wording in the launcher, that is worth ten minutes this week.
What the Act does not do is tell you when the machine should stop and fetch a person. There is no escalation duty in Article 50. That gap is where the actual customer experience lives, and it is yours to design.
Where a human becomes a right rather than a courtesy
In one specific situation, reaching a person stops being good manners. Where a decision is based solely on automated processing and produces legal effects or similarly significantly affects someone, European data protection law treats it differently.
The right in question appears in Article 22 of the GDPR, which gives the data subject the right not to be subject to such a decision, and, in the cases where automated processing is permitted, requires suitable safeguards including at least the right to obtain human intervention, to express a point of view and to contest the decision.
For most shops this will not describe your returns bot. It can describe an automated fraud block that cancels an order, an automated refusal of a credit or instalment facility, or an account suspension decided by a model. If any of your automation can say no to a customer in a way that matters, the exit to a human is not a nice to have and should not be behind a rate limit. We looked at the receiving end of this in our piece on what you can ask for when a machine scores your loan application, and the same logic runs in the other direction when you are the one deploying the model.
This is a summary of how two published provisions read, not legal advice, and the AI Act interacts with national implementing rules and with existing consumer law. Whether a particular automation falls inside Article 22 depends on facts only you have.
Why do handovers fail when the detection worked?
Because the transfer moves the conversation and leaves the context behind. The bot correctly decides it is out of its depth, drops the customer into a queue, and the agent who picks it up receives a ticket that says "customer needs help" with none of the twelve minutes that preceded it.
From the customer's side this reads as being demoted rather than escalated. They had been making progress, they had supplied their order number twice, and now they are back at the start with somebody who sounds unaware any of it happened. The emotional cost of that is much larger than the cost of the original failure, which is why a shop with a mediocre bot and an excellent handover usually outperforms the reverse.
Good customer support survives a transfer; bad support is recreated by one. Five things have to make it across. The full transcript, not a summary. The customer's identity and the order in question, already resolved. Anything the bot committed to, stated explicitly, because a promise made by your automation is a promise you made. The reason the escalation fired. And a named owner, so the conversation belongs to somebody rather than to a queue.
That third item is the one shops under estimate. If your assistant told a customer their refund would be processed within five days, the agent inheriting the conversation needs to know that before they say anything, because contradicting it is worse than the original error. The question of what an assistant can commit you to is its own subject, and we went through it in detail when considering how an assistant invents a policy that was never yours.
Which triggers are worth wiring?
Five cover nearly everything, and the most reliable ones require no sentiment model at all. Detection is mostly counting.
| Trigger | How it is detected | Needs a model? | Why it earns its place |
|---|---|---|---|
| Customer asks for a person | Intent match on a short phrase list | Barely | Refusing this is the single most resented behaviour |
| Two failed attempts at the same thing | Repetition counter in the session | No | Catches the loop before the customer leaves |
| Topic is on the forbidden list | Classifier or keyword on a fixed list | Optional | Legal, safety, payment disputes, data requests |
| Money above a threshold | Order value lookup | No | Bounds your worst case to a number you chose |
| Distress or anger in the message | Sentiment classification | Yes | Catches what the other four miss, imperfectly |
Notice how much of that is arithmetic. A repetition counter and an order value threshold are an afternoon of configuration and they catch the two situations that produce complaints. Sentiment is the fashionable one and it belongs last, because it is the least reliable and the easiest to tune into either uselessness or constant firing.
Should the bot ever refuse to hand over?
No. Rate limiting the exit is a false economy that converts a support cost into a reputation cost, and it is the behaviour customers describe when they say a company is impossible to reach.
The legitimate version of the worry is volume, and the answer to volume is not friction at the exit. It is fixing the reason people are asking. If 40% of your escalations are the same question, that question belongs in the help centre or on the product page, which is the argument we made for building a help centre out of the tickets you already have. Suppressing the request hides the signal that would have told you what to fix.
What to do when there is no human available
Say so, honestly, and convert the conversation into something asynchronous that a person will definitely see. The worst outcome is a bot that pretends a transfer happened into a queue nobody is watching at eleven at night.
For a one person business this is the whole problem, because the human is you and you are asleep, on a delivery run, or with a customer. Three arrangements work, and all of them are better than a silent handover.
State the hours and take a message. "Nobody is here until nine tomorrow. I have saved everything you told me and Sara will reply to this email first thing." That is an honest answer and it closes the loop. It needs the message to actually arrive somewhere you read.
Offer a callback slot rather than a queue. A specific time is a commitment the customer can plan around. An unspecified wait is not.
Give the bot a narrow set of things it may settle unilaterally. A refund under a value you set, a resend of a lost order, a correction of a delivery address before dispatch. Deciding this in advance is more useful than any escalation logic, because it removes the category of cases that needed a person only to approve something you would always have approved. Our walk through of which refund and return requests software can actually settle is the version of this exercise for the most common case.
The escalation you will see most, and why it is not a bot problem
Where is my order. It will be the largest single category in your escalation log, and almost none of it is caused by the assistant being weak. It is caused by the assistant not being able to see the answer.
Work through what the question actually requires. The customer wants to know where a physical object is right now. That lives with the carrier, in a tracking system your bot may or may not be connected to, updated on a schedule nobody controls, and expressed in status codes that mean less than they appear to. "In transit" covers both a parcel moving normally and a parcel that has been sitting in a depot for four days.
If your assistant is connected to order data but not carrier data, it can confirm dispatch and nothing more, which is exactly the information the customer already has from your confirmation email. So it escalates, and a human does the same lookup by hand. Connecting the carrier feed removes more escalations than any amount of prompt tuning, and the measurement that reveals this is the trigger mix rather than any judgement about answer quality.
The same structure shows up in the second and third most common categories. Stock questions on an item marked available need the real stock figure, not the catalogue one. Sizing questions need the measurements rather than the size label. In each case the fix is a connection, not a cleverer model, and this is the general rule worth carrying away: escalation volume is usually a map of what your assistant cannot see.
What about customers writing in another language?
Handover is where multilingual support quietly breaks, because the bot handles the conversation competently in Portuguese and then transfers it to somebody who does not read Portuguese. Decide this before you enable extra languages rather than after.
The workable arrangement is to let the assistant translate in both directions after handover, with the original text kept alongside the translation so the human can see what was really said. What does not work is a bot that converses in six languages feeding a queue that operates in one, because the customer experiences a sudden and unexplained change in competence. Our notes on where machine translation of your shop drifts away from your meaning apply with more force in a live conversation than on a product page, since nobody is proofreading.
How do you know whether your handover is any good?
Measure three things across your escalated support tickets, none of which is the deflection rate your vendor reports. The deflection number tells you how many conversations ended without a human, which counts an abandoned customer as a success.
Escalation latency. The time between the trigger firing and a person actually replying. This is the number customers feel. If your dashboard reports queue time from ticket creation, check whether creation happens at the trigger or at pickup, because those differ by exactly the interval you are trying to measure.
Repeat explanation rate. Of escalated conversations, how many contain the agent asking for something the customer already told the bot. Sample twenty by hand each month. This is the cheapest quality measure in support and almost nobody runs it.
Trigger mix. Which of the five triggers fired, as a distribution. A sudden rise in the repetition trigger means the bot got worse or your catalogue changed under it. A rise in explicit requests for a person usually means trust went down. The mix is a leading indicator in a way the volume is not.
We have argued before that the resolution rate a support vendor quotes counts silence as success, and the escalation metrics above are the honest counterweight. They are harder to put on a slide, which is precisely why they are worth your own time.
The design question underneath all of this
Is the assistant a filter in front of you, or a colleague alongside you? Shops answer this implicitly and then wonder why the experience feels wrong.
A filter is designed to reduce contact. It is measured on deflection, it treats escalation as leakage, and it optimises toward the customer giving up. That design makes sense for an organisation drowning in identical queries and it makes very little sense for a small business, where contact with a customer is not a cost centre but most of the relationship.
A colleague is designed to arrive with the work already done. It gathers the order number, pulls up the history, drafts the reply, and hands you something you can approve in fifteen seconds. Escalation is not a failure in this model, it is the normal path, and the bot is measured on how much time it saved you per conversation rather than on how many it prevented.
For a business of one or two people the second framing is almost always correct, and it changes what you should buy. A tool evaluated on deflection will fight you. One built to prepare and assist, the way we think about AI agents working inside a shop, is doing a job that scales with you instead of standing between you and the person who wants to buy something.
A short checklist before you switch anything on
Write the forbidden list first. The topics your assistant must never attempt: payment disputes, anything legal, data access or deletion requests, safety questions about a product, anything involving a minor. Fixed list, checked before the model runs, not a matter of judgement.
Decide the unilateral authority. One number for refunds, one for replacements, and a written note of what the bot may promise about timing. Everything outside it escalates.
Test the handover by being the customer. Open your own chat, get stuck on purpose, ask for a person, and see what arrives on the other side. Most owners discover the transcript does not come through on the first attempt.
Check the label. Make sure a reasonably observant visitor can tell within one screen that they are talking to software, and that your vendor has not quietly changed the launcher text in an update.
Then leave it alone for a month and read twenty escalated conversations end to end. Not the summaries. The conversations. Everything useful you will learn about this is in those twenty, and no dashboard will surface it for you.