Passing to a person: designing the handoff in an automated process

No process is automated one hundred per cent, so every automated process has a point where it passes to a person. That handoff is almost never designed, and it is exactly where the benefit the automation had gained gets lost.

What follows: why the handoff is neglected, when it should happen, what it must carry with it, and how it is measured.

Anyone who has been a customer recognises the scene. A system takes the request, gets part of the way, and on reaching the limit of what it can resolve transfers to a person who asks everything again.

From inside it looks like an implementation detail. From outside it cancels the earlier work: the customer concludes the system wasted their time before taking them where they should have started.

Why the handoff is neglected

Because the project is defined by what it automates. The indicator presented is the percentage of cases resolved without intervention, and that number improves without anyone looking at what happens to the rest.

Besides, the automated path is the one that gets tested. Cases that leave the flow are, by definition, the least frequent and the least rehearsed, so they reach production with the least mature design.

And there is a quiet incentive: admitting a case needs a person feels like a limitation of the project, when in fact it is a legitimate design decision.

When passing to a person is the right call

When confidence is low. If the system is not reasonably sure it has understood, persisting produces worse results than transferring. The threshold is a business parameter, not a technical detail.

When the consequence is high. A recoverable error allows the system to decide; one affecting money, health or compliance deserves human confirmation even when confidence is high.

When the case falls outside the pattern. A legitimate exception should not be forced through the flow. Recognising it early and transferring is better than attempting it and failing late.

When the person asks. A customer asking to speak to someone is supplying information about their state. Ignoring it to preserve the automation statistic trades an internal indicator for a relationship.

What the handoff must carry

The principle is simple: the person receiving should start where the system got to, not from zero.

That means passing the full interaction history, the data already verified, what the system attempted, and the specific reason for the transfer. Without the reason, whoever receives it repeats the diagnosis.

It also means not asking again for what was already given. If the customer has identified themselves and explained their case, requesting it a second time communicates that the system and the person do not talk to each other, which is what the customer suspected.

And it is worth passing sentiment context where it exists: knowing the conversation arrives tense changes how the person picks it up.

What requires judgement

The transfer threshold is tuned with the operation, not got right at design time. Starting conservative — transferring earlier — and adjusting on evidence produces a better result than starting ambitious and correcting after complaints.

It is also necessary to decide what happens when nobody is available. A handoff designed for working hours that fires at three in the morning needs a planned response, not silence.

And handoffs are worth reviewing periodically. The most frequent transfer reasons are the best map of what to automate next, because they describe what the system does not yet resolve but is asked for daily.

How it is measured

The automation indicator on its own pushes in the wrong direction: it rewards holding on to cases that should be transferred.

It is worth pairing with first-contact resolution, including transferred cases. That measure treats the system and the person as one service, which is how the customer experiences it.

And a third, more revealing: how often the person receiving has to ask again for information the system already held. If that number is not close to zero, the handoff is badly built no matter how well the rest works.

What has to exist first

An agreed catalogue of transfer reasons and a technical channel that carries the full context. Without the second, the handoff happens with whatever the person can read off a screen.

It is also worth deciding from the outset that the handoff is part of the project’s scope and not a later task. Left for afterwards, it gets implemented in a hurry and with whatever budget remains.

The two handoffs worth telling apart

Not all handoffs are alike, and treating them alike is part of the problem.

The planned handoff is the one the design anticipated: the case reaches a point where a person always intervenes, such as an approval or a known exception. It can be prepared, it can be measured, and whoever receives it knows what to expect.

The failure handoff happens when the system cannot proceed and was not expected to stop. It is the one that arrives without context, the one that frustrates, and the one worth counting separately, because its number says how much the design is missing.

Mixing the two in a single statistic hides precisely the useful information: a process can have many handoffs and be well built, or few and be failing quietly.

Should a well-automated process avoid the handoff?

No. Every process has cases requiring judgement, and recognising them early is a design decision, not a limitation of the project.

What is the most common mistake?

Transferring without context. The person receiving starts from zero and the customer concludes the system wasted their time.

Which indicator is worth using?

First-contact resolution including transferred cases, rather than the automation percentage in isolation. The second rewards holding on to cases that should pass to a person.

What are transfer reasons useful for?

They are the best map of what to automate next: they describe what the system does not yet resolve and is asked for every day.