How an AI handoff to a person should work

“Someone will get back to you” is not a handoff specification. It is a promise whose meaning depends on a queue, a person and a working process behind the conversation.

A useful handoff transfers responsibility. The customer knows what happens next. The recipient knows why the request arrived and what has already happened. The system can distinguish a notification from an accepted task. Without those distinctions, an assistant can appear helpful while quietly moving unfinished work somewhere less visible.

Here is an original specification you can adapt before connecting a customer-facing assistant to your team.

Name the reasons a person gets involved

Start with concrete triggers. A customer requests a person. A question falls outside approved information. A required detail cannot be established. An attempted action fails. A request exceeds the assistant's authority. A specialist-owned issue requires the business's approved escalation process.

Avoid a single trigger called “low confidence.” It may be useful internally, but it does not explain the operational reason. Record a reason code a manager can investigate. “Could not establish account identity” leads to a different fix from “policy does not cover this situation.”

Do not require customers to prove that escalation is justified. A repeated loop of rephrased questions can make the apparent efficiency of automation depend on the customer's willingness to give up.

These are hypothetical routing examples. The business must supply its actual recipients, coverage and authority.

Give the recipient a usable packet

A transcript can be available without being the primary handoff. The recipient should not need to read a long conversation before discovering the actual request.

Include a concise statement of the customer's goal, verified contact details, relevant facts, unanswered questions, attempted actions, and the current state of any external record. Mark uncertainty explicitly. “Customer says payment was taken” differs from “payment confirmed in the billing system.”

Separate customer statements from system observations. If a summary compresses them into one confident narrative, the human may repeat the same mistake the assistant made. Include links or identifiers that let the recipient inspect the underlying evidence with appropriate permissions.

Make acknowledgement visible

Use a small sequence of states that the team understands: created, assigned, accepted, in progress and completed, with a separate blocked state where needed. Your existing helpdesk may already provide suitable states. The important part is that “sent” does not silently count as “owned.”

In a hypothetical property maintenance workflow, a message may be delivered to the daytime coordinator after hours. That delivery does not prove anybody is working on it. The customer-facing explanation should reflect the actual coverage arrangement approved by the business.

Set a reviewable acknowledgement expectation for each queue. This is an internal operating decision, not a universal response-time benchmark. Decide what happens when that expectation is missed: notify a backup, move the task to a staffed queue, or use another approved fallback.

Design the empty-desk case first

A live transfer requires someone to receive it. Test busy signals, unavailable staff, disconnected transfers and a recipient who answers but cannot help. Specify who retains ownership if the transfer fails.

For asynchronous handoffs, collect only what is needed for the next step and explain whether the customer has a confirmed callback or simply a request for one. Do not promise an exact time unless the receiving operation can honor it.

A handoff is complete when someone takes responsibility, not when software sends a message.

That is an editorial operating principle, not a quotation from research. It is deliberately stricter than a notification metric because it exposes the point at which customers can disappear between systems.

Walk through a complete failure

Consider a hypothetical customer changing an appointment. The assistant cannot verify the new slot, creates a scheduling task, and tells the customer the change remains pending. The scheduling owner accepts the task, checks the calendar, contacts the customer through an approved channel and records the outcome.

Now remove the scheduling owner. Does a backup receive the task? Can the original appointment remain intact? Will an automated reminder incorrectly announce the requested new time? The handoff specification must account for these downstream effects, not just the initial transfer.

Have a frontline employee perform this exercise without help from the project team. Their questions reveal which assumptions have remained in people's heads.

Measure the whole transfer

Review unaccepted tasks, customers who repeat their story, transfers that bounce between queues, and requests closed without a verified outcome. Inspect a sample of successful handoffs as well as failures; a status label can be wrong in either direction.

The NIST AI risk management framework provides a voluntary risk-management context. The routing and acknowledgement design here is an original operating recommendation.

Finish the specification with one named owner for changing it. Queue coverage, staff roles and escalation authority will change. The handoff should remain correct when they do, and the people receiving the work need a straightforward way to say when it is not.

Sources

• NIST AI risk management framework

Explore the workflow considerations for customer messaging support.