Human handoff

What is a human handoff?

A human handoff is the moment an AI assistant stops and gives the conversation, or the task, to a person. Up to that message the customer was chatting with a bot. From the next one, a colleague is typing. The same move happens out of sight in a back office: an agent cannot match a payment to an invoice, so it drops the case into someone's queue with a note.

This is not the same thing as human-in-the-loop, which has its own entry here. There, a person approves an action before the system carries it out, and control goes back to the machine afterwards. A handoff runs the other way. The machine lets go, and the person owns the case from that point on.

Almost every assistant needs one, because there will always be questions it should not answer and customers who want a human. It is also the part people remember. Customers rarely recall what the bot said. They recall whether they had to tell the whole story a second time.

What triggers a handoff

You need two kinds of trigger: rules you write down, and judgements the model makes in the moment.

Microsoft splits them by who starts it. In Copilot Studio an implicit escalation happens when the customer types something like "talk to a representative", or when the assistant cannot match the question to any topic and falls back. An explicit escalation is one you designed: a topic you decided needs a person, with a transfer node in it.

Intercom's Fin escalates by default in three situations: the customer clearly asks for a human, the assistant detects strong frustration or anger, and the customer is stuck in a repetitive loop. You can add rules on data you already hold, so a negative sentiment attribute, an order above a set amount or a customer flagged as VIP goes to a person without the assistant answering first.

The triggers most companies end up writing down themselves:

• The never-automate list. A complaint about a named employee, anything legal or medical, a cancellation, a safety issue, a death in the family. Write that list before you launch, not after the first incident.

• Low confidence or no source. When a retrieval-based assistant finds nothing in your documents, the honest move is to say so and offer a person, not to improvise.

• The customer repeating themselves. The same question rephrased twice means the answer did not land, whatever the model scored it.

• A turn limit. After eight or ten exchanges without a resolution, hand over. A long conversation with a bot is rarely a good one.

Treat sentiment as a late signal rather than an early one. By the time a model reads anger in the wording, the customer has usually already asked for a person once.

What has to travel with the conversation

A handoff that arrives empty only moves the work. Four things go with it.

The transcript. Copilot Studio sends the whole conversation to the connected engagement hub together with the variables collected along the way, merged across topics when the customer passed through several before escalating. On an escalated call, Zendesk's AI agents post the transcript and a summary onto the ticket to prepare for the handoff, along with any fields the flow filled in. The same principle governs machine-to-machine handoffs: in OpenAI's Agents SDK the receiving agent sees the entire previous conversation history unless you install a filter to trim it.

What the assistant already tried. The answers it gave, the article it linked, the lookup it ran, and anything it could not verify. Without this, your colleague repeats the failed step. The transfer node in Copilot Studio carries a private message to the live agent for exactly this, an internal note the customer never sees, alongside the last topic and the phrases the customer used.

Who this is and which case it belongs to. The customer record, the order or ticket number, the conversation id. Someone who has to ask for an order number the bot repeated back two minutes ago has lost the conversation before it starts.

A summary at the top. Nobody reads forty turns while a customer waits. Three or four lines: what the customer wants, what has been established, what is still open, what was promised. Generate it, and keep the transcript underneath so the colleague can check it.

Queues, availability and what the customer sees

The trigger fires. What happens next has little to do with AI and everything to do with how your support desk is run.

Check availability before you offer. Zendesk's AI agents can look at a team's business hours and whether anyone is online before deciding what to offer, with different hours per region. Inside hours the conversation moves to messaging and someone picks it up live. Outside hours the assistant collects what it needs and raises an email ticket instead. Zendesk also tells you to put escalation options at the points where the dialogue would otherwise leave a customer at an empty block with nothing to do next.

Intercom is explicit about the failure case. If no human routing target is configured, Fin does not offer escalation at all and the conversation ends with a "get more help" outcome. An offer that leads nowhere is worse than no offer, but that is a setting somebody has to get right.

While the customer waits, a stated waiting time is bearable and an endless spinner is not. There also has to be a way out at every point: leave an email address, book a callback, walk away with a ticket number.

