Who takes over when the agent needs help?

Imagine a policy-servicing assistant preparing an address change and its confirmation. Begin with staff approving each change. Name the person watching the queue, a backup, the records they need and what they may do. A request sent to an unattended queue is still waiting for help. Decide what the customer sees during that wait and how they can reach an alternative service. Include those arrangements in the trial, alongside the agent’s answer.

Nexus describes passing on uncertain cases with context. Copilot Studio’s Customer Conversation harness documents handover to a human representative. Glean describes requiring approval before agent actions run.^1,2,3

Give each of those stops a purpose. An uncertain case needs investigation. An action reserved for staff needs approval even when the information seems clear. A request outside the service needs a route to the appropriate team. Ask the supplier to show where each rule applies and how the colleague watching the queue tells the cases apart. They should not have to guess whether to wait, approve something or find another team.^1,2,3

Arrange a rehearsal with approved test data. Let a handler review an address change, then alter the customer record before the approval is used. Your proposed rule should make the system notice the change and ask for a fresh decision. Also try rejection, no reply and a reviewer who has lost access. Look at the receiving record after each case. The assistant’s account of what it did is only part of the evidence.

Glean says source permissions apply to reads and writes and describes scoped service credentials. Kore.ai says policies are enforced outside the language model.^4,5,6

Ask which account saves the address, whether it can do more than the handler’s account and where approval is checked. A shared service account may be appropriate, but it needs limits that fit the approved job. For this example, set a clear launch condition: a rejected, expired or out-of-date proposal must leave the record unchanged. Have the supplier show that result using the connection and account you intend to use, rather than an administrator’s demonstration account.^4,5,6

An address update may reach the receiving system even if the connection times out before a reply arrives. Rehearse that case. Have the operator check the receiving system against the case reference before retrying. Distinguish confirmed success, failure with no change and an unknown result needing investigation. If the customer asks again, the proposed service should find the existing case. It should not quietly start another update while the first result is still unclear.

Kore.ai describes managing agent versions and rollbacks. Microsoft’s publishing guidance says users receive updated content after starting a new session.^7,8

Changing the agent version does not settle what happened to an address update already sent. Write recovery instructions: how to stop the service, who checks work in progress, where to verify the result, which correction is allowed and what to tell the customer. When changing a release, check an existing conversation and a new one if the product treats them differently. Record which version handled each case so the investigation can follow the right behaviour.^7,8

Ask the operations team to use those instructions without the original builder explaining them. If staff cannot distinguish a failed update from an unknown result, keep automatic changes disabled while you fix the gap. This is a launch condition we suggest for the example, not a statement about any supplier’s default retries. A useful rehearsal leaves staff knowing what to check next, including when they should not try the action again.

Nexus describes building the first procedure with the customer’s team. WRITER offers embedded transformation leads and deployment engineers. Kore.ai lists Forward Deployed Engineers and a proof using the buyer’s own case.^9,10,11,12

Ask each supplier for the same handover: the agreed job and exclusions, queue instructions, permissions, saved evidence, recovery steps, launch authority and support arrangements. Help with the build does not remove the need to agree which decisions stay with your firm. Have the service owner accept the material and show how staff handle a difficult case. Do that before expanding the actions the agent may take, while the implementation team is still available.^9,10,11,12

After launch, look at completed cases as well as exceptions against the customer result you originally wanted. Include repeat contacts, channels customers cannot use, approvals left waiting and corrections staff had to make. Agree which finding pauses an action or sends the design back for review. A changed connection, policy document or model deserves another look at the service evidence. The first approval should not become an unexplained permission for every later change.