Who owns the case after an AI handoff?

A handoff design can stop at the trigger: low confidence, an angry customer, a request outside scope, hand it to a person. That decides when the AI steps back. It says nothing about what happens in the next ten minutes, or the next twelve hours if the trigger fires on a Saturday night. Customers do not experience the trigger. They experience whether someone picked the case up.

This article is about the part after the trigger. It treats a handoff as a transfer of ownership that is only complete when an accountable person has the case and the context to act, and it works through the five design decisions that make that true: acknowledgement, timeouts, after-hours behaviour, partial human actions and preserved context. For the question of which rights the AI has before it hands off, see what a customer-service AI should be allowed to do.

Where this comes from. The five decisions come out of three conversations Typewise held in 2026: a solution workshop with a retailer's subscription business, a pilot review with an online retailer running our agent on its shopping chat, and a technical pre-pilot session with a travel company. I was in two; a colleague ran the technical session. The requirements and proposals below are reported; the failure patterns are the test conditions we recommend, and the decisions are our recommendation.

A handoff is a state, not a message

Define the handoff as a case state with an owner, a deadline and a visible status, in the system your team already works in. Until that state exists, the AI saying "I'll pass this to a colleague" is a sentence, not a transfer.

Three failure patterns show why this matters. Treat them as test conditions for your own design rather than as anyone's reported history; each is easy to produce in a test and expensive in production.

• The AI promises a follow-up and the conversation simply stops until the customer nudges it again.
• The customer replies "thanks" while the internal request is pending, and the reply is treated as the end of the conversation. The pending request disappears without a visible trace.
• The case reaches a person without the order the AI already looked up or the identity it already verified, so the person has to ask again.

A fourth condition matters for analysis rather than for the customer: if a pending internal request is cut off, the conversation record should still show that it was made, or nobody can see afterwards what went wrong.

The symptoms alone do not tell you whether the cause sits in orchestration, in state handling or in the model. Designing explicit states does not answer that question, but it makes the failure visible and the model's job simpler: the case either moved into the right state or it did not.

Decision 1: what "acknowledged" means

Separate two acknowledgements that are easily confused.

To the customer: confirm that a person now owns the case, give a realistic time, and say what happens next. "A colleague will reply by email within one working day" is a commitment someone has to meet; "we'll get back to you" is not.

In the system: the handoff is acknowledged when a person has accepted it, not when it was created. Track time-to-accept separately from time-to-resolve; an unaccepted handoff is the state most likely to be invisible.

Then make sure a customer reply during the pending state cannot close it. A thank-you, a follow-up question or a second intent should attach to the open case, not end it.

Decision 2: timeouts, and what they trigger

Every pending step needs a deadline and a fallback. Three timers cover most designs:

1. Action confirmation. The AI called a system; nothing came back. A timeout establishes an unknown outcome, not a failure: the refund may have gone through and the acknowledgement may have been lost. So the next step is to query the authoritative status of that action in the system that performs it, using the transaction or idempotency identity the request carried, and never to retry blindly, because a blind retry is how a customer gets two refunds. Tell the customer that confirmation is pending and when they will hear, and move the case to a person with the action identity attached if the status cannot be established within the timeout. A promise in the transcript is not evidence that the action happened, and a timeout is not evidence that it did not.
2. Acceptance. A handoff was created; nobody accepted it. After the timeout, it escalates to a backup or a supervisor queue rather than waiting indefinitely.
3. Resolution. A person owns the case but the committed time has passed. The customer gets an honest update, and the case is flagged.

Write the timeout values down per channel. Chat customers wait minutes; email customers wait hours; both deserve to know which.

Decision 3: after-hours behaviour

Service hours are the handoff design's biggest blind spot. The AI is available at all hours; the people are not. This was the first handoff question in the workshop with the subscription business: a customer uses the agent outside opening hours and then needs a person. What they wanted was specific: say we are not here, create a ticket, and promise an email on the next working day. That is a requirement they stated; the options below are how we would design around it. Decide explicitly, per intent, what happens when the trigger fires outside staffed time:

