Call forwarding with AI: when a human takes over and who decides

A caller explains that the heating has been out since yesterday, the child is shivering and the appointment from Monday was never confirmed. The assistant has politely asked follow-up questions, taken the address and is offering the same appointment for the second time. The voice on the other end grows quieter, then sharper. This is the moment that decides whether automation helps the business or harms it.

This scenario is made up, the pattern is not. Almost everyone who automates telephony will sooner or later meet calls in which further politeness makes things worse. The question is then not how intelligent the assistant is, but whether it recognizes that it has reached a limit, and what happens at that moment.

In this concept study we therefore look not at the successful standard case, but at the seam between machine and human. When does the assistant forward a call? To whom, in what way and with what information in hand? And which decisions should it not make in the first place? Anyone who answers these questions in writing before launch saves themselves the answers an angry customer would otherwise give.

The first trigger is emergencies. A water leak, a smell of gas, severe pain, a fall: anything that sounds like acute danger does not belong in an appointment calendar. The assistant cannot help here and must not cost any time. It should point to the emergency number where appropriate and at the same time alert a person in the business who decides.

The second trigger is angry callers. Anger is rarely clear-cut. It sits in volume and pace, in repetitions such as “I already told you that,” in phrasing heading toward a complaint, a reminder or a cancellation. The third trigger: existing customers of particular importance, such as ongoing large orders, property managers or people the owner looks after personally. With them, the task is not delicate, but the expectation of how they are addressed is.

The fourth trigger is the uncertainty of the system itself. Speech recognition does not always understand dialect, background noise or technical terms, and language models can invent plausible-sounding answers. An assistant that does not name its uncertainty is more dangerous than one that hands over too often. Better one handover too many than a wrongly confirmed commitment.

A fifth, inconspicuous trigger is often overlooked: the explicit wish to speak to a human. It needs no weighting and no justification. Anyone who says this sentence is handed over, even if the assistant could resolve the question. Anyone who argues here loses the caller, and with them the trust in everything else the assistant does well.

What all these triggers have in common is that no single keyword captures them reliably. “Water” can mean a burst pipe or a question about a water filter. That is why a list of forbidden words makes a poor foundation. What works better is the combination of several signals that together cross a threshold.

People in the office rely on instinct: the voice sounds angry, the name rings a bell, the matter seems urgent. This instinct is valuable, but it is not transferable. Anyone who merely tells an assistant to “forward when there are problems” has not delegated the decision but left its outcome to chance. Two conversations with the same content then end differently.

A rule set makes the decision verifiable. It records which signals count, how they are weighted and what follows when one is triggered. That has a further advantage: it can be changed. If it turns out that too many harmless calls land with the owner, a rule is adjusted, not a mood. Unclear responsibility becomes a line in a document that someone owns.

There is an opposing danger that we take just as seriously. A rule set that is too strict forwards everything and makes the assistant redundant, because staff now receive the same call with a delay. The task is therefore to set the thresholds so that handover remains the exception without critical cases slipping through. That does not succeed with the first draft, but through observing real conversations.

An example of the difference: a caller says twice “I need someone who can decide,” without raising her voice. A sentiment model may not react here; a rule for repeated escalation requests does so immediately. Conversely, a regular customer sometimes sounds curt on the phone without being angry. That, too, is an argument for several signals instead of a single one.

Then there is the question of the consequences of an error. An unnecessary handover costs three minutes of attention. A missed handover in an emergency or a complaint can cost trust, orders or worse. This asymmetry belongs in the weighting: when in doubt, hand over.

We would not build the handover logic as a list, but in layers that each answer a different question. The first layer detects immediate triggers, meaning situations in which any further follow-up question is dropped. The second collects and weights indications, such as repetitions, tone, customer status or repeated failure to understand each other. The third layer chooses to whom and how the call is handed over.

Each alternative has something against it. A pure keyword filter is easy to understand but produces many false alarms and overlooks urgency delivered calmly. An assessment made solely by the language model seems flexible but is hard to justify and can shift unnoticed when the model is changed. The layering combines both: hard rules where clarity is needed, weighted indications where there is room for judgment.

There is no universal value for the threshold of the second layer, and we deliberately name none. It is set cautiously at the start and then calibrated on conversations. That means: at first the assistant tends to hand over too often, the business listens in, and every handover is afterwards marked as justified or unnecessary. The fine-tuning emerges from this marking.

What matters is that the rules live outside the prompt. If they are kept in configuration or tables, office management can read them and have them changed without touching a wall of instructions. This keeps responsibility where it belongs.

In a warm transfer, the assistant calls the target person while the caller waits, and briefly summarizes the case before the two are connected. The customer does not have to repeat anything. A cold transfer connects without advance notice and is faster, but the employee does not know who is on the line or why. A callback, finally, takes down the request and promises a conversation at a stated time.

Which type fits depends on the trigger and on availability. Emergencies and angry callers deserve a real connection, as long as someone picks up. So do existing customers with special status, ideally to their known contact person. Simple questions that merely need a human answer are better served by a callback than by a long wait.

The callback has a weakness that is gladly kept quiet: it is a promise. If it is not kept, the damage is greater than with an honest refusal. That is why the assistant only names times the business can actually keep, and the callback lands as a task with a deadline in a system someone looks at. A note without an owner is not a solution.

With a warm transfer, waiting time counts. Nobody wants to listen to 40 seconds of music while the assistant rings in vain. An upper limit for ring time and attempts therefore belongs in the rule set. If the attempt fails, the assistant moves openly to the next level and tells the caller what is happening, instead of acting as if nothing had happened.

