AI-to-Human Handoff in the Contact Center: What the Human Actually Receives

When an AI agent cannot finish a customer’s request, it hands the conversation to a person. That moment decides whether the customer remembers the AI as helpful or as the thing that wasted five minutes. This piece is about what actually arrives on the human’s screen when that happens, why it is so often less than everyone thinks, and what each of the major contact center platforms gives you to work with.

What leaders say, and what customers say

In April this year, Five9 and Hanover Research surveyed contact center and CX decision-makers, and separately consumers, across the US, the UK and Germany. Nearly all of the decision-makers said their organization preserves context when the AI hands a customer to a person. And 83% of the consumers said they still have to repeat themselves, at least sometimes, after being transferred.

Five9 sells contact center software, handoff included, so read it as vendor research. Its own summary of the finding still ends on the right question: whether organizations are accurately measuring handoff success.

The two groups were asked different questions, so the numbers are not a gap you can subtract. They do not need to be. One side believes the handoff works. The other side keeps being asked for their date of birth.

In August, Gartner published a 2026 survey that shows why access to a human still matters. Of the 3,566 business and consumer customers it surveyed in February and March, 87% said it is essential for a company using generative AI in service to offer a way to reach a human. When Gartner asked the customers who were unwilling to use AI what would change their mind, the most common answer was being able to switch to a person if needed.

So the way out of the AI is part of what would make hesitant customers willing to use it at all. If that way out is rough, it undercuts the one thing those customers said would win them over.

One call, told plainly

Here is an illustrative call. It is not a client story, but most people who have worked in a contact center will recognise it.

A customer is travelling. Her card is declined at a hotel desk, so she calls her bank. The AI agent answers, verifies her with a one-time passcode to her registered phone, and asks what is wrong. She explains. The AI checks her recent transactions, confirms the card is on a fraud hold, and correctly works out that lifting a fraud hold is not something it is allowed to do.

So far, this is a good AI agent. It understood her, it checked, and it knew its limits.

It tells her it is transferring her to someone who can help. She waits. A person picks up and says: “Thanks for holding. Can I start with your full name and date of birth?”

From her side, the last three minutes did not happen.

From the bank’s side, the handoff worked. The transfer completed, and the call record shows the AI passed the customer ID and the transcript. Ask the CX leader whether their AI preserves context at handoff and they will say yes, and they will not be lying.

Sent, but not used

Here is one way both can be true at once. A leader can check whether the context was sent. A customer only experiences whether the person used it.

In between, four separate things have to go right, and each one can fail on its own:

• Did it arrive? The context reached the system the agent works in.
• Could the human see it? It showed up where the agent was looking, short enough to read.
• Was it there before they spoke? Context before connect: the card lands before the greeting, not after.
• Did they use it? The first thing they said showed they knew what had already happened.

A transfer log can answer the first question. The other three only show up on the agent’s screen and in the recording. Cresta’s own handoff guide makes the timing point as advice to its readers: the history, the details collected, what was tried and the reason for escalating “need to surface in the agent’s desktop before they connect with the customer, not after.”

Those four come apart in a few ordinary ways.

The summary arrives after the greeting. The details land in a screen pop (the panel that opens on the agent’s desktop when a call connects), but the agent is already talking, because in most of the contact centers I’ve worked with, agents are coached to answer quickly. By the time they glance at it, they have asked the question.

The summary is too long. Some teams pass the whole transcript. Nobody reads forty lines of conversation while a customer is waiting in silence.

The summary is somewhere else. It sits in a second tab, or in the CRM record, or in a Copilot panel the agent has collapsed because it was noisy yesterday.

And sometimes it is not there at all. Amazon’s troubleshooting table for escalations built with Amazon Connect’s Agentic CX designer has a row for exactly this: the agent receives no summary, and the likely cause it gives is a Set contact attributes step left out of the flow. It is a step your team has to remember, and an easy one to miss.

Then there is the plumbing, which is where my own background sits. Say a voice agent hosted in one vendor’s cloud hands a call to people working in another vendor’s contact center. In many cross-platform voice deployments, the call moves as a SIP transfer, often a SIP REFER (the signal that hands the call on) or a new outbound call leg. It lands in the ACD, the system that queues calls and routes them to a person. The context has to travel alongside it, and there are two usual ways to send it.

