We were proud of the transfer. It worked on the first try, the call reconnected cleanly, nothing dropped, and the queue wait that quarter was under ten seconds. We had spent a sprint on it.
Then I listened to one.
The caller had spent just over four minutes with the voice agent. She had given her account number, confirmed her address, described a duplicate charge, and read out the last four digits of the card it hit. The agent could not issue the refund, which was correct, that path needs a human. So it transferred her.
The human picked up and said "Hi, thanks for holding, how can I help you today?"
She said all of it again. The account number, the address, the duplicate charge, the last four digits. Four minutes of work, done twice, and the second time by a person who costs us money per minute.
What actually crosses the transfer
The thing I had not understood is that a warm transfer moves the call, not the conversation.
The call is a SIP leg. Moving it is a solved problem and that is the part we had spent the sprint on. The conversation lived somewhere else: in the agent's session state, in a service the contact-centre desktop had never heard of. What the human's screen showed when the call arrived was what it had always shown, a caller ID and a queue name.
So the human was not being lazy. They opened with a wide-open prompt because that is the only safe move when your screen tells you nothing. Anything more specific risks guessing wrong at a caller who is already annoyed.
I should be clear that the mechanism for carrying context across a transfer is not something anybody needs to invent. Screen-pop, attached data on the call, user-to-user information on the transfer itself: contact centres have had these for decades, and every platform I have worked with exposes some version of them. We had simply never wired the voice agent into any of it. The agent had been built to handle calls, and the transfer got treated as its exit door.
The channel existed. What follows is about what turned out to be worth putting in it, which was much less than I expected.
Week one, and the fix that changed nothing
We did the obvious thing, which was to put the transcript on the screen.
The whole four-minute transcript, in a panel, on screen-pop. It was live within a few days. Average handle time on the human leg did not move, and when I sat with the support team I understood why in about a minute.
An agent has a beat of about two seconds between the call arriving on their headset and having to speak. Nobody reads four minutes of dialogue in two seconds. They also cannot skim it, because the useful facts are scattered through it in whatever order the caller happened to say them. Two of the people I watched had already closed the panel by the time they said hello. One told me she had stopped opening it in the first week, because reading it while listening to a live caller made her lose the thread of what the caller was saying now.
We had moved the data and left the work where it was.
The number that finally made the case
I could not get anything else prioritised on the strength of one recording, so we built a measurement.
We called it the re-ask rate, and the definition took three tries. It ended up on the caller's channel: the share of transferred calls where, in the first sixty seconds of the human leg, the caller re-states information the agent had already captured. That is the same side of the call I count repair on, scoped per call and across the transfer instead of within a single leg.
Putting it on the human's channel was the first two tries, and it fails twice over. It misses the commonest case, because in our opening recording the human asks for nothing specific: they say "how can I help you today" and the caller volunteers everything unprompted. It also punishes the eventual fix, because a human holding a card starts saying the account number out loud to confirm it.
The caller channel has a hole of its own, which took the third try to close. When the human reads a fact back and the caller says "yes, 4471", that is an exact entity match on the caller's side, and it is a confirmation rather than a re-statement. So a caller-side match is excluded when the same entity appeared on the human channel in the immediately preceding turn. Without that clause the metric gets worse exactly as the experience gets better.
It needs dual-channel audio, which we already had for quality monitoring, and is otherwise cheap. We had the entities the agent extracted, account number, address, the disputed amount. Matching those against the caller-side transcript of the first minute is mostly string comparison. Where a match was genuinely ambiguous we excluded it from the numerator and hand-reviewed a sample each week, to check the exclusions were not hiding a pattern.
The first run came back at 62 percent, with the transcript panel already live. Almost two thirds of transferred calls had the caller repeating something the system already knew, and the median call had two separate facts in it.
That number did what the recording could not. Nobody argues with 62 percent.
Why it stayed invisible is more specific than "we had no metrics", and I want to be accurate, because we did have one that crossed the transfer. Our session-outcome metric knew perfectly well when a call had handed off. Escalation was one of its outcome values and it counted against the agent. What it recorded was that the handoff happened. Nothing looked at what happened inside the human leg afterwards, so the agent's numbers ended at the transfer, the human leg's handle time started at it and was benchmarked against other transferred calls carrying the same defect, and the waste sat in the join.
That join had no owner. The voice team's dashboard was accurate, the contact-centre team's dashboard was accurate, and the broken thing was on neither.
What we shipped
Not the transcript. A handoff card, three lines, rendered before the human's phone rings.
The first line is what the caller wants, in the agent's words, one sentence. The second is the facts already confirmed, labelled, so the human can open with "I have your account here". The third is why the call transferred, which is usually the one thing the agent could not do, and this mattered more than I expected: knowing the agent had already failed at something tells the human where not to start.
We also stopped auto-populating anything the agent had captured with low confidence. Handing a human a wrong address confidently is worse than handing them nothing, because they will read it back and be wrong in front of the caller. Below the confidence threshold the field is simply absent from the card, with no caveat, because a caveat is one more thing to read inside that same two-second beat.
Re-ask rate went from 62 percent to 18. Most of what is left is one case: transfers that touch payment details, where the human has to re-verify identity from scratch whatever the screen says. Those run at about one call in seven of our transfers, which puts a floor somewhere near 15 percent. The remainder is a small tail, and part of that tail we inflicted on ourselves with the omission rule above, since a field the card leaves out looks identical to a field nobody captured, so the human asks. I took that trade. Eighteen is close to our floor, and I stopped pushing.
Average handle time on the human leg came down by 47 seconds, which is roughly what the arithmetic predicts and the main reason I believe it: a 44-point drop in calls that were re-asking a median of two facts, at a bit under two minutes to ask for two facts, wait while the caller finds them, read them back and confirm them.
Which brings me back to the caller in the opening. Her transfer was a payment dispute, so she sits in exactly the class the compliance rule covers. The card would not have saved her the identity check, and that check takes the account number and the address, so she would have given those again either way. What it would have saved her is the dispute: the duplicate charge, the card digits, the whole explanation she had already given once to a machine that understood it perfectly.
The part I keep thinking about
The voice agent was never the problem in this story. It captured everything correctly, it made the right call about what it could not do, and it transferred cleanly. Every metric pointing at it was green and every one of them was honest.
We had built the agent to handle calls. The business needed something that handed calls over well, and those have different success conditions, only one of which was on anybody's dashboard.
If you are running a voice agent in front of humans, the handover is a product surface with its own failure modes, and in most shops nobody has been asked to own it.
Three things I'd say to the guy who was proud of the transfer
Find out who owns the join. No amount of instrumentation fixes that until someone's name is on the seam.
The transcript panel shipped on time, did what the ticket said, and did not move average handle time by a second. It handed a human four minutes of reading and a two-second beat to do it in.
And listen to a transferred call before you design the transfer. I keep relearning this one, which is why it goes at the end where I will see it again, and the thing I needed has been audible inside a minute every time.
Top comments (0)