How to decide when AI customer service hands off to a person
Before an AI customer-service assistant goes live, write which cases go to a person, what earlier context the ticket must carry, and who watches the queue in each part of the day. Split handoff into cases you planned for, and fallback when the assistant cannot match the customer. Whether a draft may be sent belongs in the bot note. The rule here covers a conversation leaving the assistant and entering an agent queue.
On this page
- Write the handoff before launch
- Zendesk asks for a strategy and a channel first
- Planned handoff and fallback are different
- The ticket carries what the customer already said
- Name who watches the queue, and when
- Offline agents and a failed transfer are separate
- Do not mix this with drafts or internal permissions
- Walk one conversation before launch
Write the handoff before launch
The handoff rules are written before launch: which questions always go to a person, which ones the assistant may answer up to a named point, what earlier context the person must see, and what the customer sees when nobody is on duty. The person responsible for customer service signs the rules. The agent supervisor confirms the queue and the hours. Deciding inside a live conversation whether to hand off fills the queue in the busy hours and leaves sensitive cases with nobody in the quiet hours.
The bot note covers classification of repeated messages, a draft from approved text, and a person deciding whether to send. The permissions note covers which internal files an employee assistant may read. Handing an external customer to an agent is a third decision: the conversation leaves the assistant and enters a queue. Do not collapse the three into "a person looks at everything". See How to build an AI customer service bot and How to set permissions for an enterprise AI assistant. How the channel meets the screen agents already open is Customer, sales, and voice assistants.
Zendesk asks for a strategy and a channel first
Read on 20 October 2026, Configuring escalation strategies and flows for AI agents on Zendesk Help says an AI agent sometimes needs to transfer a query to a human when the inquiry is complex, urgent, or sensitive. Before launch, develop an escalation strategy and design the escalation flow, then build the paths with escalation blocks in the dialogue builder. The page says flows can be built for messaging and email AI agents, and it lists Team, Professional, or Enterprise support. The page shows no publication date.
The same page defines the strategy as which queries are escalated and through which channel. It says there are typically two channels, messaging and email, and that the factors are the number of agents, agent availability and business hours, conversation volume in the channel, and the complexity and urgency of the query. Its example is a team of four agents working 9am to 5pm and handling about 200 to 250 conversations a day: escalating too many messaging conversations overloads the agents and makes customers wait. The example reserves messaging escalation for high-impact issues such as product questions and shipping failures, and offers escalation when the AI agent cannot guide the customer to self-service. That is the page's example, not a headcount or a volume every company should copy. A company writes its own hours, staffing, and which topics use messaging or email on the strategy page.
Planned handoff and fallback are different
Read on 20 October 2026, IBM's Connecting to a live agent defines an escalation as transferring the conversation to a live agent when the assistant is integrated with a supported service desk. The page says the assistant must use web chat or phone, and that a service-desk integration has to be added first. The service desks it lists are Genesys, NICE CXone, Salesforce, Twilio Flex, Zendesk, and a bring-your-own desk. The page shows no publication date.
The same page separates two situations. A planned escalation is an anticipated case you always want to hand to a person. Its examples are a service the assistant cannot complete alone, and a sensitive subject that needs a person, such as bereavement benefits or resolving a complaint. A fallback escalation is an unexpected case where the customer cannot get help from the assistant. Its examples are a customer repeatedly asking something that matches no defined action, repeatedly giving an invalid answer, or explicitly asking for a human. Fallback uses the built-in Fallback action, which by default starts a transfer to a live agent. The rules page uses those two names. It does not fold them into "transfer when the customer is unhappy".
The ticket carries what the customer already said
Zendesk's section on designing the flow says that, before escalation, the agent can gather an order number, name, or email, add tags and update fields for the existing workflow, and identify suitable agents, so the handoff and the conversation after it are more efficient. The flow is then designed with template replies. Additional templates are created when more than one flow is needed. The IBM page says that when the assistant starts a transfer, the agent is notified in the agent dashboard and can see the history of the customer's chat with the assistant. The rules page turns "context that must travel" into a list: order or case number, the channel the customer used, the name or email already collected, the last question the assistant stopped on, and whether the chat history travels with the ticket.
An item that is not on that list is not something the agent should have to ask the customer to repeat. Zendesk also notes that only a conversation with at least one customer or AI-agent message can be escalated. An empty conversation does not become an empty ticket. Tags are the set customer service already uses. The assistant does not invent a second vocabulary. The step that adds a tag or updates a field names the field it writes.
Name who watches the queue, and when
Hours and queues live on the strategy page, not inside a single conversation. Zendesk says you can escalate by messaging only when agents are available to continue, and that outside working hours a synchronous channel can escalate by email instead. An availability block at the start of the path checks business hours or agent availability. Forwarding to an agent goes by default to the group chosen when the AI agent was integrated with the CRM, or to a team named in Escalate to team. If escalation fails, the flow can name the dialogue to trigger, such as the system reply for a failed escalation. The page says the older "send an email" option is no longer recommended.
On the IBM side, the transfer step chooses Connect to agent in the And then field. The messages that can be set are the reply when agents are online (the default is "Let's send you to an available agent"), the reply when agents are offline (the default is "There are no agents available at this time. When one becomes available, we'll connect you."), an optional message to the agent, and an optional route to a specific queue. The page notes that the action completes once the transfer occurs, whether or not the customer is then engaged with a live agent. "Transfer sent" and "agent picked up" are therefore two fields. The action ending is not the same as a person having answered. The queue owner and the hours are on the strategy page. Leave is recorded there, not by editing an old conversation.
Offline agents and a failed transfer are separate
Agents being offline is a hours problem the strategy already expected: switch to email, show the offline message, or wait for the next staffed period. Zendesk uses the availability block for that branch. IBM uses the offline reply, which by default tells the customer that no agent is available and that a connection will be made when one is. Neither page sets a wait in seconds or a service level. A company's own wait standard stays in its customer-service rules, with a date, and is not attributed to these two pages.
A failed transfer is different: the path decided to hand off, and the conversation did not reach the named team or desk. Zendesk lets you name the dialogue to trigger on failure. IBM says the action completes when the transfer occurs, even if the customer is not engaged with an agent. The rules page therefore names the sentence the customer sees on failure, the queue the ticket lands in, and who clears that queue in the next staffed period. Without those three, the conversation sits where the assistant has finished and no agent has seen it. If email automation thresholds are actually in use, Zendesk also says an escalated conversation receives the escalated_by_ultimate tag and the AI agent stops replying, and that workflows should find tickets still Open with that tag. Write that tag into the clearing rule only when that email capability is in use.
Do not mix this with drafts or internal permissions
Whether price, delivery date, refund, and complaint may be sent only after a person confirms them belongs in the bot note: the assistant may draft, and an agent decides whether to send. That sentence is still inside the assistant. This note is the conversation leaving the assistant. A complaint can do both: draft the part approved text can answer, then use a planned escalation to hand the person or the refund to an agent, carrying the order number and what was already said. An internal permission table does not mean the external queue has an owner.
Internal permissions govern which files an employee may read. External handoff governs which agent group receives the customer, and in which hours. The same person can appear on both tables. The fields stay separate. The permission table does not hold queue hours. The strategy page does not hold a document catalogue. The launch check looks at both: an agent can see a ticket that carries the agreed context, and the employee assistant is not the thing answering that external ticket.
Walk one conversation before launch
Before launch, walk one planned case and one fallback case in preview or in a test environment. IBM says the action preview pane does not perform a real transfer; the Connect to an agent message only confirms the step was triggered. A real transfer is tested from the assistant preview once a service desk is connected. The walk checks that the online and offline sentences are the ones written on the rules page, that the agent sees the chat history or the agreed fields, and that a failure lands in the named queue. The date, the conversation id, and the result are written at the end of the strategy page.
Headcount, wait limits, and satisfaction targets stay in the company's own customer-service rules. The four agents and the daily volume on the Zendesk page are that page's example. Neither document gives a handoff success rate or a number of seconds in which an agent must answer. Before the assistant offers a handoff to customers, three things are on the strategy page: planned and fallback are separate, the ticket carries the agreed context, and every staffed period has a queue owner.