The first is to carry it inside the call itself, in the SIP User-to-User header (usually called UUI) or in custom SIP headers. For UUI the catch is size. The standard for passing UUI across older phone networks allows 128 bytes of user data. Genesys Cloud itself accepts far more where UUI is supported, but recommends keeping UUI to 128 characters or fewer, because some systems further down the line discard anything longer. That is an interoperability limit, not a Genesys one, and it is a small version of this whole article: what one system can send is not the same as what survives the trip. The same page says UUI is not available at all on Genesys Cloud Voice calls, and is unlikely to reach a station that is reached through the public phone network. Google’s contact center guide says much the same about forwarding a call over the public network: intent cannot ride along in the call metadata. Its recommended route is a SIP REFER over a bring-your-own-carrier connection, which can carry custom SIP headers.

For anything substantial, the header often carries a key rather than the whole story. The second way carries the story: the AI writes the full context to a store keyed by a correlation ID, and the agent desktop looks it up when the call arrives. I wrote about that plumbing, with a diagram, in why voice AI agents are harder than chatbots.

Every one of those paths can be working perfectly and the customer can still be asked for her date of birth. The data was sent, and nobody used it.

When to let go

There is a second failure that runs the other way: the AI holds on too long.

Gartner’s advice here is blunt: do not make AI a mandatory first step for every issue. When customers are forced through several unsuccessful AI attempts before they reach a person, they are less likely to use that tool again.

Four moments where the AI should let go, in my experience:

• The customer asks for a person. Always honour it.
• The AI is not allowed to do the next thing. Like the fraud hold in our call. That limit should be written down and enforced, which is the same idea as turning autonomy up one task at a time.
• It is going round in circles. How many failed attempts is too many depends on the task and how the flow is configured. What matters is that there is a limit, and the AI notices when it hits it.
• The customer is getting upset. In my experience, tone matters more on the phone than in chat, and pushing on through an angry caller often turns the next call into a complaint.

The first one hides a trade-off worth knowing about. On Salesforce Agentforce, by default, a request for a human skips the topic’s instructions, which Salesforce says prevents the agent “from collecting data or running tools before the handoff”. That is fast, and it is the right default for a customer who just wants a person. But it also means nothing new gets gathered for the human on the way out. Salesforce also describes a way to let a topic’s instructions hold the handoff until prerequisites are met, such as the customer providing an email address. Which one you want depends on how much you trust your summary.

What the person picking up needs

Three things, readable before they say a word. A transcript is the wrong shape for this.

1. Who this is, and what they have already proved. Name, account, and how they were verified.
2. What they want, in one line. In her words where possible.
3. What has already been tried, and why it stopped. So the human does not repeat it.

For the engineers in the room, here is roughly what the AI should hand over for our call. The field names are illustrative, not any vendor’s schema.

handoff:
  customer_id: 'C-48213'
  verified: true
  verified_by: 'one-time passcode to registered mobile, 14:02'
  wants: 'Card declined abroad; needs it working today'
  tried: 'Confirmed last three transactions with customer'
  stopped_because: 'Card on fraud hold; lifting it needs a person'
  mood: 'Calm, short on time'
  summary: 'Travelling customer, verified, card blocked by fraud hold. Transactions confirmed as hers.'

That will not fit in the 128 characters Genesys recommends for UUI, which is the point about headers earlier. A short key goes in the call, and the rest is looked up.

Now the uncomfortable part. Look at the second field.

Your fraud or security team may well require the person to verify the customer again after a transfer, whatever the AI did. They can have good reasons for that, and a handoff design that quietly overrides them is not a design I would sign off. So in our call, re-asking might be correct.

What is not correct is re-asking without saying why, and without using anything else the AI learned. Here is the difference in the first few seconds:

The last row still asks her to verify. She does not mind, because she can tell she was heard.

What each platform gives you at the handoff

Your teams may be on any of these platforms, so here is what each one publishes about the three things above. Where I could, I read their own documentation. Where the docs sit behind a login, or only a product page, blog or customer story says it, the table labels that as the vendor’s claim.

The first thing that sorts them is where the handoff crosses from one system into another.

If you run Amazon Connect, Genesys Cloud, Five9, NICE CXone, Google’s Customer Engagement Suite, Microsoft Dynamics 365 Contact Center, Salesforce Agentforce or Dialpad, and you use that same platform’s AI agent, the handoff can stay inside one system, and the context has a natural place to land. It still needs to be set up well, but you are configuring one product. Salesforce says the architecture point out loud. On its own voice telephony, it says the full call transcript and session context are preserved through transfers between AI and human. With third-party telephony, it warns, data “can become fragmented, or context can be lost, when an interaction is handed off.” Five9 says its Voice AI Agents support context-rich warm handoffs that carry full conversational context, though its public technical material says less about the field-by-field mechanism. I found no voice mechanism in Dialpad’s docs.

