The question every practice asks, and few vendors answer
When practices evaluate an AI phone system, the first real question is almost never about voice quality or pricing. It's some version of: what happens when it can't handle something?
It's the right question. A system that transfers too readily is an expensive call router — your front desk still picks up, just with an extra fifteen seconds of delay first. A system that transfers too rarely traps callers in loops, and the caller who eventually hangs up in frustration is worse off than if nobody had answered at all.
The difference between those two outcomes is transfer logic, and it's rarely discussed in marketing material.
The four cases where transfer should be immediate
1. Dental emergencies
Severe pain, facial swelling, trauma, bleeding that won't stop, a knocked-out tooth. These are clinical situations where a delay has consequences, and where the caller is frightened.
An AI should recognize the emergency, say something reassuring, and connect the caller to a human immediately. It should not attempt triage. It should not try to book them for Thursday.
Worth being specific with a vendor: ask what their system does with "my face is swollen and I can't open my mouth." The answer tells you whether emergency handling was designed or assumed.
2. The caller asks for a person
If someone says "can I talk to a real person," the answer is yes, immediately, without friction and without a counter-offer.
Some systems are built to deflect this — offering to help one more time, or asking what the issue is first. That's a design decision that prioritises containment metrics over the caller. For a dental practice, where the caller may be a long-standing patient, it's the wrong trade.
3. Repeated failure on the same request
If the AI has tried three times to complete something and hasn't, it should stop and hand over. Not apologise and try again. Not restate the question differently.
Three is roughly the right threshold. Two can be premature — genuine misunderstandings resolve on a second attempt often enough. Four or more and the caller is already annoyed.
4. Requests outside its configured scope
If a caller asks about a service the practice doesn't offer, or one the AI wasn't set up to discuss, it shouldn't guess. The honest options are to offer a consultation booking or transfer to the team, and either is fine — as long as it doesn't invent an answer.
This is the failure mode that damages practices most quietly. An AI that confidently quotes a price for a procedure you don't perform creates a problem your front desk has to unwind later.
Where transfer is the wrong answer
Just as important, and less discussed.
Ordinary confusion. A caller mumbles, the AI mishears, it asks them to repeat. That's a normal conversation, not a failure. Transferring here means your front desk handles every call with a bad connection.
One unsuccessful attempt. If the first booking attempt doesn't land, try again. Immediate escalation on a single miss makes the system useless for its main purpose.
Questions that are unusual but answerable. Parking, wheelchair access, whether you validate parking, what to bring to a first visit. These are unusual only in that they're infrequent. A well-configured system handles them from the practice's own information.
Anything the practice explicitly configured it to handle. Some systems escalate on keywords regardless of configuration, which means the practice's own setup gets overridden by a vendor's default caution.
The failure that's harder to see
Most discussion of AI phone systems focuses on whether the AI can complete a task. The subtler question is what happens at the boundary.
A system that transfers 40% of calls isn't obviously broken — the calls get answered, patients get helped, nobody complains. But the practice is paying for AI coverage and receiving a slightly slower version of what they had before.
A system that transfers 2% of calls also isn't obviously broken. Until you listen to a recording of a patient asking four times to speak to someone.
Neither shows up on a dashboard as a problem. Both are worth measuring directly: ask your vendor what percentage of calls get transferred, and ask to see a sample of transfers and non-transfers. If they can't produce that, they aren't measuring it either.
What should happen during the transfer itself
The mechanics matter as much as the decision.
The caller should know it's happening. Silence during a transfer feels like a dropped call. A brief "let me get you to someone who can help with that" costs nothing.
It should be a warm transfer where possible — the call connects to your front desk line while the caller stays on. Not a callback promise. Not a message taken. The caller who wanted a person should get a person on the same call.
There should be a fallback. If your front desk line is busy or nobody picks up, what happens? A well-designed system has an answer — voicemail with a logged summary, an emergency line, a callback commitment with a specific window. A poorly designed one drops the call.
The practice should get context. Whoever picks up shouldn't start from zero. A short summary of what the caller wanted, before they say hello again, saves the caller repeating themselves and saves your team time.
Four questions to ask a vendor
"What are your exact transfer triggers?"
A good answer is a short, specific list. A vague answer — "our AI knows when to escalate" — means either the logic doesn't exist or the vendor doesn't know it.
"What's your average transfer rate across dental clients?"
Any number is fine as long as they have one. No number means no measurement.
"Can I change the triggers for my practice?"
Some practices want everything clinical routed to staff. Others want the AI handling more. Configurability matters, and a system with fixed triggers will fight your preferences.
"What happens if my front desk doesn't answer the transfer?"
The answer reveals how carefully the edge cases were thought through.
The underlying principle
An AI receptionist isn't trying to replace your front desk. It's trying to make sure nobody reaches a dead end.
Judged that way, the goal isn't the highest possible containment rate. It's that every caller ends the call having either got what they wanted or reached a person who can help. Transfer logic is just the mechanism for deciding which of those applies.
Any vendor optimising for containment above that is optimising for their metrics, not your patients.
How Aria handles it
Aria transfers on four triggers: dental emergency, explicit request for a person, three consecutive failed attempts on the same task, and any service outside its configured scope. It doesn't transfer on ordinary confusion or a single failed attempt — those are handled in-conversation.
Practices configure the triggers during setup. If you want every clinical question routed to your team, that's a setting, not a limitation.
See how it works · Try the demo line
Hear Aria handle a real call.
Call the live demo line — no signup. Try asking something unusual, or ask to speak to a person, and see exactly what happens.
Try the Demo →