'"Transfer to a Human" Is Not One Feature — It Is Five'

When a vendor says "it transfers to a human", they are describing a button. When your customer experiences a transfer at 19:40 on a Friday, they are experiencing the result of five separate configurations — and if any one of them is wrong, the call dies.

This is the least glamorous part of voice automation, and the part most likely to be untested before launch.

The five pieces

1. Who is on shift right now. Not the team, not the group — the specific person whose phone should ring at this moment. That requires a roster, and a roster that is actually maintained.

2. Whether that person is available. Being on shift is not the same as being reachable: they may be on a break, in another call, or away from their desk. A handoff that ignores this tries a number that will not be answered.

3. What time it is where they are. If your team spans time zones, "9 to 5" is ambiguous. A transfer at 17:30 in the customer's zone may be 08:30 the next morning for the person receiving it.

4. Whether the destination number is verified. Sending a live customer to an unverified number is a data protection incident waiting to happen, and it is also a common cause of failed transfers — the number was wrong, or belonged to someone who left.

5. Which rules apply in this country. Transfer behaviour is not always the same everywhere: working days differ, so do public holidays, and so does what customers expect from a "call you back" promise.

What breaks at 7pm

Play the scenario that catches most deployments:

A customer calls at 19:40 on a Friday, asks for something that requires a person, and your office hours are 9–17 Monday to Friday.

Four possible outcomes, and only one is acceptable:

• The transfer fails and the call drops. Worst. No record, no callback.
• The transfer connects to a personal mobile that nobody answers. The customer hears ringing, then nothing.
• The agent says "we're closed, call back Monday." Honest, but it wastes a call that was ready to convert.
• The agent captures the request, states clearly when they will be called back, and records it. Acceptable, provided the callback actually happens.

The fourth is not the same as "take a message". A message with no owner and no time is a promise the business will break. A callback with a named owner and a stated window is a commitment the business can keep.

The lunch problem

This one is small and absurdly common.

A one-person office, hours 9–17, lunch 12–13. An agent transfers at 12:20 to a number that rings in an empty room. The customer waits, hears nothing, hangs up — and neither the agent nor the business has any record that a live enquiry was lost.

If your handoff does not know about breaks, it does not know about availability, and it will route calls into a void four hours a week.

The questions to ask before launch

"What happens if the person is already on a call?" The correct answer involves either a defined fallback (another person, then a callback request) or an honest queue. "It rings out" is a failure.

"How does the system know who is on shift, and who updates it?" If the answer is "we update it in the system", ask who, and how often, and what happens when they forget.

"What does the customer hear when no one is available?" This should be a sentence you have written, not a default.

"How do we know a transfer actually connected?" You need a record. Without it, failed transfers are invisible — the same silent failure mode as a missing default route.

Design the failure path first

The instinct is to design the happy path: customer calls, agent understands, transfers to the right person, everyone is happy.

Do the opposite. Design these four first:

1. Nobody is on shift. 2. The person is on a break. 3. The person does not answer. 4. The destination number is wrong.

Each of those is common, and each turns a good conversation into a lost customer. Once they have a defined behaviour, the happy path is easy.

The organisational half

A handoff is not only a configuration. It is a commitment by the team to be reachable in the hours the agent promises.

If the business says "we answer 24/7" and the roster only covers 9–5, the agent is the thing that makes the lie visible. That is not a technology failure — but it will be blamed on the technology.

Two ways to avoid it: either the agent only promises what the roster supports, or the roster grows to meet the promise. Both are fine. Pretending the gap does not exist is what generates the bad review.

A modest standard

A handoff is in good shape when you can answer these without looking anything up:

• Who gets this call right now?
• What happens if they do not pick up?
• What did the customer hear when it failed?
• Where is the record of it?

Four answers, no ambiguity. That is the bar — and it is a much higher bar than "it transfers to a human".

Disclosure: I work on RingBot, an Agent-as-a-Service platform where handoff can target a team with availability, a specific verified number, or a configured time window, with per-country routing rules. The failure paths above are the ones worth designing on any platform, including a phone system from 1998.

Related: the handoff brief, when to hand off, per-country configuration, missing default route.