Design the handoff before the voice agent

Before choosing how an AI receptionist sounds, decide what happens when it cannot finish the call. A transfer to an unanswered phone is not a completed handoff. A callback request without an owner is just another unattended inbox.

The useful design question is what the caller and the receiving team each need at that moment.

Decide when a person should take over

Start with the business's boundaries. A caller explicitly asks for a person. The agent cannot confidently identify the account. A request falls outside the approved service list. The scheduling system is unavailable. The caller has already corrected the same misunderstanding twice.

These situations need different responses. Some require a transfer, some a callback, and some a clarification. Write the decision with the staff who will receive the work.

Microsoft's Guidelines for Human-AI Interaction, published in March 2019, include making capabilities clear and supporting correction when the system gets something wrong. The application to a voice workflow is straightforward: explain what the assistant can do and give callers a usable route out of a failed interaction.

The number of clarification attempts should reflect the task and its cost. Two attempts can be a sensible pilot setting, but it is a design choice to test, not a universal rule.

Define the receiving end

For each destination, record staffed hours, the transfer number or queue, the fallback, and the person responsible for maintaining those details.

A branch office might accept live transfers during opening hours. After hours, it might accept a callback request with a stated response window. The assistant should follow the verified schedule, not infer availability from a directory entry.

Use a small handoff contract:

Field	Why it is needed
Reason for handoff	Helps the receiver choose the next action
Confirmed caller details	Avoids repeating identification unnecessarily
What has already been attempted	Prevents another trip through the same failed flow
Outstanding request	Makes the remaining work explicit
Named queue or owner	Makes the request actionable

Include only information the receiving team is permitted to use. A concise factual summary is often more useful than forwarding an entire recording by default.

Confirm the transition

Treat "transfer requested," "transfer accepted," and "call ended" as different events. The agent should not announce that the caller is connected to a person merely because a transfer API accepted a command.

Test the actual telephony behavior. What does the caller hear while the destination rings? What happens if the receiving line is busy, unavailable, or goes to voicemail? Can the caller return to a useful fallback?

Microsoft's November 2018 conversational AI guidance emphasizes responsible design and transparency in conversational systems. For this workflow, that means avoiding promises the system cannot verify, including a promise that a human is already available.

Measure completion after the transfer

A low transfer rate is not automatically good. An agent can reduce transfers by trapping callers in a conversation. A high transfer rate can also be appropriate if the assistant deliberately handles only a narrow set of requests.

Measure accepted transfers, callback requests assigned to an owner, callbacks completed within the agreed window, and customers who have to contact the business again about the same issue. Review the reasons separately.

A pilot review should include a few calls from both sides: the caller's experience and the receiving employee's experience. The summary might sound clear to an engineer while omitting the account reference staff need to do anything useful.

Run the after-hours test

Before launch, call when the destination is deliberately unavailable. Ask for a person, correct a detail, and interrupt the transfer process.

The workflow should still produce an honest explanation and a traceable next step. That test is more revealing than another perfect booking demo. It tells you whether the business can keep its promise when automation reaches its limit.