The calls an AI shouldn't handle

What to do about the calls an AI shouldn’t handle is not a question of whether AI is useful. It is a question of boundaries. A phone agent can answer routine questions, collect job details, check availability, and book ordinary appointments. It should not guess its way through emergencies, legal disputes, vulnerable-caller situations, or decisions that carry real safety or financial consequences.

The goal is not perfect call containment. The goal is a reliable system that knows when to stop. A caller with a leaking water heater at 2 AM, a patient describing urgent symptoms, or a customer disputing a large invoice should not be treated like a standard scheduling request. In those moments, the AI needs a clear next action, a human destination, and a fallback if nobody is available.

Table Of Contents

1. Key Takeaways
2. Build A Do-Not-Handle Policy
3. Use A Routing Decision Tree
4. Make Human Handoffs Useful
5. Plan For Failures And Review Exceptions
6. Frequently Asked Questions

Key Takeaways

Set Boundaries Before You Measure Automation

We should judge an AI phone system by the quality of the calls it resolves and the quality of the calls it declines to resolve. A high containment rate can look good on a dashboard while hiding callers who were delayed, misunderstood, or sent to the wrong queue.

A sound policy separates routine transactions from cases that need judgment, authority, empathy, or specialist knowledge. For a home-service company, booking a seasonal tune-up may be appropriate for AI. Deciding whether a caller’s report of a gas smell is safe to wait on is not.

Treat Escalation As A Designed Outcome

An escalation trigger is not a vague instruction to transfer callers who sound upset. It is a rule that links a call condition to a specific action. That action may be an immediate human handoff, a safe refusal with emergency instructions, or a structured callback request.

The useful question is not, “Can the AI answer this?” It is, “What is the cost if the AI is wrong?”

Protect Caller Trust During Exceptions

A caller should never have to diagnose the system’s limits. If the request is outside scope, the AI should state what it can do next in plain language. It should not make the caller repeat the same issue three times, promise a transfer that cannot happen, or present an uncertain answer as a fact.

The same principle applies to routine leads. Understanding the impact of missed calls helps explain why businesses automate coverage, but keeping every caller on automation is not the answer. The right boundary protects both revenue and service quality.

Build A Do-Not-Handle Policy

Classify Calls By Risk, Not Just Sentiment

A caller can sound calm while describing a dangerous situation. Another caller may sound angry because they have already called twice about a billing error. Sentiment matters, but it is not enough to define the automation boundary.

We recommend creating a written do-not-handle policy by call class. Each class should define what the AI may collect, what it must not decide, where the call goes, and what happens after hours.

This policy is more useful than a generic “transfer when unsure” instruction because it establishes exclusions before a call reaches an uncertain moment. It also keeps teams from gradually expanding AI authority without deciding whether that expansion is safe.

Distinguish Handoff, Deflection, And Refusal

Not every call the AI should not handle belongs in the same queue. We can separate three actions.

1. Handoff means connecting the caller to a live person or specialist queue. Use it when a human can take action now, such as a dispatcher handling an active water leak or a billing team reviewing a disputed charge.

2. Deflection means collecting details and setting a defined next step, usually a callback, because a qualified person is unavailable. Use it after hours when the issue is important but not an immediate emergency.

3. Refusal means declining to perform an action the AI is not authorized to take. The AI may explain the limit and provide an approved alternative. For example, it should not give legal advice, change ownership details without authentication, or decide whether a medical symptom is harmless.

These distinctions matter. A transfer that goes nowhere is worse than an honest callback plan. A refusal without a next step can feel like abandonment. The system needs to choose the least disruptive safe action.

Define What “Urgent” Means In Your Trade

Urgency is local. A no-cooling call may be routine in mild weather but urgent if a household has an infant, an elderly resident, or dangerous heat conditions. A broken lock may need immediate attention. A cosmetic roofing concern likely does not. We should not ask a general-purpose model to infer these distinctions without specific business rules.

Create an urgency matrix with operations, field leaders, and whoever owns on-call coverage. Include service area, time of day, weather, customer type, available crews, and the exact language callers may use. Then keep the AI’s role narrow: identify approved signals, collect facts, and follow the route.

This is part of the limitations of AI receptionists: an AI can be consistent with rules, but it cannot be allowed to invent the rules while someone is waiting for help.

Use A Routing Decision Tree

Put Safety And Compliance First

The decision tree should follow risk order, not convenience. A simple operational sequence is:

1. Check for immediate safety language or an active emergency.
2. Check for compliance-sensitive, legal, medical, payment, or identity-related restrictions.
3. Check for vulnerability, distress, or an explicit request for a person.
4. Check whether the intent is within approved AI scope.
5. Check whether the AI has successfully understood and completed the task.
6. Route, collect-and-flag, or continue with automation.

LiveKit’s handoff guidance identifies compliance-sensitive workflows, emotionally charged conversations, and high-stakes decisions as appropriate reasons to involve a human. That is a practical starting point, but each business still needs its own operational definitions.

For example, a plumbing caller saying, “There is water everywhere, and the electrical panel is nearby,” should trigger the emergency path even if the caller does not sound distressed. The AI can ask for the address, determine whether the caller is safe, give approved instructions, and connect the on-call process. It should not troubleshoot wiring or assure the caller that the situation is safe.

Make Failure Thresholds Measurable

“Low confidence” is useful but incomplete. Confidence scores can be difficult for nontechnical teams to audit, and a model can be confident about the wrong intent. Add observable failure rules alongside any score threshold.

Fini’s guidance on voice-agent escalation includes low confidence, negative sentiment, explicit requests, refund thresholds, legal topics, and vulnerable callers as triggers. We should turn those broad categories into thresholds that a dispatcher or office manager can inspect.

A practical two-strike rule is often easier to manage than an abstract confidence number: if the AI fails to resolve the same intent twice, it stops trying on the third attempt. This does not mean every clarification needs a transfer. It means the system must recognize a stalled conversation before frustration becomes a hang-up.

Use Skills-Based Routing, Not The Next Open Line

The correct human is part of the resolution. Routing an invoice dispute to an on-call technician may meet a transfer metric but not solve the caller’s problem. Send safety matters to the dispatcher or on-call lead, contractual questions to an authorized manager, and complex estimates to sales or operations.

Sameday’s call-handoff protocol guidance recommends mapping escalation triggers to defined destinations, such as a dispatcher, senior customer-service representative, salesperson, or owner, and passing the call summary, caller details, and reason for escalation.

A specialist route does require coverage planning. If the billing team only works weekday hours, the after-hours route should not pretend a live billing transfer is available. It may collect the dispute amount, invoice number, preferred callback time, and any payment deadline, then create a priority case for the next business day.

Make Human Handoffs Useful

Send The Right Context Before Pickup

A human handoff fails when the caller hears, “Can you tell me what happened?” after explaining it for five minutes. The transfer should carry a usable record, not only a transcript that the next person must scan while the caller waits.

Intercom’s AI-to-human phone workflow recommends sending the full transcript, identified intent, authentication status, actions already taken, and reason for escalation, while routing by issue type and using a warm transfer message.

We can scale the handoff payload to the risk level.

The AI should not claim that a human has all the details unless the context transfer has actually succeeded. Under the hood, that usually means a session summary and structured fields are pushed to the CRM, dispatch platform, or agent console before the connection completes.

Next Level AI’s explanation of real-time transfers describes passing conversation context through a warm briefing or CRM push so the receiving person can continue rather than restart the conversation.

Tell The Caller What Happens Next

A warm handoff is a short, honest bridge. It should name the next step, set expectations, and avoid false promises.

For an immediate transfer: “I’m connecting you with the on-call dispatcher now. I’ve shared your address and the details you gave me, so you should not need to repeat them.”

For an unavailable specialist: “Our billing team is unavailable right now. I can document the invoice number and your concern for priority follow-up tomorrow. If this involves suspected fraud or an urgent payment deadline, I can direct you to the approved support option.”

Avoid vague language such as “someone will get back to you soon.” Use a time window only if the business can meet it. Otherwise, state the next business period and provide a reference number or confirmation text where appropriate.

Do Not Treat A Hang-Up As A Resolved Call

A caller may hang up because they found the answer, but they may also hang up after a loop, a long pause, or an unclear transfer. The system should label the outcome as abandoned or disconnected unless it has evidence of completion.

Reviewing reasons for call hang-ups alongside transcripts can reveal whether callers leave after a repeated question, an unavailable transfer, or a confusing policy statement. That is more actionable than treating all abandoned calls as identical.

Plan For Failures And Review Exceptions

Design The 2 AM Fallback Before Launch

The hardest test is not a weekday booking. It is an excluded call at 2 AM when the specialist does not answer. The system needs a planned ladder, with time limits at each stage.

1. Attempt the designated on-call destination.
2. If unanswered, attempt the secondary contact or backup queue.
3. If no live person is available, provide approved urgent instructions where applicable.
4. Collect the minimum safe details and create a high-priority alert.
5. Confirm the callback or dispatch expectation only if it is operationally real.
6. Log the failed transfer and notify the coverage owner.