One legal note. The bot half of the conversation falls under the transparency duty in Article 50 of the EU AI Act, which requires people to know they are dealing with AI; the transparency obligation entry covers what that means in practice. The handoff message is the natural place to close the loop the other way, by naming the person taking over.

What this looks like without a contact centre

A company with four people on support does not need routing software. It needs one shared inbox or channel where escalated conversations land, with a name against it each day. It needs a rule for office hours, so the assistant offers a live handover between nine and five and takes an email address after that. And it needs a fixed template for the summary the assistant writes, so every escalation arrives in the same shape. The template costs an afternoon and saves the most.

Handing back, and warm versus cold

The reverse direction is the one people forget to build. A colleague sorts out the hard part, and the routine follow-up afterwards should not need them again. Zendesk names both moves: handoff removes the AI agent as the conversation's first responder and makes a person the first responder, while handback removes the live agent so the AI agent can respond again when the customer starts a new conversation. Their handback fires when the ticket moves from Solved to Closed, with four days between those states by default, during which a returning customer with an unrelated question still lands on the human.

The quality of a transfer has a name from the telephone world, and one dimension separates the two versions: what the customer has to repeat.

Cold handoff. Genesys calls this a blind or one-step transfer, passing the call on without explaining the reason for it. In chat it is a ticket that appears in a queue with the subject "chat escalation" and nothing under it. The customer starts over, and so does the colleague.

Warm handoff. A two-step transfer made with an acknowledgement, so the person receiving it knows why it came. In chat that means the assistant says what it is doing and to whom, the transcript and the summary arrive with it, and the colleague opens with a sentence proving they already know. The customer repeats nothing.

Cold is cheaper to build and it is what most integrations give you by default. The gap the customer feels is one paragraph of text and one availability check.

The same case, done twice

A plumbing supplier sells a circulation pump online. It arrives with a cracked housing on a Friday afternoon, and the customer needs it for a job on Saturday.

The bad version. The customer describes the damage. The assistant replies with the returns procedure and a link to the form. The customer writes "I need someone now". The assistant repeats the returns procedure in different words. The customer writes "human". The assistant shows a line about office hours running Monday to Friday, nine to five, and the window closes. It is 16:40 on a Friday, inside those hours. On Monday the customer mails, and the ticket holds only that mail. A colleague asks for the order number the assistant already had. The customer tells the story a third time.

The good version. Same assistant, same opening replies. When the customer writes "damaged, and I need it before Saturday", two rules fire: damage on delivery sits on the never-automate list, and a deadline inside 24 hours raises the priority. The assistant checks availability, sees support online for another twenty minutes, and writes one line: "I'm passing you to Lien in customer service, she can see everything you told me." Into the ticket goes a four-line summary: order number, delivered yesterday, cracked housing with the photo attached, two units in stock in Genk, no delivery date promised. Lien opens with "I see the pump arrived cracked, and we have two in Genk". The customer repeats nothing and a replacement goes on the evening run.

The technology is identical in both versions. What separates them is a written trigger, a summary template, and a check for whether anyone is actually there.

What to measure, and the number that lies

Four numbers tell you whether your handoffs work.

1. Handoff rate. The share of conversations that reach a person. Microsoft's guidance uses the mirror image, deflection, and splits escalations into direct ones, where the customer simply asked for a human and you cannot design that away, and indirect ones, where something in the conversation pushed them there. Only the second group is a to-do list.

2. Time to first human reply, counted from the handoff and not from the start of the chat. That is the wait the customer actually feels.

3. Resolution after handoff. Of the conversations a person picks up, how many end solved and how many come back within the week. A handoff into a queue nobody works is a slower way of refusing help.

4. How often the customer repeated themselves. No tool reports this. Read twenty escalated transcripts a month and count.

Then the trap. Handoff rate is the easiest number here to improve dishonestly, because it drops every time you make a person harder to reach: bury the button, add a confirmation step, skip the offer outside office hours, let the assistant try one more answer before giving in. The rate falls and the experience gets worse. Microsoft's advice to bring escalation down is aimed at the topics where the assistant genuinely could have answered, which you find by reading transcripts one topic at a time. Read handoff rate next to resolution after handoff and repeat contacts, and it stops lying to you.