An AI customer-support handoff is complete when the receiving support system has the case, the right team owns it and the customer knows what happens next. Saying 'I will connect you' is only the beginning. Preserve useful context, stop conflicting automated actions and provide a recovery path when the transfer fails.
This guide uses a fictional duplicate-charge complaint to specify an AI-to-human handoff. It is for teams building a custom support experience or connecting an assistant to an existing help desk. The examples and evaluation numbers are illustrative, not customer outcomes or a comparison of support vendors.
Key takeaways
- Define escalation triggers as product rules and honor a direct request for a person.
- Transfer a concise, verifiable case packet rather than only a model-written summary.
- Track request, delivery and ownership as separate states.
- Measure usable handoffs and eventual outcomes alongside automated resolution.
Decide when the assistant should stop trying to resolve the case
In the duplicate-charge example, the assistant can explain where to find an invoice and collect an authorized billing reference. It cannot establish that two similar-looking charges are duplicates merely from the customer's description. A request to reverse a payment needs the product's defined permissions and review process.
Set triggers for a direct request for a person, unresolved repeated attempts, unavailable account information and actions outside the assistant's authority. Keep these rules understandable to the support team. Avoid a vague instruction such as 'escalate when uncertain' if nobody can explain which observed conditions should cause a transfer.
A model's confidence statement is not a calibrated guarantee. Use the information and action boundary: does the system have the evidence it needs, and is it permitted to do what the customer requests? If either answer is no, the next step should be explicit rather than another persuasive answer.
Prepare a case packet a human can actually use
Keep the customer's question, the authorized account reference, the checks attempted, their results and the reason for escalation. A short summary helps navigation, but the agent should be able to verify it against the relevant messages and system evidence. Label an inference as an inference.
For the fictional complaint, the packet says that the customer reports two charges; it does not say that a duplicate charge was confirmed. Include the accessible invoice or transaction references through approved systems. Do not copy payment credentials or unrelated account data into a general-purpose ticket.
Separate information gathered from actions taken. If the assistant already opened a billing investigation, record its identifier. If it merely prepared a draft request, say so. The distinction prevents a human from repeating an action or assuming something was completed when it was only proposed.
| Field | Example | Purpose |
|---|---|---|
| Customer request | Customer reports two charges and wants billing review. | Preserves the requested outcome without claiming verification. |
| Authorized context | Workspace reference available in the support system; identity verified by the approved flow. | Avoids inferring identity from message text alone. |
| Checks attempted | Invoice lookup timed out; no refund action performed. | Distinguishes failed lookup from missing invoice. |
| Reason for handoff | Unverified charge relationship and action outside assistant authority. | Tells the receiving team what judgment is needed. |
| Evidence references | Relevant conversation messages and authorized billing record links. | Lets the human verify the summary without broad data copying. |
| Next owner and receipt | Billing queue, case reference and delivery acknowledgment. | Shows that a real receiving system accepted the work. |
Treat the transfer as a durable request
Intercom's official external-handover guide describes sending customer context to another support tool through workflows and data connectors. That is a concrete integration example. A custom implementation needs the same clarity about which system receives the case and what evidence establishes receipt.
Persist a handoff request with a stable identifier before sending it. Keep the destination's ticket reference when delivery succeeds. If the external system times out, query or reconcile the result before creating another ticket. A timeout may mean the request failed or that the response was lost after success.
Design a fallback for unavailable support infrastructure. Preserve the pending case, explain that live transfer is unavailable and offer the configured alternative. Do not tell the customer an agent has the case when the receiving system has not acknowledged it.
| State | Evidence | Allowed next behavior |
|---|---|---|
| Transfer requested | A persisted request and destination exist. | Send or retry through the controlled delivery process. |
| Delivery uncertain | A timeout or missing receipt; destination result not yet known. | Reconcile before another ticket creation. |
| Case received | Destination case reference recorded. | Tell the customer the case was received and explain the next step. |
| Human owns conversation | Receiving assignment and takeover state verified. | Prevent competing automated actions; preserve context. |
| Resolved or awaiting customer | Support outcome recorded by the owning process. | Follow the documented follow-up and closure rules. |
Does the receiving team get a usable support case?
Bring your help desk, escalation rules and support hours. We can define the case packet, confirmed transfer and ownership checks.
Prevent the assistant from re-entering the conversation
Intercom documents a specific failure pattern: a workflow triggered by every new customer message can route an escalated conversation back to Fin. Its recommended guards depend on the actual conversation state and prior teammate reply. Check the current instructions for the deployment you use.
For a custom assistant, maintain an explicit ownership state. Once the human path owns the billing case, the assistant should not create a second investigation, promise a refund or answer as though no transfer occurred. Decide whether it may still provide limited informational help, and make that boundary clear.
Test a customer who sends another message immediately after requesting a person, then another after a human has replied. Also test reopening a closed case. Route from persisted state rather than trusting a model to remember the correct owner from a long transcript.
Tell customers what is available in their support window
A global audience does not imply a staffed queue at every hour. Show the applicable support hours with a clear time zone and distinguish live transfer from a case awaiting response. For US, UK, Canadian and Australian customers, a vague 'today' can describe different dates.
Use wording tied to the actual receipt. For example, after confirmed delivery: 'Your billing case has been received. Your reference is [case ID]. The billing team will respond through [channel] during [published support hours].' Only include a response-time promise if the team has agreed and can support it.
When delivery is pending, use different wording and preserve a visible recovery route. The customer should not have to repeat the entire story just because the support API was temporarily unavailable. Make any additional information request specific to what is still missing.
Evaluate the handoff as a complete customer journey
Build a small evaluation set covering a direct request for a person, repeated unresolved questions, a failed lookup, a closed queue, a destination timeout and a message after takeover. For each case, inspect the customer's wording, case packet, destination receipt and ownership state.
For illustration, suppose 40 synthetic conversations require a handoff. If 34 reach the correct queue with all required context, usable delivery is 34 divided by 40, or 85%. That is a hypothetical calculation, not a recommended universal threshold or a MUBBITS result. Record the six remaining failures by reason so the percentage leads to useful work.
Measure ultimate resolution and whether customers repeat information separately. A high automated-resolution figure can conceal a poor escalation experience. MUBBITS can help define the support integration and evaluation around your actual help desk, permission boundaries and operating hours.
Frequently asked questions
Should the assistant ask another question after a customer requests a person?
Honor the request and begin the configured transfer. If more information is useful, explain why and collect it without turning that question into a barrier to human support.
Is a generated conversation summary enough for handoff?
No. Include the request, authorized context, checks, actions, evidence references and destination receipt. The receiving human should be able to verify the summary and see what remains unresolved.
How do we avoid duplicate support tickets after a timeout?
Use a stable transfer identifier, preserve the receiving system's reference and reconcile uncertain delivery before another creation attempt. The exact mechanism depends on the destination's API and capabilities.
Let’s work through your next step.
Tell us what you’re building, what you’ve tried, and where you need a hand. We’ll work with you to define a practical way forward.