Booking rate is the wrong number to buy an AI receptionist on. For a plumber or a roofer, the call that pays for the month is the one the agent has to refuse to book and get to a human inside ninety seconds.
Almost every AI answering service says it can transfer an emergency call to a person. Almost none publish what happens when that person does not pick up. And on the leg that dials your on call technician, the phone network usually cannot tell a human from a voicemail box until after it has connected the two. That is the risk you are buying, and no comparison table shows it.
Voicemail wins the race, and it hangs up on everybody else.
The mistake: you demo the booking, never the handoff
Every demo I have sat through runs the same way. Somebody asks the agent for a Tuesday morning slot, it books it, the room nods. Nobody calls at eleven at night to say the basement is filling with water.
An appointment business can be graded on booking rate. The trades cannot, because their phone carries two populations: scheduling calls worth a normal ticket each, and emergencies worth the biggest ticket of the week, which the agent should qualify, price the after hours fee on, and hand to a human. So interrogate the transfer, because the transfer fails in a way that looks like a success.
It booked the appointment, and it sounded human doing it.
Grades the agent on the half of your call volume that was never the expensive half.
Now call it at 11pm, refuse to be booked, and switch the on call phone off.
Grades the handoff. Most vendors cannot run this one, and that is the answer.
The failure that reads as a success
To hand a live caller to your on call technician, the agent dials a second leg and bridges the two calls. Everything rests on whether a person answered that leg or a voicemail greeting did. Twilio, which sits under much of this market, is unusually straight about it.
Answering machine detection can be enabled on a transfer leg. Twilio's own FAQ then says that on the Participants API and on <Dial><Number> or <Dial><Sip> it is "asynchronous by default and cannot be configured to behave otherwise". Asynchronous, in Twilio's definition on that page, means the callee is "connected immediately" while detection runs in the background, and the average verdict lands about four seconds after the call was answered. Your customer is already listening to the greeting by then.
Two further details make this worse. The default value of machineDetection on <Number> is none, so in most builds nobody switched the check on and there is no verdict at all. And the one mode Twilio will quantify, DetectMessageEnd, is "close to 100% accurate in US destinations with default settings" precisely because it waits for the greeting to finish playing: the accurate mode is the one you cannot use on a caller who is holding. For the mode you would need, Twilio says only that accuracy "is more relative".
Twilio's Connect Call documentation puts it plainly, on ringing several people at once: "The first contact to pick up the phone (even through answering machine) will be the official recipient of the call while the others will have their calls canceled."
What the platforms publish about the handoff
Read the transfer documentation, not the integrations page.
Retell has clearly thought about it. Its warm transfer carries an Enable human detection setting, documents that the caller "will only be connected once a human is detected", and offers an Action on Timeout choice between cancelling the transfer and bridging the caller anyway. It also publishes a failure I would not have predicted: a real person can fail the check because their "speech was too similar to an IVR or voicemail".
Vapi ships the protection, but not by default. Blind transfer is what you get when transferPlan is omitted, and Vapi says it "does not confirm that the downstream telephony provider completed it". The fallback for a destination that is "unreachable or not human" lives in the mode Vapi still labels experimental.
Bland puts it behind the price list: "Warm Transfer requires an enterprise account." ElevenLabs Agents publishes a transfer tool with no timeout, no ring duration and no no-answer behaviour at all. GoHighLevel's entire published definition is one sentence, "Call Transfer sends the caller to a person or external number", and it adds that call transfer is not supported during web call testing, so the thing most likely to break cannot be rehearsed in a browser.
The trades vendors, and who has it backwards
Jobber publishes a real escalation policy: trigger terms you configure, its own examples being "emergency", "speak to a manager" and "urgent", and two outcomes, a text or a live transfer to one contact. Across both Receptionist help articles, the feature page and the release notes, it never says what happens if that contact does not answer. Its advice is to design the problem out: remove the speak to someone option "after hours when no one is available to take the transfer".
Housecall Pro is the only one that will not let you switch emergency handling off: "Emergency handling is always on, so this only changes how you're notified, not whether." It also contradicts itself on disclosure: the marketing page says telling callers they are speaking to AI is "up to you", the help centre says "the disclosure is a required feature and cannot be turned off". Believe the help centre.
ServiceTitan documented its own failure out loud. A release note describes the previous state plainly: the Voice Agent "could only forward escalated calls to a single phone number", and then "no one answers, and the call goes to voicemail". Multi point escalation fixes it, and Support has to switch it on. Price this line in too: "All calls, regardless of their outcome or the caller's intent, are included in your bill."
Then the pattern worth a slide. Sameday has the best emergency copy of anyone, promising that true emergencies page your on call technician, and says nothing about what happens if that technician is asleep. Goodcall publishes the most detailed no answer branch I found anywhere and never calls any of it emergency handling. Rosie sells the waterfall, trying numbers until someone answers, on its top tier only.
Four moves before your next after hours shift
This needs one page of paper and one late evening.
Write the escalation path down before the demo
One number or several, in what order, ringing how long each, and what the caller hears when all of them fail. Take that page into every sales call. Ask the vendor to fill it in on the screen. If nobody can, you have your ranking, and our notes on AI calling for home services cover how we wire the rest of it.
Make the technician accept the call
Twilio’s <Number> verb takes a url that runs "on the called party’s end, after they answer, but before the parties are connected", and it supports <Gather>, so you can require a keypress. A voicemail box cannot press a key. Two constraints Twilio publishes: <Dial> is not allowed inside that document, so the next number has to ring from the parent call, and you need answerOnBridge or your caller hears silence instead of ringing.
Run the three call test at 11pm, from a number the vendor has never seen
Once with the technician answering. Once with the technician declining. Once with the phone switched off entirely. The third call is the only one that tells you anything, and it is the one nobody runs before signing.
Ask the two billing questions in writing
How is a wrong number billed, and is the transfer leg metered separately from the conversation. ServiceTitan answers the first one on its own help centre and the answer is that everything is billable, test calls included.
The bottom line
Buy on the handoff. A vendor that publishes a ring duration, a second destination and a terminal fallback has thought about your worst night. One that leads with booking rate has thought about your easiest. I build this for home service companies, and the booking half is close to a commodity now. The handoff is still bespoke, still untested by most of the people selling it, and still the only part of the call your customer will remember.