• Hold with a promise. Create the ticket, tell the customer when staffed hours resume, and commit to a reply in that window. This is the right default for most requests and it needs a named owner on the first staffed morning.
• Restrict scope. Some intents should not start outside hours at all, because a half-finished action with no person available is worse than a clear "we're closed, here is how to reach us".
• Keep the AI going with a lower ceiling. Informational requests can continue; anything needing an action or a judgement waits.

Whichever you choose, the customer should hear it before they invest ten minutes in a conversation that cannot finish tonight.

Decision 4: partial human actions

Not every handoff hands over the whole conversation. When an integration is missing, a person can perform one step and return the result to the AI, which carries on with the customer. This is a useful bridge for workflows where the lookup or write exists in a third-party system you have not connected yet. The travel company's product lead proposed exactly this as an interim for reservations, where no endpoint existed yet: the agent collects the minimum details, a colleague with the tools performs the step and returns the result, and the agent continues. Their engineering lead's caveat is the reason for the last paragraph of this section.

Design it deliberately:

• the request to the person is specific (what to look up or do, for which customer, by when);
• the result flows back into the case so the AI can continue without asking the customer again;
• the customer knows a short wait is happening, and the acceptance timer above applies;
• the partial step is counted as human work in your metrics, because it is.

Partial handoffs are also where pilot dashboards mislead. A high share of conversations "handled by the AI" can hide a high share that needed a person for a step in the middle. Inspect the partially handled cases and the human time they consumed before treating participation as resolution.

Some tasks should not be bridged at all. Where a workflow has a controlled experience the customer should use, like a reservation flow in an app with its own safeguards, the better handoff is a clear pointer into that flow rather than a person doing it over chat.

Decision 5: context travels with the case

The person receiving a handoff needs what the AI already established, in the tool they work in:

• the verified identity and what it was verified against;
• every lookup already performed, with its result, including the order or booking in question;
• the customer's stated intents, including the ones not yet addressed when several arrived at once;
• what the AI already told the customer, so nobody contradicts it;
• the reason for the handoff, in one line.

Context also has a lifetime. If the customer uploaded a document for one step, the handoff design should say how long it stays available and when it is deleted; that is a data-handling decision, and it is easier to make before the first upload than after. The subscription business asked for exactly this: a document uploaded for one step should be deleted when the conversation ends, while the conversation itself is kept longer. Whether a given platform can do that is an engineering question; the decision is yours to make up front. Likewise, if an AI channel sits alongside an existing ticket system, define how the ticket identity survives forwarding, so a handoff does not create a duplicate ticket with half the history. The online retailer's engineering lead raised precisely that when we discussed routing their email channel alongside the incumbent desk; it is an acceptance criterion, not a detail.

Metrics that show whether handoffs work

• Time to accept, per channel and per hour of day.
• Share of handoffs that timed out at each timer, and for action timeouts, how many were later confirmed as completed versus failed versus still unknown.
• Repeat questions after handoff: how often the person asked for something the AI already had.
• Partial handoffs as a share of "AI-handled" conversations, with the human minutes they took.
• Customer contacts during the pending state, and whether they closed the case by mistake.

Keep the agent-performance reporting your team already relies on intact while you automate the channel; if those measures disappear during a test, the people who are measured by them will notice first.

Limits

This design assumes you can create and track case states in your service tooling; where you cannot, the honest handoff is a ticket with a human owner and a stated reply time, and nothing more ambitious. It also does not decide the triggers; the existing guidance on when an AI should step back still applies. And a well-designed handoff does not fix an understaffed queue. If acceptance times are long at every hour, the problem is capacity, and the fix is to narrow the AI's scope or add people, not to tune the timer.

Related reading

• what a customer-service AI should be allowed to do: the rights the AI holds before and after the handoff.
• Taking a customer-service AI agent live: approval coverage and staffed hours in the pilot.
• What counts as a resolution: how partial handoffs enter your metrics.

FAQ