When Should an AI Support Agent Hand Off to a Human — and What Must It Carry?
September 15, 2026 · 9 min read · by the hiy team
The short answer
An AI support agent should hand off in exactly two situations: when it cannot answer from the material it has, and when the customer asks for a person. Not on a timer, not on a guessed office-hours schedule, and not after the third wrong answer — the third wrong answer is two too many. The handoff itself must carry four things to the person who picks it up: who the customer is (an email at minimum), the whole conversation rather than the last line, the moment it happened, and what the agent already tried. And the customer must be told, on screen, that it went through. The test of a good handoff is that nobody ever reaches a dead end: from the customer's seat there is always a next step, and it is always true.
The single most expensive handoff mistake is escalating without context, so the customer repeats themselves to a person who starts cold. The second is hiding the human option in the hope the customer will give up first.
When should the handoff happen?
Two triggers, and the case for not adding a third.
When it cannot answer. The agent has searched, nothing in the material covers the question, and it says so. That admission is the handoff's natural moment — the customer has just been told the agent is out of road, and the next sentence should be an offer of a person. In hiy this is what every Support Agent does by default: it admits the gap, then offers to pass the question on.
When the customer asks for a person. Some customers do not want to be triaged. "Can I talk to someone?" is a handoff request whatever the agent could have answered, and an agent that argues — "I might be able to help, what's the issue?" — is an agent that has decided its deflection number matters more than the person asking. hiy's Escalation page offers this as an additive second trigger: asking for a person is another reason to hand over, never a replacement for the first.
Now the triggers that sound sensible and are not:
- Working hours. "The team is offline right now" is a claim about your availability the agent cannot verify, and a customer told the wrong thing about your availability is worse off than one told nothing. hiy deliberately has no working-hours setting: a handover is attempted whatever the clock says, and the question is recorded the moment it happens.
- Sentiment. Escalating on detected frustration sounds humane and is fragile: it fires on brisk typing and misses polite despair. If someone is frustrated, they will ask for a person, and the second trigger handles it.
- A failure counter. "Escalate after N unhelpful answers" bakes in N−1 unhelpful answers. If the agent cannot answer, the first admission is the moment to hand off, not the third.
There is a reason to resist a rule builder here. Two rules need an order, an order needs a tie-break, and before long you are learning a workflow engine to express "hand over when you're stuck". Three settings — when, who, and what it says — cover almost every support desk, and the ones they do not cover are worth deciding out loud rather than by accident.
Nothing in the material covers it, and the agent says so plainly.
no filler
The next sentence, in your team’s words, not the agent giving up.
≤ 200 characters
The question goes with it. The customer reads: Sent. The team has your question and your email.
on screen
Whole conversation, in the Inbox, whatever your notification settings say.
Inbox · always
Reading what the agent tried first, rather than one line of context.
your job, not ours
What must a handoff carry?
| What travels with it | Why it has to | What happens without it |
|---|---|---|
| Who the customer is — an email at least | So a person can actually reply, and so the same customer is one thread, not three | A form that goes nowhere; the customer emails again from scratch |
| The whole conversation | So the person reads what was asked, how it was phrased, and what the agent already said | "Can you tell me what the issue is?" — the customer repeats themselves to someone starting cold |
| The moment it happened | So the wait is measured from when the customer was stuck, not from when someone noticed | A ticket with no age, sorted behind newer ones |
| What the agent tried | The searches it ran before it gave up — so the person knows this is a real gap, not a phrasing miss | The person re-searches the docs, finds nothing, and the gap stays open |
| A confirmation on screen | So the customer knows it went through and can stop trying | The customer sends it three times, or assumes it was lost |
The second row is the one that decides whether the handoff was worth having. In hiy, each handoff in the agent's Inbox opens the conversation that produced it, and that view is never behind a plan on a Support Agent — a handoff you cannot read has dead-ended, which is the one thing the agent promises not to do.
The dead-end test
Sit in the customer's seat and walk every branch of the conversation. At each point, ask: is there a next step, and is it true?
- The agent answered, with a citation the customer can open — a next step (read the passage) that is true.
- The agent could not answer and offered a person — true, provided the offer leads somewhere that is actually watched.
- The agent said "the team is offline, try again at 9am" — a next step, but is it true? The agent does not know your hours.
- The agent said "I've passed this on" and nothing was recorded — a lie, and the customer will find out.
- The agent hid the human option behind a plan, or behind three more attempts — a dead end dressed as helpfulness.
- The customer was told a reply time nobody committed to — a promise the agent cannot keep.
An agent passes when every branch ends in an answer the customer can check, or a person who will actually read it. hiy's version of the last point is deliberate restraint: the customer is told Sent. The team has your question and your email — and no reply time, because the product does not know one.
What the receiving side sees, and what it does not
This is the part most handoff advice leaves out, and it is where the honest statement of what a tool does today matters more than its feature list.
In hiy, a handoff is always recorded in the agent's Inbox the moment it happens, whatever your other notification settings say, because someone is stuck right now. Whether an email reaches you as well depends on the deployment: where email delivery is set up, a handoff is emailed and recorded; where it is not, it is recorded and nothing is sent — and the Escalation page tells you which of the two states you are in, in words, rather than assuming. So the Inbox, not your mailbox, is the thing to check. Colleagues you invite into your organisation can open that Inbox and read every handoff and the whole conversation behind it; they cannot change the agent's rules or its knowledge, which stay with the account that created it.
If you turn handover off altogether — a real choice on the Escalation page — the agent still says plainly when it cannot answer; it just stops there, and the email box a customer would otherwise see under the admission is removed, so what the agent says and what is on screen agree.
The two expensive mistakes
Escalating without context. The customer has spent four messages explaining the problem, the agent has given up, and a person arrives asking what the issue is. Every minute the agent saved has just been spent again, by a more expensive person, in front of a customer who is now certain the agent was a waste of time. The fix is structural: the handoff is the conversation, not a summary of it and not a subject line.
Hiding the human option. Some teams bury "talk to a person" because an easy exit lowers the deflection number. It does. It also teaches customers that the agent is an obstacle, and the ones who need a person most — the angry, the confused, the ones with a real bug — are exactly the ones who will leave rather than fight through. A visible route to a person makes the agent more trusted, not less used; a customer who knows the exit is there is more willing to try the agent first. And a deflection rate improved by hiding the exit is the metric flattering itself — deflection vs resolution explains why.
The honest version
A handoff is a promise a person has to keep. The agent can record the conversation, attach the email, and tell the customer it went through; it cannot reply. If nobody reads the Inbox, the handoff was a polite way of losing the customer, and no design fixes that.
Two things hiy does not do today and will not pretend to: it sends no email receipt to the customer, and it makes no reply-time promise, because it has no way to know one. Resolution tracking and helpdesk integrations — pushing the handoff into the tool your team already lives in — are on the roadmap. Until they ship, the Inbox is where a handoff lives, and the routine of checking it is yours.
Where to start
Run the dead-end test on your current agent, branch by branch, and write down every step that is not true. Then look at what actually arrives on the receiving side when a customer hands off: if it is one line and an email address, that is the first thing to fix. If you are setting up a hiy Support Agent, the Escalation page is three settings and takes five minutes; the handover sentence a customer reads is yours to write, and it is live on the next question.
Questions people ask
Should an AI support agent escalate when it detects frustration?
It is an unreliable trigger: it fires on brisk typing and misses polite despair. A frustrated customer will ask for a person, and an agent that hands off whenever someone asks covers that case without guessing at mood. The two triggers that hold are: the agent cannot answer, or the customer asks for a person.
What information should be passed to a human agent during handoff?
Who the customer is (an email at minimum), the whole conversation rather than a summary or the last message, the moment the handoff happened, and what the agent tried before giving up. The customer should also see an on-screen confirmation that it went through.
Should the chatbot tell customers when the support team is offline?
Only if it actually knows. An agent that guesses at your hours tells some customers the wrong thing, and a wrong claim about availability is worse than no claim. hiy attempts the handover whatever the time and records it immediately; the customer is told it went through, not when a reply will come.