If you put a specialist AI agent such as Sierra, Parloa, Omilia or a standalone Cognigy in front of another vendor’s contact center, the handoff crosses from the AI platform into a separate contact center system. In my experience that is where context is easiest to lose, because each side can say, truthfully, that it did its part. The question to ask in that sale is simple: show me what our agent sees when your AI transfers a call into our Genesys, or Connect, or CXone. Not the architecture diagram. The agent’s screen.

Cresta sits in that second group, because the call itself runs through your existing contact center. It is a little different from the others there: it also sells Agent Assist for the human who picks up, so it can put the context on the receiving agent’s desktop as well as send it across.

A few things stand out once they sit side by side.

Genesys, with conversation summarization switched on, generates a summary when a Virtual Agent escalates and shows it beside the receiving agent’s interaction panel, so more of the escalation summary comes ready-made. Amazon Connect has handoff built in too, with an Escalate tool on its AI agents by default, and it gives you the flow steps to carry context to the agent. But more of what the agent finally sees, how the call is routed and what pops up on screen is left to your implementation. Neither approach is wrong, but they put the work in very different places, and a buyer should know which one they are signing up for.

If you build the AI agent yourself, handoff becomes an integration problem rather than a platform feature. Agent infrastructure such as Amazon Bedrock AgentCore can run the agent and support human-in-the-loop workflows, but your team still has to design how the conversation context, summary and escalation reason reach the contact center platform and the human agent. Those are two different patterns. In human-in-the-loop, the AI pauses, a person reviews, approves or adds input, and the AI may carry on. In a customer handoff, the AI stops owning the conversation and a contact center agent takes it over. This article is about the second.

Two of the specialists are harder to assess from outside. Parloa says plainly that authentication and conversation history are delivered at transfer, through CRM updates, screen pops and escalation summaries, and it names the platforms it integrates with. Sierra describes contextual handoffs and more than 40 integrations without naming the contact centers. Both keep their detailed docs behind a login. What neither shows in public is the vendor-by-vendor detail: how the handoff context is carried into, and shown in, each receiving contact center. Omilia and Cognigy publish much more of that implementation detail, which tells you about their documentation, not about which product is better. Sierra’s and Parloa’s handoffs may be perfectly good. You just cannot tell from outside, so ask to see it, on your own contact center, before you sign.

And the last column. Most of the platforms I checked count escalations. In what I read, I found no built-in measure of whether the person who picked up could use what arrived: whether they had to ask again, or whether the customer called back. Cresta and Sierra both publish guidance saying you should measure what happens after the handoff, such as repeat contact, and Sierra ships a monitor for what it calls “false transfers”, but neither documents such a measure built in. Amazon has a score for context quality, but it covers handoffs between AI agents, not to a person.

Which brings us back to the survey. If the dashboard only counts handoffs, it cannot tell a leader whether the context was used or only sent.

If you are still choosing a platform, my comparison of voice AI and IVA platforms for contact centers covers the wider question of who owns the conversation logic when it has to change.

How to tell a good handoff from a bad one

The rule I use is simple. Judge the handoff from the human’s side. If the person picking up asks for something the customer already said, without knowing the customer already said it, the handoff failed, whatever the logs say was passed.

Re-verification is a different thing. “I can see you already verified with our automated system. For this change I need to run one more security check” is a handoff that worked. The person knows what happened and says so.

You do not need a new platform to check that. Three things, in order of effort:

Listen to twenty recorded transfers. Yourself, not a sample report. Note the first thing the agent says. You will know within an hour whether the context is arriving, whether it is being read, and whether it is useful.

Check whether the same customer called back. A customer who calls again within a day or two about the same issue is a useful signal that the first interaction may not have resolved it, however smooth the transfer looked. This connects directly to measuring resolution rather than deflection.

Ask your agents. They know exactly which summaries they trust and which ones they have learned to ignore. That knowledge rarely reaches a dashboard.

Then fix the thing the recordings point to. In my experience, the failure is often not the AI itself. It is where the summary shows up, how long it is, or a step someone left out of the flow.

That leaves the question from our call, and I do not have a clean answer to it. If your bank requires a person to verify a customer the AI has already verified, the customer will be asked twice. You can make that feel respectful instead of careless, by saying why and using everything else you know. I have very rarely seen a team that has worked out when the AI’s verification could be trusted enough to skip the second one, and who in the bank gets to decide that. That is a conversation between CX, fraud and security, and few of the organizations I have seen have had it yet.

The design principles behind that kind of decision, what an agent is allowed to do and how you prove it, are the subject of Designing Enterprise Agentic AI Systems.

If you want help getting the handoff right on your own platform, including what the human sees, how the context travels and what to measure, that is part of the voice AI development work I do.