AI to human handoff: design a good escalation

Every in-app helper gets stuck sometimes. The user asks for something the app can’t do, a record isn’t where they think it is, or the request needs a person to say yes. What happens next decides how the whole experience feels.

A cold handoff sends the user to a blank contact form. They type the problem again, someone on your team asks which page they were on, and a two-minute question turns into a two-day thread. A warm handoff passes the request along with everything the helper already knows, so your team can start from the answer, not from the question.

This post is a checklist for the warm version: when to hand off, what to pass, and how to close the loop.

Why the handoff matters more than it looks

Users judge help by the worst moment, not the average one. A helper that sorts out most requests and then drops someone at a dead end leaves that person feeling worse than if they had written to you directly. They tried, they were patient, and now they have to start again.

A good handoff turns “it couldn’t help me” into “it got me to the right person, and they already knew what I needed”. That is a fine outcome. Not every request should be solved by software, and your users don’t expect it to be. They expect not to repeat themselves.

When to hand off

Before deciding what to pass, decide when to pass it. A helper should hand off in four situations:

1. The app can’t do it. The feature doesn’t exist, or the user’s plan or role doesn’t allow it. The helper should say so plainly, then offer the team.
2. It needs a person’s judgement. Refunds, exceptions, account changes that need approval, anything where your policy has a “it depends”.
3. It tried and couldn’t finish. Something on the page got in the way, or the path wasn’t where it expected. Say how far it got and stop.
4. The user asks for a person. Always honour this straight away. Don’t make them argue with the helper first.

What a helper should not do in any of these cases is guess. Changing the wrong record, or reporting something as done when it isn’t, costs far more than a handoff. A clear “I couldn’t do this, here’s why” is a correct answer.

The handoff checklist

When the helper hands over, the message that reaches your team should answer the questions your agent would otherwise have to ask. Here is what to pass, in order of how often it saves a reply.

Pass this	Why it helps	Example
The request, in the user’s words	Your team sees what they actually wanted, not a summary of it	“Connect my work calendar”
What was tried	Nobody suggests the steps that already failed	Looked in Installed apps and Calendar apps settings
Why it stopped	Tells your team whether this is a bug, a missing feature or a permissions question	The calendar wasn’t listed on the Calendar apps page
Where the user is	The page or screen they were on when they asked	Settings, Calendars
Who the user is	Account, plan and role, so your team can check limits and permissions without asking	Signed-in user id, workspace, plan
What changed, if anything	Your team knows whether there is anything to undo	Nothing was changed

Two more things make the message easier to act on:

• Leave out what doesn’t belong. Passwords, card numbers and ID numbers should never be in a handoff, even if they were on screen. Pass what your team needs to help, not everything the helper could see.
• Keep it short. A few lines your team can read in ten seconds beats a full transcript. Link the transcript if you keep one, but lead with the summary.

Where the handoff should go

Send the handoff to wherever your team already works. If you run a help desk, the request should land there as a ticket with the context filled in, not as an email someone has to copy across. If your team answers from a shared inbox or a dashboard, it should land there.

Equally, the reply should go back to where the user is. The best handoffs feel like one conversation: the user asks in your app, your team answers, and the answer shows up in the same place the user asked. If the reply arrives by email two days later, the user has to remember what it was about.

1. Step 1User asksIn plain words, in your app›
2. Step 2Helper triesDoes it, or stops and says why›
3. Step 3Context goes overRequest, what was tried, why it stopped, where they are›
4. Step 4Team repliesFrom the help desk or dashboard they already use›
5. Step 5Answer comes backIn the same panel the user asked in

Close the loop

A handoff isn’t finished when your team replies. Three habits make each one count for more:

• Reuse the answer. If your team explains how to do something once, the next user who asks the same thing should get that answer without waiting. The handoffs you see most often are your best source of help content.
• Tag the reason. Was it a missing feature, a permissions question, a bug, or a judgement call? Counted over a month, these tags tell you what to build and what to fix. A support ticket audit works the same way.
• Watch for repeat handoffs on the same task. If users keep getting handed over for one request, that is usually a screen that is hard to use or a feature people expect and can’t find.

How Stiro handles the handoff

Stiro is an in-app agent: you add it to your app with one script tag, users ask for what they want in plain words, and it does the steps in your real interface while they watch. The handoff is built into how it ends a request.

• It says so when it can’t. If a request isn’t possible in your app, Stiro stops, says why, and changes nothing. It doesn’t guess or change something else instead.
• The user keeps the final say. Anything that sends, spends or deletes is set up and handed back for the user to press.
• Stuck requests reach your team with the context attached. A signed-in user can message your team from the same panel, with what they asked and why it stopped already attached. Your team replies from the dashboard, and the answer shows up in the user’s panel.
• Or your help desk. If you already run one, one line hands the request to it instead.
• Answers get reused. The next time someone asks something similar, Stiro starts from what your team said.
• Handoffs don’t cost a task. Messages to your team, their replies and the saved answers are free on every plan, as the pricing page sets out.

Stopping well is something we test, not just something we promise. In the Stiro benchmark, 7 of the 44 everyday requests were things the app couldn’t do, such as editing a record that doesn’t exist. A pass meant Stiro stopped, said why, and the app’s own database showed nothing had changed.

requests the app couldn’t do: stopped with the reason, nothing changed

7 of 7

everyday requests passed, cold, in three apps it had never seen

44 of 44

A typical stop reads like this: “There’s no event type named ‘Board review’ in this workspace.” That is the line that goes to your team if the user wants a person, so they know straight away what was asked and what was missing.

Make the handoff part of the help

Write down your four reasons to hand off, decide what your team needs to see, and make sure the answer goes back to where the user asked. Do that, and even the requests a helper can’t finish feel looked after. If you want an in-app agent that does the steps and hands over the rest with the context attached, see how Stiro works as an AI support agent. The free plan includes 50 runs a month, so you can try it on your own app first.