The dead end
The worst thing an AI assistant can say is "I will have someone get back to you" when nothing is going to happen.
It is worse than a wrong answer, because a wrong answer is at least detectable. The false promise costs the visitor their time twice: once in the conversation, and again three days later when they realise nobody is coming and they have to start over somewhere else. It also spends the goodwill that everything else in your product was working to build.
Handoff is the part of an AI assistant that most teams design last and should design first, because it is the failure path — and how a product behaves when it cannot help is a better predictor of trust than how it behaves when it can.
When to trigger it
There are four reliable triggers. Everything else is noise.
They asked
Someone who types "can I talk to a person" should not be talked out of it. Assistants that deflect ("I might be able to help — what is your question?") turn a request into a negotiation with software about whether the person is allowed to reach you. They will win that negotiation by closing the tab. Honour the request immediately.
It failed twice
Two consecutive turns where the assistant could not answer is the reliable signal. One failure is a rephrasing problem. Three is an abandoned conversation. Two is the moment to offer.
The topic has consequences
Billing disputes, cancellations, anything legal, anything medical, anything where a wrong answer costs real money. These should route to a person on the first turn, regardless of whether the assistant could answer. The question is not capability, it is who should be accountable for the answer.
The tone turned
Frustration is a handoff signal even when the assistant is technically answering correctly. Someone who is angry does not want a better answer, they want acknowledgement, and no amount of accuracy substitutes for it.
Notice what is not on the list: complexity. A long or technical question is not a handoff trigger. Plenty of complex questions are exactly what a grounded assistant is good at.
Collect the details before you promise anything
This is the rule that makes handoff work, and it is the one most implementations skip.
An assistant should never say "someone will follow up" until it has a way to reach the person. Otherwise you have generated a notification your team cannot act on: a transcript of an anonymous visitor with a problem and no contact details. That is not a lead, it is a receipt for one.
It is a mistake that happens naturally. The model is trained to be reassuring, so when someone says they want help, "I will pass this along" is the fluent response — and it arrives before anyone has asked for an email address. The fix cannot live in the prompt alone, because prompts are probabilistic and this needs to be certain. In our case the check runs on the server: an escalation that arrives without contact details is rejected and handed back to the assistant, which then asks for them. The model cannot promise what the system will not deliver, because the system simply declines.
Practically, collecting those details is better done with a small form than with conversational back-and-forth, especially in a spoken conversation where nobody wants to recite an email address aloud. That trade-off is covered in in-chat forms that convert.
What to pass along
The point of handoff is that your colleague does not start from zero. A notification that says "a visitor requested help" has moved the work, not reduced it.
| Include | Why it matters |
|---|---|
| Full transcript | The person already explained their situation once. Making them do it again is the main reason handoffs feel worse than just emailing |
| What they asked for, explicitly | The transcript has the detail; a one-line summary has the intent |
| Contact details, verified in shape | An email with a typo is the same as no email |
| The page they were on | "Pricing page" and "docs page" are different conversations |
| Which assistant, and when | Obvious until you run more than one |
| What the assistant already tried | Stops your colleague repeating a suggestion that already failed |
The last row is the one people forget and the one that changes the reply most. If the assistant already offered the self-serve fix and it did not work, your colleague needs to know that before they suggest it again.
Where the notification goes
Two destinations cover almost every team.
Email to whoever handles enquiries
No setup beyond an address. The transcript and details arrive in an inbox somebody is already watching, which is the whole advantage — a handoff that lands somewhere nobody checks is a dead end with extra steps.
A signed webhook to your own systems
For teams with a helpdesk or CRM, the escalation posts to your endpoint with a signature you can verify, so you can open a ticket, attach it to an existing customer record, or route by topic. Delivery is retried with backoff if your server has a bad minute, and every attempt is logged so you can see what was sent and what came back.
You can use both. The important part is that at least one exists and is monitored, and that you have watched a real submission arrive at least once. Untested delivery paths fail silently, and by design they fail at the exact moment when someone needed you.
Do not let the conversation die
The last piece is what the visitor sees after the handoff fires, and it is where an otherwise correct implementation still feels bad.
Three things belong in that message. What happened — not "escalated," but "I have sent your question and your email to the team." When to expect a reply — a real interval you can meet, not "shortly." What they can still do — the conversation should keep working. Freezing the widget into a "waiting for an agent" state after a notification-based handoff is the cruellest possible design: the person sits there watching a spinner for a live console that is not going to open.
The assistant should stay available. Plenty of people ask two more questions after requesting a human, and some of them get answered well enough that the follow-up becomes a much shorter email.
And give them an exit that does not depend on you. A support address, a docs link — something they can act on if your reply is slower than promised. It costs nothing and it is the difference between "they are handling it" and "I am stuck."
The shape of it
A good handoff is unglamorous: recognise the moment, get a contact method before making any promise, send your team enough context to reply properly, tell the visitor exactly what will happen, and keep the door open.
Handoff volume is also a signal worth reading. If a topic escalates repeatedly, that is a gap in your knowledge base rather than a fact about your visitors — keeping a knowledge base accurate covers closing that loop, and reducing support tickets covers the broader deflection picture.
Escalation by email or webhook is configurable per assistant at hiroi.ai. Worth setting up on day one, before the first real visitor finds the edge of what your assistant knows.