When should an AI receptionist transfer to a human?
An AI receptionist should transfer to a human whenever the caller asks for a person, the request needs judgment the business has not authorized it to make, a required system or answer is unavailable, or the call type is one your team has marked for human handling. Everything else it can finish on its own.
That sentence is easy to agree with and hard to operate. The gap is that most businesses never write the triggers down. They configure a greeting, connect a calendar, forward the line, and then discover the boundary the expensive way, on a call that mattered.
This guide covers the part that actually decides whether an AI receptionist helps or hurts: the outcome tiers every call should land in, the triggers that move a call between them, what the handoff has to carry, what happens when nobody picks up, and how to tell from your own call records whether the rules are working.
The four outcomes every call should end in
Escalation is not a single switch. Treating it as "AI or human" is what produces both failure modes: a receptionist that transfers everything and saves nobody any time, or one that stubbornly handles calls it should have passed on. Give every call one of four outcomes instead.
| Outcome tier | What the receptionist does | Use it when | What the caller hears |
|---|---|---|---|
| Answer and close | Answers from approved business information and completes the call | The question is inside the approved knowledge and no action is needed | A direct answer and a confirmed close |
| Act and confirm | Books, reschedules, routes or records the approved action, then confirms it | The request matches an approved action and every required detail is present | Confirmation of what was done, only after the system succeeds |
| Capture for a person | Collects the defined details and hands the request to the responsible person | The request is valid but a person must decide, approve or investigate | What was captured, who receives it, and the real next step |
| Transfer now | Connects the caller to a person during the call | The caller asks for a person, or the call type requires live human handling | That they are being connected, and to whom |
The two middle tiers do most of the work. A business that only has "answer" and "transfer" will over transfer, because every request that needs any judgment becomes a live call. Capturing a complete request for a person is usually faster for the caller and far less disruptive for your team.
What should an AI receptionist never handle?
Some calls should never end in an automated answer, no matter how good the transcript looks. Write this list before you write anything else, because it defines the edge of the job.
- Decisions that require a licensed or credentialed professional. Clinical, legal, financial and similar judgments belong to the person who carries the responsibility for them. The receptionist can collect context and route it.
- Anything that commits the business. Quotes, discounts, scope changes, payment arrangements, warranty decisions and contractual promises should route to whoever is authorized to make them.
- Requests the knowledge base cannot answer. An unknown answer is a routing event, not an invitation to improvise. This is the single most common source of a bad automated call.
- Anything the caller says is urgent under your own definition. Define urgency in your own operational terms, in writing, and give it a dedicated path that does not depend on the receptionist interpreting tone.
- A caller who has asked for a person. Once someone asks, the answer is yes. Adding two more qualifying questions first is how you lose them.
- A caller who is clearly distressed or has failed twice. Repeated misunderstanding is a signal in itself. Route it rather than trying a third rephrasing.
This is an operational boundary, not a legal opinion. Businesses in regulated fields should confirm their own requirements with their own advisors before automating any call type.
The principle behind the list is not specific to phones. The NIST AI Risk Management Framework states that risk management efforts "should prioritize the minimization of potential negative impacts, and may need to include human intervention in cases where the AI system cannot detect or correct errors" (AI RMF 1.0, section 3.1). The same framework's MANAGE 2.4 outcome asks that mechanisms exist, and responsibilities are assigned and understood, to supersede, disengage or deactivate a system whose behavior does not match its intended use. In a small business that translates to a plain question: who can turn this off, and how fast?
Escalation triggers you can actually configure
A trigger is only useful if it maps to something the system can observe. "Escalate if the call is important" is not a rule. These are.
| Trigger | What the system observes | Outcome tier | Why it matters |
|---|---|---|---|
| Explicit request | The caller asks for a person, the owner, or a named employee | Transfer now | The highest intent signal on the call. Honor it immediately |
| Knowledge miss | The question falls outside the approved knowledge base | Capture, or transfer if the call type requires it | Prevents an invented answer, which is the costliest failure |
| Authority limit | The request maps to a call type marked as human only | Transfer now | Keeps commitments and professional judgment with people |
| Repeated misunderstanding | Two consecutive failed attempts to resolve the same intent | Transfer now | Caller patience is already spent by the third attempt |
| Tool or system failure | The calendar, CRM or scheduling tool errors or times out | Capture, and say plainly that nothing was booked | Never confirm an action the system did not complete |
| Missing required detail | A detail needed to complete the action cannot be collected | Capture with what is available | A partial record beats a dropped call |
| Caller distress | The caller states an emergency or an urgent condition you defined | Your defined urgent path | Tone detection is unreliable. Trigger on stated conditions |
| Out of scope caller | Vendor, recruiter, or a request no call type covers | Capture, or route per your rules | Stops unclassified calls from becoming silent drops |
Two of these are worth defending against pressure to soften. The explicit request trigger should have no qualifying questions attached to it. The tool failure trigger should never produce a confirmation. If your scheduling tool is down, the honest sentence is that the request was captured and someone will confirm the time, not that the appointment is booked. Our guide to AI receptionist appointment scheduling covers the booking side of that boundary in more detail.
Builders of voice systems treat this as design work rather than configuration trivia. OpenAI's voice agents guide describes attaching tools, handoffs and guardrails to a voice agent the same way you would for a text agent, and its guardrails and human review guide frames the pairing directly: guardrails and human review "define when a run should continue, pause, or stop," with human approval used to pause before sensitive actions. A phone call is the same problem with a caller waiting on the line.
What a good handoff has to carry
Most escalation disappointment is not a failure to transfer. It is a transfer that arrives empty. The person picks up, the caller repeats everything, and the automation has added a step instead of removing one.
Microsoft's Copilot Studio hand off to a live agent documentation describes the standard worth holding a phone system to: when the agent hands off a conversation, "it can share the full history of the conversation, and all relevant variables," and the person who receives it "sees an alert, reviews the conversation history, and continues the conversation." Continues, not restarts.
Define what every handoff must include before you launch:
- Who is calling and a callback number that was confirmed out loud
- Why they called, in the caller's own framing rather than a category label
- Every detail already collected, so nothing is asked twice
- What the receptionist already told them, including anything it promised
- Which trigger caused the escalation, so the receiving person knows what went wrong
- What the caller is expecting to happen next
Then test the reverse: can the person receiving the handoff open the call cold and continue it without asking the caller to start over? If not, the handoff is incomplete no matter how smooth the transfer sounded.
What happens when nobody picks up
This is the step almost every setup skips, and it is where escalation rules quietly fail. A transfer rule that assumes a person always answers is not a rule, it is a hope. Small teams are on jobs, with customers, or asleep.
Build a ladder with a defined end, and make sure the last rung always works.
- Attempt the primary destination for a defined number of rings
- Attempt one named backup destination, not a general queue nobody owns
- Tell the caller plainly that the person is not available right now
- Capture a complete message including the original escalation reason
- Confirm the callback detail and state only the response expectation your team has actually committed to
- Notify the responsible person immediately through a channel they genuinely watch
The fifth rung is where trust is won or lost. Do not let the receptionist promise a fifteen minute callback because it sounds reassuring. Promise what your team delivers on a busy Tuesday. If you cannot name that number, the honest version is to say someone will follow up and to name the person. For calls that land outside staffed hours, the after hours answering service guide covers the coverage models behind this ladder.
How to write escalation rules that do not annoy callers
Escalation rules fail in two directions, and the fix for one makes the other worse. Watch both at the same time.
| Failure mode | What it looks like | What it costs | The correction |
|---|---|---|---|
| Under escalating | The receptionist keeps trying on calls it cannot resolve | Invented answers, frustrated callers, lost jobs you never hear about | Add explicit triggers for knowledge misses, authority limits and repeat failures |
| Over escalating | Routine questions get transferred or captured for a person | Your team is interrupted as much as before, and the tool looks pointless | Widen the approved knowledge base rather than loosening the escalation triggers |
The correction for over escalating is the one people get backwards. When too many calls reach a person, the instinct is to make the receptionist try harder. The safer fix is almost always to give it more approved information to answer from. Keep business facts in the knowledge base and keep behavior rules in the call flow, so widening one does not quietly loosen the other. The AI receptionist script template shows how to keep those two layers separate.
A few wording rules that consistently hold up on real calls:
- Say what is happening before it happens, so a transfer is never a surprise silence
- Name the destination when you have one, because "transferring you now" tells the caller nothing
- Never apologize for escalating. It is the system working, not failing
- Do not ask for information the person receiving the call already has
- Offer one alternative when a transfer cannot connect, not a menu of three
How to test escalation rules before you go live
Escalation paths are the least tested and most consequential part of a call flow, because the happy path is the one everyone demos. Test the exits deliberately.
| Test call | Pass condition |
|---|---|
| Caller asks for a person in the first sentence | Transfer begins immediately with no additional qualifying questions |
| Caller asks something outside the knowledge base | No invented answer. The configured capture or transfer path runs |
| Caller requests something only an authorized person can approve | The request is captured or transferred, with no commitment made on the call |
| Transfer destination does not answer | The full fallback ladder runs and ends in a complete message |
| Connected calendar or CRM is unavailable | Nothing is confirmed as booked, and the caller is told the real status |
| Caller is misunderstood twice in a row | The call escalates rather than attempting a third rephrasing |
| Caller states an urgent condition you defined | Your urgent path runs exactly as written, during and after hours |
| Same call after any rule change | Previously passing escalation paths still pass |
For each test, check four layers rather than one: what the caller heard, what the transcript recorded, what reached the person, and what that person could actually do next. If those four disagree, the rule is not ready. The broader AI receptionist setup checklist covers the rest of the launch sequence around these tests.
How to measure whether your escalation rules are working
Answer rate tells you the phone was picked up. It says nothing about whether the right calls reached the right people. Review these instead, monthly at minimum.
| Measure | What it tells you | What to do when it moves |
|---|---|---|
| Escalation rate | Share of calls that reached a person in any form | Rising usually means a knowledge gap, not a broken receptionist |
| Escalation reason mix | Which triggers are firing most often | A dominant single trigger points at one fixable gap |
| Unnecessary escalation rate | Escalations your team could have avoided with better approved information | Widen the knowledge base for the specific questions involved |
| Missed escalation rate | Calls that should have escalated and did not | The most important and least visible number. Sample real calls to find it |
| Failed transfer rate | Transfers that never connected to a person | Fix the destination or the backup before touching anything else |
| Handoff completeness | Share of escalations where the person had to ask the caller to repeat themselves | Fix what the handoff carries, not the trigger |
Only one of these is genuinely hard to measure, and it is the one that matters most. Missed escalations do not appear in a dashboard, because by definition the system thought it succeeded. The only reliable method is to read a sample of completed automated calls each week and ask whether any of them should have reached a person. Ten calls a week is enough to find a pattern.
Resist setting a target escalation percentage. A plumbing company with mostly emergency calls and a dental practice with mostly scheduling calls should look nothing alike, and any single benchmark would be wrong for one of them. Use your own first month as the baseline and treat movement against it as the signal. Any threshold you adopt from an article, including this one, is a planning heuristic rather than a validated benchmark.
How Telvana handles transfers and escalation
Telvana's current feature set lists smart call routing that routes calls to the right person or department based on caller intent, described as "warm transfers with full context so nothing gets lost," along with call recording and transcription, CRM and calendar sync, and post call SMS notifications summarizing what happened and any follow up needed.
The Telvana FAQ is explicit about the escalation paths. Transfers can be configured to any phone number, including a mobile, a front desk, or a specific team member, based on rules you set. When the system encounters something outside its knowledge base, it "can transfer the caller to a human, take a detailed message, or offer a callback," depending on the workflow you configure. Greeting, knowledge base, call flows and escalation rules are all customer configurable.
Those capabilities are the mechanism. The triggers, the human only call types, the fallback ladder and the promise your team can keep are still yours to define. That work is the difference between a receptionist that protects your calls and one that merely answers them.
Frequently asked questions
Should an AI receptionist transfer a call the moment someone asks for a human?
Yes. An explicit request for a person is the strongest signal on the call, and adding qualifying questions after it is the fastest way to lose the caller. Announce the transfer, name the destination if you have one, and connect. If nobody is available, move straight to the fallback ladder rather than back into automated questions.
What should the AI say when it cannot answer a question?
It should say plainly that it does not have that answer, then run the configured path: transfer, capture a message, or offer a callback. It should not guess, and it should not fill the gap with a general statement that sounds close enough. A clear limitation followed by a real next step keeps trust. An invented answer destroys it.
How many calls should an AI receptionist escalate?
There is no correct percentage, and any number quoted without your call mix is guesswork. A business with mostly emergency calls will escalate far more than one with mostly scheduling calls. Measure your own first month, then watch the direction of travel and the reason mix rather than chasing a target.
What happens to the call if the transfer fails?
That depends entirely on the fallback ladder you configured, which is why it needs to exist before launch. A complete ladder attempts a named backup, tells the caller the truth about availability, captures a full message including the escalation reason, confirms the callback detail, and notifies the responsible person through a channel they actually watch.
Can escalation rules be different after hours?
They should be. The same trigger can have a different destination, a different backup, and a different promise depending on the time of day. Write the after hours version explicitly instead of letting it inherit business hours behavior, and test it at the hour it will actually run.
Does an AI receptionist replace the need for someone to answer the phone?
No. It changes which calls reach a person and what those calls arrive with. Routine questions, intake and approved bookings can complete without interrupting anyone, while judgment calls, commitments and urgent requests still route to people. Comparing the coverage models in AI receptionists versus traditional answering services is a useful next step if you are still choosing between approaches.
Decide the handoff before you forward your first call
Escalation rules are not a safety net bolted on after launch. They are the part of the design that decides whether callers trust the experience, and they are worth writing down before a single call is forwarded. Start with the calls that must never be automated, give each remaining call type one of the four outcomes, define what the handoff carries, and build the ladder for the moment nobody picks up. If you have not routed your line yet, our guide to forwarding calls to an AI receptionist covers the telephony side.
Bring your three hardest call types and the point where you want a person involved, and book a Telvana demo to map them into triggers, destinations and fallback paths.
Sources
- NIST: AI Risk Management Framework
- NIST AI Risk Management Framework (AI RMF 1.0), full text
- OpenAI: Guardrails and human review
- OpenAI: Voice agents
- Microsoft Copilot Studio: Hand off to a live agent
- Telvana Features
- Telvana FAQ
Last updated: August 25, 2026. By the Telvana team.