Technically, the handover is an interplay of the phone system, the assistant and a service that knows the status of the staff. The assistant does not decide alone who is available. It queries a service that forms an answer from presence, calendar and phone status, such as “Person A is on a call, Person B is free.” The connection is usually made through the phone system’s interfaces, whose capabilities differ by provider and must be checked before the design.

Availability hours are more than opening hours. They distinguish core hours, standby, breaks and public holidays, and they know substitutes. A rule such as “after 5 p.m. only emergencies to the on-call service, everything else into the next morning’s callback list” must be formulated explicitly, otherwise the owner gets a call at night about an appointment question.

For every handover, a record is created: time, phone number or customer assignment, trigger, detected signals, short summary, chosen target, result of the attempt. It goes simultaneously to the employee taking over and into the ticket or customer system. It also states what the assistant promised. This way nobody can later claim nothing was said, and the business can reconstruct wrong decisions.

Data protection belongs in this design from the start: what is recorded, how long is the log kept, who sees it, and is the caller informed at the start that an AI assistant is speaking? These are not details for later. The answers should be clarified with the business’s data protection officer or legal advisor; this text is not legal advice.

The rule set must also cover the cases in which the handover itself fails. Nobody picks up, the target is busy, the phone system does not respond, the assistant’s provider has an outage. This is where it shows whether a solution was built for everyday use or only for the demo. We therefore plan a chain of fallback levels that takes effect according to fixed rules.

A typical failure pattern: the forwarding points to the extension of a person who is on vacation, and nobody has maintained the call diversion. The assistant rings into the void, the caller hears silence. That is why the system checks the target’s status before the attempt and does not rely on a number entered months ago.

The first level is the substitute: if the target person does not answer, the next one in the sequence is called after a defined time. The second is the callback with task and deadline. The third, and here no language model helps, is a simple forwarding to a fixed phone number or voicemail that works even when the assistant can no longer be reached. This diversion is stored in the phone system, not with the AI provider.

The failure of the assistant is the case most easily forgotten. If the connection to the provider drops, the system needs a timeout after which it switches on its own to the default routing: let it ring, voicemail, on-call number. This switchover should be tested regularly, ideally with a scheduled test call, and it should be reported internally so that someone learns of the outage before customers do.

Honesty toward the caller matters. A sentence like “I can’t reach anyone right now, a colleague will call you back by this afternoon at the latest” is better than more waiting or silently hanging up. Whoever tells the truth can keep it, and that is the yardstick for every commitment.

The benefit of a regulated handover lies mostly in what does not happen: fewer lost requests, fewer callers who have to give the same information three times, fewer surprises for staff. That sounds unspectacular and is precisely why it is hard to prove. A concrete improvement cannot be promised across the board; it depends on call mix, staffing and the quality of the rules.

Some figures that arise in the log anyway are measurable, however. These include the share of calls that are handed over, broken down by trigger. The share of handovers that are later rated as unnecessary or too late. The rate of successful warm transfers compared with callbacks, and the share of callbacks completed within the stated deadline. The distribution of these values shows where the rule set needs sharpening.

In addition, spot-checked conversations, listened to or read, serve as a check, as far as the business records them and this is permitted. Qualitative signals count too: complaints about the phone, questions within the team, remarks that customers “never reached anyone.” Comparing the development over several weeks gives a reliable picture.

What cannot be promised, we state explicitly. There is no guarantee that every instance of anger is detected, because tone and language are ambiguous. There is no guarantee of particular rates, and speech recognition remains error-prone. The system’s task is therefore to make errors visible early and limit their consequences, not to rule them out.

From the experience of many concepts of this kind, a basic rule can be derived: decisions involving liability, money or health stay with humans. The assistant may take in information, suggest appointments and give information from approved sources. It does not promise that damage will be covered, it does not quote binding prices for special cases, and it gives no medical or legal assessment.

This also includes goodwill gestures, discounts, cancellations outside the rules, terminations and anything that sounds like a complaint with consequences. The assistant can listen, record the request in a structured way and honestly say that a person decides on this. That is not a weakness but a mark of credibility. Anyone who promises something wrong on the phone may bind the business in a way that is hard to correct afterward.

It should be equally clear what the assistant says about itself. If someone asks whether they are speaking with a human, it answers truthfully. It gives no information about other customers and confirms no data before the person has identified themselves sufficiently, as far as the business provides for this. These limits belong in the rule set as a positive list: what is allowed is listed, everything else leads to a handover.

For medical practices and similar businesses in particular, the limits need to be drawn more tightly than in the trades. Pre-existing conditions, urgency of symptoms or medical information must not be assessed by an assistant. It takes down and passes on. Determining which rules apply in your industry is a matter for professional and legal advice on site.

Anyone introducing an AI phone assistant should start with the handover, not the greeting. It determines whether callers trust the system, because they know a human is available at the decisive moment. AI call forwarding escalation is therefore not a side issue but the part where seriousness shows.

A simple exercise makes a good first step: write down the ten most delicate calls your business had in recent months, and note for each who ideally should have taken over and with what information. This produces the draft of a rule set. It is incomplete, but it is concrete, and it can be worked on.

Three insights carry furthest. First: rules belong to the business, not the provider, and should be readable without programming skills. Second: the fallback level is part of the product and is tested like any other function. Third: the log is not a control instrument but the source of learning from which the rule set improves over weeks.

We develop such rule sets together with the people who will later take the calls, and test them before launch with role-played conversations. Whether an assistant is worthwhile for your business, we discuss honestly, even if the answer is that a better-organized answering machine is enough.