AI chat handoff to a human agent

Decide who catches the conversation before you decide what fires it. Almost every handoff that fails, fails at the far end, in a queue nobody agreed to open.

Somewhere in your settings there is a list of checkboxes labelled something like escalation triggers, and it is the first thing anybody configures, because checkboxes invite you to tick them. The destination — the inbox, the alert, the actual human being — tends to get decided weeks later, usually after a customer has spent an afternoon waiting in a queue nobody opened. Do it in the other order. Work out who catches the conversation and how they find out it is waiting, and the trigger list mostly writes itself once a real name is attached to the far end. Everything below assumes somebody is there to catch it; what the assistant should say during the hours when nobody is belongs to the out-of-hours setup.

Design the destination first

A flag raised in a dashboard is not a handoff. It is a record that a handoff should have happened, written somewhere your team opens on Tuesdays. If the destination is a screen someone visits when they remember to, you have not routed the customer anywhere. You have built a contact form with a worse response time than the one already on your contact page.

Three destinations work, and they share one property: they interrupt a specific person. An email to a named individual, not to support@ and not to a shared alias four people assume someone else is reading. An alert to a phone, which is what you want when handoffs are rare and the ones you get are urgent. Or a ticket in the helpdesk queue your team already lives in all day, which is right once handoffs are frequent enough to need assignment rules and a record of who replied.

Pick by volume. Under about five handoffs a day, email to a named person is enough and a helpdesk is overhead you will not maintain. Above twenty a day, email stops being a queue and becomes a pile, with no way to tell what has been answered. The phone alert is chosen by category rather than count. An angry customer or a payment problem justifies a buzz in someone's pocket whether there are two a week or thirty.

One destination per channel, and per shift

The destination is not one setting. The person who handles website widget conversations at 11am is usually not the person watching your WhatsApp number, and on Saturday it is neither of them. Before you open the configuration, write a small table on paper: channel down one side, the parts of the week across the top, a name in every cell. If you cannot fill a cell with a name, you have not found a configuration problem. You have found a gap in your staffing, and no trigger setting will cover it.

Channel matters more than owners expect. A message on your own WhatsApp number reads as a personal thread and wants a person replying in that thread, in a tone close to the one the assistant was using. A widget conversation on a product page is closer to a question shouted across a shop floor, and it can become a ticket without anyone feeling ignored.

Put the finished table somewhere the team can see it. A destination that exists only inside a settings screen is a destination nobody has agreed to, and the first time it matters you will find out that the named person thought the other named person was covering it.

The triggers you should never argue with

Once the destination has a name attached, the trigger list is short. These five should fire without hedging, without a clarifying question, and without the assistant deciding it can probably handle this one.

Two of these are worth stating precisely. Money leaving your account means the customer is asking you to move money, not asking what something costs. A price question is answerable and belongs in the second list further down. And the request for a person counts in any wording, including the sarcastic ones. "Is there a real person there" is the same trigger as "transfer me", and it is usually the last thing someone types before closing the tab.

The second-attempt rule is the one shops leave out and the one that recovers conversations you would otherwise never hear about. A first miss is forgivable and the customer will usually try again in different words. The second miss is where they decide the whole thing is a waste of time, and then they do not complain. They leave. Firing on the second attempt costs you a handful of unnecessary escalations a week, which is a cheap price for the alternative. Note what it does not mean: a customer who asks a second question because the first answer was useful is the shape of a working conversation, and counting those is a separate exercise done on the measurement page. The trigger is a repeat of the same question, not a follow-up to a good answer.

Never ask permission

"Would you like me to connect you to a colleague?" costs a turn and answers nothing. The customer already said what they needed. Now they have to confirm they meant it, to a machine, before anything happens. Some will not bother, and that shows up in your transcripts as a resolved conversation when it was somebody giving up politely.

Write the rule as an action rather than an offer. If a person is needed, fetching one is the reply. The assistant says what it is doing, who it is going to and what happens next, in the same message, and then stops. The customer should never have to say yes to being helped.

What the handoff message actually says

The trigger fires and the customer reads one sentence. That sentence is the entire handoff as far as they are concerned, and it is almost always the part written last, into a settings field, in a hurry, by whoever happened to be configuring the tool that afternoon. Give it ten minutes instead. It has three jobs, all concrete. Say that a person is now involved, in the past tense rather than the conditional: someone has been alerted, not someone will be. Say who, by role if you cannot say by name, because "a member of our team" and "Maya, who handles returns" are very different amounts of reassurance for the same number of characters. And say when, in a unit a person can hold in their head: within the hour, this afternoon, first thing tomorrow.

Then stop writing. The instinct is to soften it with an apology, a recap of what was discussed and an invitation to add anything else in the meantime. Each addition makes the message read more like an auto-reply and less like a person having been fetched, and a customer who reads it as an auto-reply keeps waiting for the real reply, which is a poor state to be in when the real reply is genuinely on its way.

One thing not to attempt in that message is answering the question as well. A rule phrased as answer-this-and-then-escalate reliably loses the answer, and since that failure is a property of how the instruction is written rather than of your routing, it is dealt with on the page about writing knowledge. Here, assume the handoff line is the whole reply, and write it well enough to survive being the whole reply.

Carry the thread across

Three things should arrive with the handoff. What identifies the customer, usually an order number or the email they gave. The problem in their own words rather than a category label. And what has already been tried, including what the assistant told them. That third one gets left out most often and matters most: without it, the person picking up repeats the answer that already failed, and now the customer has been let down by software and by a human being.

Being asked to explain everything from the beginning is the moment a customer stops being annoyed and starts being lost. It is worse than never having offered chat at all, because they have already spent five minutes typing and are now being told those five minutes did not count.

