A good handover has three parts: the agent spots a trigger early, tells the customer what happens next and how long it may take, and passes a note so nobody asks the customer to repeat themselves. Then it goes quiet. Each handover records its trigger, so you can check whether the agent let go at the right moment.
What is a chat handover, and who owns it?
Every AI chat agent eventually meets a conversation it should not finish. The customer asks for a person. The request is outside its bounds. The customer is upset, or vulnerable, or the agent has misunderstood twice. A handover moves the conversation to a person in the same chat window, ideally without a gap, a lost transcript or a customer starting again.
Support operations owns handover rules and queue staffing. Team leaders own response times for handed-over chats. The agent owns noticing and passing on. Our guide to the AI support agent that knows when to say no makes the case that knowing when to stop is the agent's most important skill, and how should a support agent hand a conversation to a person? gives the short answer.
What are the steps, and at what depth?
- Person, support operations: defines triggers. A request for a person; any refused or held verdict the customer is waiting on; vulnerability or distress; anger that is rising; two failed attempts to understand; failed authentication; complaints; anything legal.
- Agent, depth 1: watches for triggers on every turn, not just at the end of a flow.
- Agent, depth 3: tells the customer. What is happening, why in plain terms, and the expected wait, taken from the live queue. "I'm passing you to a colleague who can look at the refund. The wait is around ten minutes. You can stay here or ask us to email you."
- Agent, depth 2: writes the handover note. Who the customer is and whether they are verified, what they want, what was already said and tried, the trigger, and anything sensitive the person should know first. The handover note template from an AI agent to a person sets out the fields.
- Agent, depth 3: transfers to the queue for the trigger type, with the note and transcript attached.
- Agent, depth 3: keeps the customer informed while they wait, at set intervals, without trying to resume the conversation.
- Agent, depth 3: offers the fallback if no person is available in time: a callback, an email reply, or a ticket with a clear timescale.
- Person, adviser: picks up, reads the note, and opens with what they already know.
- Agent: stops speaking once the adviser joins, unless the adviser asks for its help in an assist mode.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Triggers | Nothing | none | Defining them |
| Watch | Checks each turn | 1 | Nothing |
| Tell | Explains and gives wait | 3 | Nothing |
| Note | Writes handover note | 2 | Reading it |
| Transfer | Routes by trigger | 3 | Queue staffing |
| Wait | Updates the customer | 3 | Nothing |
| Fallback | Offers alternatives | 3 | Callback or reply |
| Pick up | Nothing | none | Adviser continues |
Which controls matter, and what evidence does each leave?
A request for a person is always honoured. The agent may say what it can do, once, but it does not argue. Evidence: time from request to transfer.
Trigger recorded. Every handover names the reason. Evidence: trigger field on each transfer.
Note before transfer. The adviser never receives a bare chat. Evidence: the note attached to each handed-over conversation.
Honest waits. The expected wait comes from the queue, not a fixed script. Evidence: quoted wait against actual wait.
Silence after pick-up. Two voices in one chat confuse customers. Evidence: no agent messages after the adviser joins, unless in assist mode.
What should you measure?
- Time from trigger to a person's first message.
- Customers who leave while waiting, by trigger and time of day.
- Questions repeated after handover. Each one is a note that failed.
- Late handovers: conversations a reviewer judges should have been handed over earlier, often after anger or a second misunderstanding.
- Handovers by trigger, over time. A rising share for one topic points to a gap in the agent's sources or bounds.
Where does it usually go wrong?
The agent tries one more time. It wants to resolve the chat and keeps going after a trigger. The customer ends up angrier. Hand over at the trigger.
The note is the transcript. Pasting forty messages is not a note. The adviser needs the summary first.
The handover lands with the wrong team. A billing question goes to general support, which transfers it again. Each extra transfer costs the customer time and patience. Route by trigger and topic, and measure how often handed-over chats are transferred a second time.
The wait is a guess. "Someone will be with you shortly" when the queue is long breaks trust. Use the live figure.
Out of hours, the handover goes nowhere. Transfer to an empty queue strands the customer. Offer the fallback.
Channel switches lose the thread. The customer is asked to call instead and starts again on the phone. If you switch channels, carry the note; can one AI support agent work across email, chat and phone? covers what that takes.
The technical transfer fails silently. The platform drops the chat between queues. Test transfers under load; the configuration side is in how to let an AI agent hand a chat to a person in your live chat tool and how to connect an AI agent to your live chat platform.
Questions people ask
Should the agent say why it is handing over?
Yes, in plain terms. "This needs a colleague who can approve refunds" is better than a vague "let me transfer you". Avoid exposing internal flags, such as a fraud signal.
Can the adviser hand the chat back to the agent?
Some teams allow it for routine follow-up, such as sending a confirmation. The adviser decides, and the customer is told.
How do we judge whether handovers are well timed?
Review a sample against the triggers, and read conversations where the customer asked for a person after a long exchange. Those usually show the trigger the agent missed.