AI Chatbot Customer Support: Escalation Rules

Define when the bot must stop, what context a human receives and which actions remain unavailable to the model.

Why escalation rules come first

Most chatbot projects start with the questions the bot can answer. The better starting point is the list of situations where it must not try. A bot that handles delivery queries well but keeps a distressed customer in a loop for twenty minutes has failed, whatever the deflection rate says.

The Competition and Markets Authority's guidance for businesses using AI agents makes the legal position plain: consumer law applies in the same way whether a customer deals with a person or a bot, and using a vendor's product does not move responsibility to the vendor. Escalation rules are how you keep that responsibility in your own hands.

The escalation checklist

Write these as rules the bot follows, not as guidance it interprets. Each one should be testable.

1. The customer asks for a person. Once is enough. Do not require the customer to ask twice or to explain why. A second bot reply after a clear request is a complaint waiting to happen.
2. The bot is not confident. If the answer is not grounded in an approved source, or two sources conflict, hand over. A fluent guess about a returns window is worse than "I will pass this to the team".
3. Signs of vulnerability. Mentions of bereavement, illness, financial difficulty, disability or distress. The bot does not need to diagnose anything. It needs to stop and route to a person with the right training.
4. A complaint. Any message that expresses dissatisfaction with the business, not just the product. Log it as a complaint at the point of handover so it enters your complaints process on time.
5. Money and rights. Refund requests outside the automatic rules, cancellations near renewal, faulty goods, and anything where the customer states a legal right. Our note on keeping human approval in refunds covers the financial side.
6. Account security. Password resets, changes to contact details, payment details or delivery addresses, and any request that starts with "I am calling on behalf of". These are the paths a fraudster uses.
7. Repeated failure. Two consecutive turns where the customer restates the same question. The bot has not understood. Stop.
8. Anything outside the approved scope. Legal advice, medical questions, comments on competitors, or a topic with no approved source.

What the human receives

A handover that arrives as "customer needs help" wastes the customer's time twice. The agent should receive, in one view:

• the full transcript, with the bot's messages clearly marked;
• the trigger that caused the escalation;
• the customer's account and order references the bot has already collected;
• any action the bot took or proposed; and
• the priority, so a vulnerability trigger is not queued behind a delivery query.

Tell the customer what is happening. "I am passing this to a colleague who will reply within two hours" is a promise the business must be able to keep. Do not describe the handover as "a specialist" if it is a queue.

Actions the model never takes

Some actions should not be available to the bot at all, whatever the conversation. Keep them behind a permission the model does not hold rather than a rule it is asked to follow:

• issuing refunds or credits above the automatic threshold;
• changing bank, card or address details;
• closing accounts;
• promising compensation or goodwill gestures;
• sending anything to a third party; and
• stating that a complaint is resolved.

The difference matters. A rule in a prompt can be talked around by a determined customer or an injected instruction. A missing permission cannot.

Test the rules before launch

Build a test pack of at least twenty conversations that should trigger each rule, including messy versions: a complaint buried in a delivery question, a vulnerability signal in passing, a request for a person phrased as "is there anyone else I can talk to". Run it before launch and again after every prompt, model or knowledge change.

Measure the outcomes that matter: time from trigger to human reply, escalations that should have happened but did not, and customer messages after an escalation that suggest they were still stuck.

Own it after launch

Name one person who owns the escalation rules and can change them without a software release. Review a sample of escalated and non-escalated conversations weekly for the first three months. Set a stop condition, for example moving all complaints to a person if the bot misses one in a review.

The customer support AI workflow page describes how we set up the approved sources, handover paths and review loop for a small support team.

Source basis

• Competition and Markets Authority: complying with consumer law when using AI agents
• ICO: guidance on AI and data protection