Customer-service AI chatbots: plan the human handover

Information: The bot answers a general question using approved content, such as opening hours or documents needed for an appointment. Linking the relevant source makes the response checkable.

Personal case: An order, account or appointment does not belong to the person asking merely because they supply a reference number. The approved identity and authorization route must precede disclosure.

Action: Changing an order or issuing a refund additionally requires an allowed action, appropriate permissions and confirmation from the destination. A generated proposal is not an executed change.

Limit the first trial to a few defined tasks. If existing help-centre search already answers general questions, improving its structure may suffice. Check suitable AI and handover capabilities in the current support product first.

Define the triggers for a chatbot handover:

• an explicit request for a person
• unclear sources
• complaints
• actions outside the bot's authority
• an unavailable destination system

Identify the responsible team and the alternative when that team is unavailable.

Copilot Studio provides a concrete product example: Microsoft documents transferring conversation history and variables to a connected customer engagement hub. This does not establish automatic compatibility with every ticketing system. Check the channel, licensing, supported connection and the case that actually arrives. Microsoft: handing over to staff, checked 26 September 2026.

A callback request differs from an immediately available live conversation. The bot should describe only the availability the business can actually provide.

This conversation is entirely synthetic:

Assistant: You are speaking with the example business's AI assistant. I can answer general questions and pass unresolved requests to our team.

Customer: My delivery arrived damaged. Refund the amount.

Assistant: I cannot authorize a refund here. I can pass your message to the responsible team. Please do not share payment details in this chat.

Customer: I want to speak to a person.

Assistant: The live team is currently unavailable. Would you like me to request a response through the designated contact route?

The bot may confirm receipt only after successfully creating the case. On a technical failure, it provides the agreed alternative contact route. It claims neither a completed refund nor a response time that was never agreed. This example does not replace assessment of legal requirements or the customer's specific rights.

Include these details in the case that goes to staff:

• the request in the customer's own words
• a factual summary
• verification status
• steps already attempted
• relevant sources
• the current action status
• the case identifier, owner and agreed contact route

Transfer only what is necessary for handling the request. A complete conversation may contain confidential information inappropriate for every destination. The recipient must be able to distinguish customer statements from generated summaries.

A handover request needs a checkable state. The three states mean:

• Requested: the customer needs a person.
• Received: the destination has acknowledged the case.
• Accepted: an accountable employee or managed queue can actually handle it.

One friendly closing message should not conceal those different states.

Zendesk's handoff and handback documentation describes the change of first responder between AI and staff. Check when the selected product stops bot replies and what permits the bot to resume. A staff member's response must not compete with a simultaneously generated bot message.

Lost acknowledgement. In a synthetic outage test, the helpdesk creates the ticket but its response never reaches the chat. The operator uses the existing operation reference to establish whether the ticket exists before retrying. This prevents a worried customer from receiving contradictory replies from two queues.

Closed chat. If the customer closes the chat while waiting, the agreed follow-up route must still work. Check the recorded contact channel and explain whether the window must remain open. An open browser should not be an undisclosed prerequisite for a promised email response.

Outside staffed hours. Cases submitted outside staffed hours need an owner for the next working period. Acceptance therefore includes a test at the end of a workday and after an absence. Successful technical delivery to a permanently unattended group is not a functioning service handover.

Count answered questions, completed actions, correctly transferred cases and unresolved contacts separately. Someone closing the chat window has not necessarily solved their problem. A necessary handover is also not a failure when the task exceeds the bot's authority.

Review repeat contacts, corrections and staff handling time. Otherwise apparent relief in the chat window can create more work in the inbox. Repeat relevant tests after source, handover-rule or interface changes.

List common questions, authoritative sources and three cases that must remain with people. Establish available channels and ownership. WhatsApp is a separate integration with its own accounts and platform conditions; a functioning website chat does not demonstrate that connection.

The chatbot service page explains our approach. For internal information, start with the knowledge assistant. The cost guide helps budget setup, usage and the work that remains with your team together.