A working AI-to-human handover needs three things: a trigger, a clear waiting message, and a teammate who can continue the conversation. Configure the route, then test it as both a visitor and an operator. A handover button alone does not establish that anybody is watching the inbox.
1. Define when a person should take over
Start with explicit requests such as “I need a person,” exceptions your Agent cannot approve, and questions that need private account investigation. Keep routine public-policy answers with the Agent when the source supports them.
In the selected Agent's Architect Studio, ask for a human-support route and inspect the resulting workflow. Human takeover requires an eligible paid plan; check current plans before designing a release around it.

This screenshot shows how to inspect a saved workflow step in the actual app, using demo data. It is not a capture of a completed live handover. Review the handover step and branch in your own configured workflow.
2. Write a truthful waiting message
For a team that monitors the inbox without a guaranteed reply time, use wording such as: “Your question needs a teammate. Leave the details here and our team will continue in this conversation.”
If you publish support hours, ensure the team actually covers those hours. Avoid “Someone is joining now” when the route simply changes conversation status. Decide who checks conversations left overnight and who covers absences.
3. Run the visitor side
Open the published widget in a separate browser session. Ask a policy question first, then request a person. Keep the two-message context so the receiving operator has something meaningful to inspect.
After the handover, send one more detail. Check that the message arrives in the conversation and that the AI does not continue competing with the human. LoopReply's website widget stops AI responses when a conversation is waiting or in human takeover.
4. Run the operator side
An authorized Workspace member opens the receiving conversation, reads the earlier messages, and takes over. Reply with a specific next step related to the original question. Confirm that the visitor sees the reply and can continue typing.
Use this test sequence with fictional details:
| Step | Visitor action | Operator check |
|---|---|---|
| Policy question | “Can I return an opened item?” | The question and AI response are visible |
| Exception | “It arrived damaged. I need help.” | The exception is clear without asking again |
| Request a person | “Please get your team.” | Waiting or human ownership is visible |
| Additional detail | “The packaging was torn.” | New detail arrives after the handover |
| Human reply | Visitor reads the next step | AI does not issue a competing response |
These are expected outcomes for your drill, not claimed production response times. Save the actual transcript and mark any missing step.
5. Test the offline path
Repeat when no operator is immediately available. Confirm the waiting message, where the team will find the conversation later, and what a returning visitor sees. A route that works only while its creator is online is unfinished.
Use the support deployment guide to assign coverage, and the support responsibility map to identify who can approve an exception. For a damaged-order example, see the ecommerce return scenario.
6. Return to AI deliberately
Once the human task is finished, an authorized teammate can return the conversation to AI. This changes the conversation to active. Test the next ordinary question to verify the intended route resumes.
Do not treat a status change as evidence that a customer's problem is solved. The operator should first complete the promised action or explain what remains pending. Our conversation review method keeps this distinction visible in reporting.
Diagnose the first broken transition
If the visitor cannot send after opening the widget, investigate the widget interaction before changing routing. If messages arrive but nobody receives the work, investigate inbox ownership. If AI keeps answering, inspect the actual conversation status and branch. Fix the earliest failing step, rerun the whole sequence, and keep the passing transcript with the release notes.
