What an AI receptionist should do when it cannot answer
The failure path is the design, not an edge case. A caller who hits the limit of what the system can do decides whether the whole thing was worth building.
The short answer
- An AI receptionist is judged by what happens when it cannot handle a call, not by how well it handles the easy ones. Every deployment eventually meets a question it was not built to answer.
- A caller who is led to think they reached a person, then finds out otherwise mid-call, loses more trust than a caller who was told upfront and knew what to expect.
- A working transfer to a human during business hours, and a real fallback after hours (at minimum a voicemail someone reviews), separate a usable system from a caller left with nothing.
- In SalesCrew, outbound calls through Vapi log against the contact, inbound calls route by business hours with voicemail transcription, and the AI receptionist books and transfers from the same records.
Why the hard part is not the easy calls
Most demos of an AI phone system show the calls it is good at. A caller asks for business hours, the system answers correctly, and the caller hangs up satisfied. That case is easy to build well. It is also a poor predictor of whether the system holds up in production. The calls that matter are the ones it was not built to handle: an unusual question, an angry caller, a request the system cannot fulfill. Every deployment meets that call eventually. What happens next is the real design problem.
There are three broad outcomes when an automated phone system hits its limit. It can pretend to understand and give a wrong or evasive answer, which damages trust the moment the caller notices. It can transfer cleanly to a person who can help. Or it can fail silently: a dropped call, a dead end, or a voicemail nobody checks. That is the worst outcome, because the business does not even know the call was lost.
Disclosure, transfer, and the after-hours gap
The first design decision is whether the system tells a caller upfront that they are talking to an automated system. Not disclosing it can make the good calls feel more natural. It sets up a worse moment for the bad ones. A caller who realizes partway through that they were not talking to a person feels misled, and that costs more trust than knowing from the start. There is no universally right answer. Businesses reasonably differ on this trade-off. What gets skipped is treating it as a real decision, rather than defaulting to whichever setting sounds more impressive in a demo.
The second is the transfer path. A system that recognizes when a caller needs a human, and routes them there immediately during business hours, turns a hard call into a solved one. A system with no transfer path, or an unreliable one, turns every hard call into a lost caller, however good it sounds on the easy ones.
The third is what happens outside business hours. For most small and mid-size businesses, that is when a meaningful share of inbound calls arrive. A system with no after-hours fallback either rings out or drops the call. The minimum viable fallback is a voicemail that gets transcribed and reaches someone who will read it the next business day. Not a voicemail that sits in a mailbox nobody checks until the caller has already called a competitor.
What this means for evaluating any inbound AI phone product
When evaluating a vendor's AI receptionist claim, the useful questions are about the failure path, not the demo path. What happens when the system does not understand the caller? Is there a real transfer to a person, and does it work reliably during business hours? What happens after hours or on a missed call: does a voicemail get transcribed and routed to someone who will act on it, or does it disappear into a mailbox? A vendor that can answer those three questions concretely has built the hard part. A vendor that only demonstrates the easy calls has shown only the part that was easy to build.
SalesCrew runs outbound calls through Vapi, logged against the contact and deal they belong to. Inbound calls route by business hours, a whisper message briefs the person before a transfer, and voicemails are transcribed into the same thread list as email. The SalesCrew AI receptionist is built to the same three questions above: it books from a real calendar, transfers to a person in business hours, and leaves a transcribed voicemail after hours.
Questions
- Should an AI receptionist ever try to sound fully human?
- That is a design choice with a real trade-off, not a settled best practice. Disclosing upfront that an automated system is handling the call costs a little trust with callers who wanted a person. It avoids the larger trust cost of a caller feeling misled once they realize partway through.
- What is the minimum an AI phone system needs before it goes live?
- A defined boundary for what it can do (answer FAQs, book from a real calendar, take a message), a working transfer to a human during business hours, and a fallback for after-hours or no-answer that does not silently drop the caller. At minimum, a voicemail with a transcription a person will actually see.
- Where do calls land in SalesCrew?
- On the contact and deal they belong to. Outbound calls run through Vapi, the disposition is recorded, and the follow-up becomes a cadence step. Inbound calls route by business hours, voicemails are transcribed into the same thread list, and the AI receptionist books and transfers from the same records.