An AI chatbot should hand a conversation to a person when the customer asks, the bot cannot answer reliably, the request carries unusual risk, or a human has authority the bot does not. The transfer should include the conversation context, explain what happens next and provide a safe fallback if no agent is available.
The aim is not the lowest possible escalation rate. A bot that refuses to transfer can appear efficient while customers repeat themselves, abandon the conversation or receive an unsafe answer. The better measure is whether automation resolves suitable requests and routes the rest to the right person with enough context to continue.
What is chatbot human handover?
Human handover is the controlled transition from an automated conversation to a human support agent. It has four parts:
- Trigger: the system recognises that human help is required.
- Package: it collects the relevant conversation, customer and routing context.
- Route: it sends the case to an appropriate queue or agent.
- Resolve: the human takes ownership, then closes or returns the conversation to automation under a defined rule.
A button labelled “talk to a person” is only the trigger. Without ownership, context and failure handling, it is not a dependable handover process.
The 12 triggers that matter most
Hard triggers: the bot should transfer immediately
Hard triggers are rules where business policy requires a person. They should not depend on the model’s confidence score.
1. The customer asks for a human
Respect a clear request such as “agent”, “human please” or “I want to speak to someone”. The bot may ask one short routing question, but it should not force the customer through more automated troubleshooting first.
2. Account security or suspected fraud
Transfer suspected account takeover, identity mismatch, payment fraud or credential exposure to an authorised team. The bot can explain the next safe step but should not improvise an identity decision.
3. A high-risk or regulated request
Medical, legal, financial, safeguarding and other regulated matters may require a qualified person or an approved process. Define the categories with the organisation’s responsible specialists; do not rely on a generic keyword list as the complete control.
4. The action requires human authority
Examples include approving an exceptional refund, changing a locked account, overriding policy or committing the business to compensation. The bot may collect the facts, but only an authorised person should make the decision.
5. Threats, abuse or immediate safety concerns
Set a specific safety response and escalation route. The bot should not argue, make promises it cannot keep or leave urgent language in a routine queue.
Soft triggers: the bot should assess and route intelligently
Soft triggers combine evidence. One weak signal may justify clarification; several together may justify transfer.
6. Repeated failed answers
If the customer rephrases the same question, rejects the answer or returns to the same point, continuing the same response pattern is unlikely to help. Count failed turns around the customer’s unresolved goal rather than counting every message.
7. Low or conflicting answer confidence
Confidence can help, but there is no universal threshold that suits every business. A product-colour question and a disputed high-value refund should not use the same tolerance for uncertainty.
Calibrate thresholds by intent and consequence. A low-risk request may receive a clarifying question; a high-impact request should transfer sooner.
8. Missing or contradictory knowledge
The bot should escalate when two policies disagree, an answer is absent or the source appears outdated. It should say that it cannot verify the answer rather than smoothing over the gap.
Reviewing unanswered or weak conversations can also improve the knowledge base. AeroChat’s AI-powered chat insights can help a team find recurring issues, but a human still needs to decide which source is correct.
9. Strong frustration or deteriorating sentiment
Repeated negative language, demands for resolution and signs that the customer feels ignored can justify earlier transfer. Sentiment is imperfect, so use it as one signal alongside the conversation history and business rules.
10. A valuable or time-critical sales opportunity
Automation can answer routine questions, but a person may be better placed to handle a complex quote, a bulk order, a deadline-dependent purchase or unusual compatibility requirement. Define what counts as high value for your business rather than copying another company’s threshold.
11. The request crosses several teams or systems
A conversation may start as delivery tracking and become a damaged-item claim involving logistics, refunds and inventory. Transfer when the bot cannot complete the end-to-end task or when split ownership would make the customer repeat information.
12. A tool, channel or integration fails
If order lookup, identity verification or another required tool fails, the bot should not invent a result. It should explain the limitation, capture a safe reference and route the case or offer an alternative contact method.
Match each trigger to an action
| Trigger | Immediate bot action | Routing destination | Context to pass |
|---|---|---|---|
| Customer requests a person | Acknowledge and stop persuading | General support queue | Request and short summary |
| Suspected fraud | Give approved safety instruction | Security or authorised team | Verified identifiers and risk signal |
| Exceptional refund | Explain that approval is needed | Billing or senior support | Order, policy exception and customer request |
| Repeated failed answer | Apologise once and transfer | Subject queue | Attempts made and unresolved question |
| Missing knowledge | State that the answer cannot be verified | Knowledge owner or support | Question and sources checked |
| Integration failure | Avoid inventing status | Technical or service queue | Tool name, error time and safe reference |
| Time-critical sale | Confirm urgency | Sales or priority queue | Need, deadline and relevant product context |
This table is a template, not a universal policy. Replace queue names and approval boundaries with the business’s real operating model.
What context should the human agent receive?
The agent needs enough context to continue, not an uncontrolled data dump. A practical handover packet includes:
- customer’s stated goal;
- a concise reason for transfer;
- relevant conversation transcript;
- verified identity or order reference, when appropriate;
- actions already attempted;
- relevant product or policy source;
- urgency, language and channel;
- any promised next step or expected response time.
Microsoft’s current live-agent handoff guidance describes passing conversation history and relevant context variables when a conversation escalates. The principle applies beyond one platform: make the next agent informed without exposing unrelated customer data.
The receiving agent should see what came from the customer, what the bot inferred and what was verified. Those labels prevent an AI-generated summary from being mistaken for a confirmed fact.
Design the handover as a state workflow
A reliable workflow has explicit states rather than a vague promise that “someone will join”.
- Automation active: the bot owns the next response.
- Transfer requested: the trigger and required context are captured.
- Queued: the customer sees that the request is waiting and what to expect.
- Accepted: a named or clearly identified human owns the conversation.
- Resolved: the outcome is recorded and the conversation is closed.
- Transfer failed: the customer receives an alternative route instead of silence.
Only one party should own the next message. When a human accepts the case, pause the bot unless the workflow explicitly calls it for a supporting task. This avoids collisions in which the bot and agent send conflicting replies.
What should happen when no agent is available?
After-hours design is part of the handover, not an exception to it. Tell the customer that live help is unavailable, collect only the information needed for follow-up and set a realistic expectation based on the team’s actual service hours.
Offer a relevant alternative when possible:
- create a support request with a reference;
- allow email follow-up;
- show the next staffed period;
- provide an approved emergency or security route;
- let the customer continue with the bot for unrelated questions.
Do not claim that a transfer is immediate when it enters a queue. For seasonal demand, the guide to handling high-volume Shopify messages explains how to reduce repeat enquiries and prioritise urgent cases before the queue becomes unmanageable.
How should failed transfers be handled?
A transfer can fail because the queue is closed, an agent declines it, the channel disconnects or routing data is incomplete. Treat failure as a visible state.
The bot should acknowledge the problem, preserve the case, offer the next valid route and avoid asking the customer to repeat everything. Operationally, record the failure reason so the team can distinguish staffing gaps from technical faults.
Microsoft’s bot-to-human handoff pattern describes accepted, failed and completed handoff events. Even if your platform uses different labels, the state model helps prevent abandoned conversations.
How AeroChat handles human handover
AeroChat is an AI agent platform that helps online businesses run customer service on autopilot. Its smart human-handover feature is designed for the point where automation should give way to personal attention.
According to AeroChat’s current feature documentation, handover can be triggered when the customer asks for a human or the AI has low confidence. It can assign an available agent, carry the conversation context, support agent-to-agent transfer and allow a person to join an AI conversation. Business-hours and away-mode settings help teams define the response when nobody is immediately available.
Those capabilities still need business rules. AeroChat does not know your refund authority, risk appetite or priority-customer definition unless the workflow and source material express them. Set hard triggers first, then tune soft triggers from real conversation reviews.
AeroChat supports customer conversations across web chat, WhatsApp, Facebook Messenger, Instagram, Telegram, email and other supported channels. This makes consistent escalation important: a customer should not receive a safe human route on the website but become trapped in automation on another connected channel.
For the wider operating model, see how customer-service automation should divide work between systems and people. The guide to chatbot errors and recovery covers what to do after an inaccurate answer; this page focuses on preventing and routing that moment.
How do you measure whether handover works?
Do not optimise one metric in isolation. Track a small set that reveals both customer outcome and operational health:
- percentage of handovers accepted;
- queue time before acceptance;
- failed or abandoned transfers;
- repeat-contact rate for transferred issues;
- customer effort or satisfaction after transfer;
- reasons for escalation;
- cases where a person had to correct the bot;
- cases escalated too early or too late.
A falling escalation rate is not automatically an improvement. It may mean the bot resolves more issues, or it may mean customers cannot reach staff. Review conversation samples alongside the numbers.
Common handover mistakes
Hiding the human option
Customers should not need a secret phrase. Recognise normal requests and make the route discoverable where risk or frustration is high.
Transferring without a summary
A transcript alone can be long and hard to scan. Pass a concise summary while keeping the original conversation available for checking.
Using one confidence threshold for every intent
The cost of a wrong opening-hours answer is not the same as the cost of an unauthorised refund. Tune by consequence.
Claiming an agent is available when the case is queued
Use accurate states and expectations. Acknowledgement is not acceptance.
Letting the bot continue after acceptance
Make ownership explicit. The bot should pause unless the human deliberately invokes it.
Collecting unnecessary data before transfer
Ask only for the information the receiving team needs. Sensitive or unrelated details increase privacy risk without improving the outcome.
A launch checklist for support teams
Before enabling handover, confirm that:
- every hard trigger has an owner;
- soft triggers have examples and review rules;
- queues, skills and business hours match reality;
- the handover packet separates verified facts from AI summaries;
- automation pauses when a human accepts;
- failed and after-hours transfers have a fallback;
- sensitive-data rules apply across all channels;
- agents know how to transfer, resolve and return a conversation;
- outcome metrics and conversation reviews have named owners.
The final rule
Escalate when a person is requested, required by policy, better equipped to manage the risk, or needed because the bot lacks knowledge, confidence, authority or a working tool. Then transfer the useful context and set an honest expectation.
The strongest handover does not make automation look clever. It makes the change of ownership feel uneventful to the customer—and gives the human agent a fair chance to solve the problem on the first continuation.