For a nonemergency dispute, the fallback may be a priority callback. For an active safety concern, the fallback may require emergency-service instructions rather than a promise that a technician will arrive. The exact wording should be reviewed by the business’s legal, safety, and operational stakeholders.

Keep An Audit Trail For Every Boundary Decision

Calls that the AI refuses, deflects, or transfers deserve more review than ordinary bookings. Preserve a timestamp, call identifier, policy version, reason code, route selected, whether the transfer connected, and the final disposition where available.

Reason codes should be simple enough to report on: EMERGENCY_SIGNAL, LEGAL_TOPIC, HUMAN_REQUEST, REPEATED_FAILURE, OUT_OF_SCOPE, or NO_SPECIALIST_AVAILABLE. The point is not surveillance. It is accountability. If a caller says they were denied help, the business should be able to see what triggered the system and what happened next.

Improve Boundaries Without Expanding Risk By Default

Review excluded calls on a regular schedule. Look for false positives, false negatives, failed routes, and new call types. Do not automatically automate every category that creates callbacks. Some categories create callbacks because they require a human.

A useful review asks four questions:

• Did the AI identify the risk correctly?

• Did it choose the correct behavior: handoff, deflection, or refusal?

• Did the destination have the authority and context to act?

• Did the caller receive a clear next step when the route failed?

If repeated inference failure is common for a particular issue, improve the intake wording or add a route. If a category creates legal or safety uncertainty, keep it excluded until the business has explicit policy and coverage. Restraint is often cheaper than recovering from one harmful promise.

Frequently Asked Questions

What Calls Should An AI Never Try To Handle?

An AI should not independently handle active emergencies, legal advice or liability disputes, medical triage, restricted financial decisions, identity-sensitive account changes, or situations involving vulnerable callers where a human is needed. It may collect limited information and follow approved safety language, but it should not make the final decision.

Should An AI Transfer Immediately When A Caller Asks For A Human?

Yes, when a person is available. If no one is available, the AI should state that clearly and offer the approved alternative, such as a priority callback or specialist voicemail. Do not require the caller to ask twice or continue forcing self-service.

How Do You Stop An AI From Looping On The Same Question?

Track repeated questions, repeated corrections, and unsuccessful attempts to identify intent. A two-strike policy is a practical option: after two failed attempts on the same issue, the AI transfers or collects information for human follow-up rather than trying again.

What Context Should Be Passed During A Human Handoff?

At minimum, pass the caller’s identity or authentication status, callback number, intent, summary, actions already taken, and escalation reason. High-risk calls also need timestamps, exact safety or compliance signals, transfer outcomes, and a preserved transcript or recording record when permitted.

What If No Human Agent Is Available Right Away?

Use a defined fallback path. Try backup coverage, then collect only the information needed for a callback or emergency response. Never claim a transfer succeeded when it did not. For immediate danger, provide approved emergency instructions rather than waiting indefinitely for an internal callback.

How Should We Handle Angry Or Vulnerable Callers?

Treat anger, distress, confusion, or vulnerability as possible escalation signals, not as a problem to argue with. Use plain language, avoid repeated questioning, and route to a trained person when available. The AI should not make assumptions about a caller’s condition; it should follow the business’s approved vulnerability policy.

How Do We Test Whether The Transfer Flow Works?

Test complete scenarios, including an answered transfer, an unanswered transfer, a wrong queue, a disconnected caller, and an after-hours emergency. Confirm that the receiving person sees the right context and that alerts, CRM records, and callback tasks are created as expected.

Is A High AI Containment Rate Always Good?

No. A high rate is only useful if contained calls are truly resolved and excluded calls reach the right human path. Track repeat calls, abandoned calls after failed attempts, transfer connection rates, missed urgent alerts, and customer complaints alongside containment.

Sources And References

• Intercom — Building an AI-Human Phone Support Workflow That Actually Works: https://www.intercom.com/learning-center/ai-human-phone-support-workflow

• Next Level AI — Real-Time AI Call Transfer: Warm Agent Handoff: https://nextlevel.ai/ai-call-transfers/

• LiveKit — The Handoff Pattern for Voice Agents That Replaces IVR: https://livekit.com/blog/handoff-pattern-voice-agents

• Fini — AI Voice Agents With Human Handoff for Customer Support: https://www.usefini.com/guides/ai-voice-agents-human-handoff-customer-support

• Sameday — AI to human call handoff protocols: https://www.gosameday.com/post/ai-to-human-call-handoff-protocols-create-seamless-transitions-in-customer-service