This is the cheapest test of whether the tool is worth its subscription. Send yourself a handoff and look at what lands. If your team has to open the conversation and reconstruct the situation before they can reply, the assistant has added a step to your support process rather than removing one. The person picking it up should be able to answer without scrolling.

Handing off too eagerly is its own failure

The failure nobody plans for runs the other way. A customer types "does this run small?!" and the exclamation mark trips a tone rule, so a sizing question becomes a ticket. Do that a few hundred times and the assistant is a slower contact form with a chat bubble on it, your team is handling the questions they installed it to stop handling, and the customer waited an hour for an answer that was in your product data the whole time.

So name the categories that get answered, not escalated, and be as explicit about them as you are about the triggers. These are the questions where your catalog and your written policies already contain the answer, and passing them to a person adds delay without adding accuracy.

A rough threshold: if more than one conversation in five ends in a handoff, and those handoffs are full of questions from that list, the problem is not your triggers. The assistant does not know enough about your products or policies, and escalating is what it does when it has nothing to say. Fix the knowledge and the handoff rate falls without you touching a rule.

When routing is not the problem you have

If you are a one-person shop handling ten or fifteen conversations a week, skip all of it. You are the destination for everything, there is no routing decision to make, and building five trigger rules for a queue of one is a way to spend an afternoon feeling organized. Let the assistant answer catalog questions, send everything else to you, and come back to this page when volume makes it a real question.

The second exception runs the opposite way. If you sell made-to-order work, wholesale, or anything that ends in a quote, the handoff is not the exception case. It is the product. The assistant answers what it can, collects what a person will need, and hands over almost every serious conversation. Judging that setup by how few handoffs it produces optimizes for the wrong outcome.

And if nobody has actually been given the job of watching the destination, do not configure handoff at all. Turn it off and let the assistant say plainly that it cannot reach anyone right now. A promise of a person who never arrives does more damage than an honest limit, and it is the version customers repeat to other people.

Read for the handoffs that never fired

The handoffs that fired are easy to inspect. They are sitting in someone's inbox. The expensive ones are the conversations where the assistant should have stopped and did not, and they have a recognizable shape. Someone asks the same thing three times in slightly different words, each answer misses in the same way, and then the conversation ends with no goodbye.

Read for that pattern on purpose, which is a different activity from reading for quality. You are not grading answers. You are scanning endings: the same question in three costumes, a conversation that stops mid-thought, a last message from the customer that nobody replied to and nobody needed to. Whatever counting routine you keep, it will not surface these, because in any tally a conversation that ended without a handoff looks exactly like one that went well. Every case you find resolves into either a missing trigger or a missing knowledge card, and it is usually the card.

How this works in Starly

You write the handoff message yourself, so it sounds like your shop rather than like software. When it fires, your team is alerted by a flag in the dashboard, by email to a person you choose, or by a phone alert, and it works the same across the website widget, your own WhatsApp number and Gorgias tickets. The phone alert notifies your team member. It does not call the customer, and there is no voice or SMS anywhere in this. The conversation stays in the channel where it started and a person picks it up there.

Two honest limits. This is one handoff setup, not a routing table, so if the table you wrote has different names per channel or per shift, you arrange that on the receiving end: which address the alert goes to, and who is holding the phone that day. And before you rely on any of it, run the test above and read what actually arrives, so you know how much your team has to open before they can reply.

For the reading habit, every conversation is stored as a transcript with a per-message trace showing what the assistant used to build each reply. That is where the asked-three-times-and-left conversations turn up, and where you can tell whether a wrong turn came from a missing knowledge card or from a trigger that never fired. Nothing in this page sits behind a tier, so the destination you choose is a decision about your staffing rather than about your plan.

Common questions

What should trigger a handoff to a human agent?

Five triggers should fire every time, without argument: anyone asking for a person in any wording, anything involving money leaving your account such as refunds, cancellations or a double charge, a complaint or an angry tone, a second failed attempt at the same question, and anything legal, medical or safety-related. The second-attempt rule is the one most shops leave out. A customer who has rephrased once and been missed twice usually leaves without complaining, so you never find out it happened.

Should the assistant ask before transferring the customer to a person?

No. "Would you like me to connect you to a colleague?" costs a turn and answers nothing, and some customers will not bother to confirm, which shows up as a resolved conversation when it was somebody giving up politely. If a person is needed, fetching one is the reply. The assistant should say what it is doing, who it is going to and what happens next, in the same message.

Where should a handoff go if I do not use a helpdesk?

To an email address belonging to a named person, not to support@ or a shared alias several people assume someone else is reading. Under roughly five handoffs a day that is enough, and a helpdesk is overhead you will not maintain. Above about twenty a day, email stops working as a queue and a helpdesk with assignment rules becomes worth the setup. For urgent categories such as payment problems and angry customers, a phone alert to a team member is the right destination regardless of volume.

My AI chat hands off too often. How do I fix it?

Over-eager handoff usually comes from tone rules firing on punctuation, and from the assistant escalating when it simply does not know an answer. Write an explicit list of categories that must be answered rather than escalated: sizing and materials, which variants exist and how two similar products differ, shipping cost and delivery windows, your returns policy as written, and whether a discount code is valid. If more than one conversation in five ends in a handoff and those handoffs are full of catalog questions, the fix is better product and policy knowledge, not stricter triggers.

Can a chat handoff connect the customer to a phone call?

Not in Starly. A phone alert notifies your team member that a handoff has happened. It does not dial the customer or move the conversation to a call, and there is no voice or SMS channel. The customer stays where they started, whether that is the website widget, your own WhatsApp number or a Gorgias ticket, and a person replies to them there with the transcript available to read.