A customer selects “talk to an agent,” and reporting marks the conversation escalated. One practical question remains: who responds now? Buying bot-to-human handoff requires an explicit waiting, acceptance and return path because starting a transfer does not establish that a person read or took responsibility for the request.
Do not combine everything after the button
The customer may request a person, the system initiate transfer, the conversation wait for availability and an agent finally accept it. These are different events; some can fail or require another step. Ask the supplier to describe each state, the customer display and follow-up owner beyond a “transferred” message.
This article reviews responder responsibility across states rather than rebuilding customer identity or transferring conversation history. Complete context can coexist with an unattended waiting customer. Counting transfers alone cannot assess service at the boundary between an assistant and a person.
A conversation acceptance sheet
Complete the sheet for the agreed platform and channel. Specify evidence demonstrable in an appropriate test rather than merely a configured state name. If the tool records no independent acceptance event, document alternative evidence and its limits without inventing a state the system cannot record.
| Situation | Responsibility question | Buyer verification |
|---|---|---|
| Person requested | Did transfer start, or were instructions merely displayed? | Actual path and customer message |
| Waiting for the team | Who follows up when nobody is available? | Understandable waiting and an agreed option |
| Human acceptance | What establishes responder responsibility? | Acceptance or alternative evidence and a contextual response |
| Customer returns | Is this the previous case or a new request? | Expected responder for the closure state |
Add failed transfer or channel interruption where included, specifying when the assistant resumes and who decides. Do not tell customers a person is present without appropriate evidence. A waiting message also establishes no round-the-clock human coverage.
A fictional waiting-and-return test
Consider a camera-equipment rental service. A customer asks about an arrangement requiring staff and requests transfer when nobody is available. Staff later handle the conversation and mark it solved. The customer returns with another question before final closure. This is neither an actual operation nor a customer story.
Ask the supplier to demonstrate expected behavior at each transition, including whether the assistant may answer during waiting. Repeat the return after final closure and compare outcomes. Use authorized test accounts and data in a suitable environment; proposal evaluation requires no messages to real customers.
Escalated does not establish human acceptance
Copilot Studio documentation explains that escalation can provide a message or link without an engagement hub, and reaching the transfer node marks an escalated session in analytics. Distinguish that event from an agent accepting and responding, considering actual product and channel integration requirements.
Ask what every proposal metric counts: the customer's request, transfer initiation or team acceptance. Differing definitions do not automatically imply a broken platform. Evidence must match the purchased meaning, and unestablished behavior must remain visible in the acceptance report.
Resolution and closure can change the responder
In Zendesk's documented behavior, the human remains the responder until ticket closure, and a customer returning during Solved can remain in the previous conversation. After Closed, a new customer-initiated conversation can return to the assistant. This is product-specific behavior rather than a universal chatbot rule.
Review the project's actual configuration and the team's state terminology instead of transferring documented default closure periods into your contract. Agree test coverage and evidence limits, recording deferred or unsupported behavior rather than declaring success because the transfer message appeared.
Complete the scope with service automation deliverables and escalation boundaries. Bring the state sheet when requesting customer-service solutions from Nextwave so responder responsibility remains understandable during waiting and after the conversation ends.
Behavior sources and limits
Copilot Studio handoff and Zendesk handoff and handback documentation was read on 4 November 2026. No configuration, test or closure was performed. Prepared with AI assistance and information and translation review.
