The fastest way to destroy trust in an AI agent is to trap someone in it. A visitor who needs a person and cannot reach one does not conclude “this bot has limits” — they conclude the company is hiding. Handoff is the feature that prevents that, and it is worth setting up before you deploy rather than after the first complaint.
1. Why handoff matters
Every knowledge agent has a boundary. Some questions need an account lookup, a judgement call, an exception, or simply a human being. What matters is not whether the boundary exists — it always does — but what happens when a visitor reaches it.
A bot with handoff configured converts its own failure into a warm lead for your team. A bot without it converts the same moment into an abandoned session you never hear about.
2. How a handoff works
- 1
A visitor asks for a person
Either because the bot offered — it should, when it cannot answer — or because the visitor asked directly.
- 2
The request is created with full context
Chat.co records the conversation it belongs to, a category, the visitor's name and email if they gave them, an optional message explaining what they need, and a snapshot of how long the conversation had run. Your team inherits the transcript.
- 3
Your recipients are emailed
The category decides who. The email carries the context, so someone can act on it from their inbox without opening the dashboard.
- 4
Someone works it
The request appears in the bot's Handoff queue as Pending and moves through the states below as your team picks it up.
| Status | Meaning |
|---|---|
| Pending | Raised, emailed, nobody has picked it up yet |
| In progress | Someone on your team has taken it |
| Resolved | Closed out, with a note recording what happened and who closed it |
| Cancelled | Closed without being handled — duplicate, spam, or the visitor resolved it themselves |
Both closing states carry a note. Fill it in — six weeks later, the notes are the only record of what your bot could not do.
3. Routing & recipients
Handoff requests carry a category. Out of the box these are GENERAL, TECHNICAL and SUPPORT, and you can define your own to match how your team is actually organised — BILLING, RETURNS, whatever you route on.
How recipients are resolved
Chat.co walks a three-step fallback, in this order:
- 1
Recipients configured for that specific category
If
TECHNICALhas its own recipient list, that list is used. - 2
The default handoff recipient list
Used for any category without its own recipients.
- 3
The bot owner's email address
The last-resort fallback, so a handoff is never silently dropped. It also means a bot with no configuration at all still works — it just all lands on one person.
4. Working the queue
Open Handoff under Interactions in the bot sidebar. Each request opens onto the conversation that produced it, so the first thing your team reads is what the visitor actually said — not a summary of it.
Two habits make the difference between a queue that works and one that rots:
Move it to In progress when you take it
Otherwise two people work the same request and a third assumes someone has it. The status is the only signal your team has.
Write a real note when you close it
“Resolved” with no note tells you nothing later. One sentence about what the visitor needed turns the queue into a source of product truth.
Team members can be given access to Handoff without access to everything else — Team, roles & seats covers the permission model.
5. Teaching the bot when to escalate
A model will not offer a human unless you tell it to. This belongs in your system prompt under Tune Bot → Behavior, and it should be specific about triggers rather than vague about willingness.
Worth naming explicitly:
- Anything the knowledge base does not cover. Not an apology and a guess — an offer.
- Anything account-specific. Order status, billing, personal data. The bot cannot see it and should say so.
- Any sign of frustration. Repetition, escalating language, a second rephrasing of the same question.
- Any direct request for a person. This should never require negotiation. A bot that argues about it is worse than no bot.
6. Helpdesk tickets
If your team lives in a helpdesk rather than an inbox, connect one. Zoho Desk in particular can receive tickets created from handoff requests, so the escalation lands where your agents already work and inherits your existing SLA and assignment rules.
Both Zendesk and Zoho Desk are configured from the bot's Integrations page — see channel integrations.
7. What to watch
| Signal | What it usually means |
|---|---|
| Handoff rate climbing | Either the bot got worse or your traffic changed. Read the transcripts before assuming either. |
| Handoffs clustering on one topic | A knowledge gap with a name. This is the single most actionable signal the queue produces. |
| Handoff rate near zero | Rarely good news. Usually the bot never offers, and visitors are leaving instead of escalating. |
| Long time-to-first-reply | Recipients are wrong, or the notifications are landing in a mailbox nobody reads. |
The second row is where the value is. A cluster of handoffs about shipping times is not a support problem — it is a missing page in your knowledge base. Knowledge Gaps attacks the same problem from the other direction, and the two together close the loop: the bot fails, a human covers it, and the failure becomes content so it does not happen again.