A voice agent for the calls nobody is answering

What this actually solves

The businesses that buy this share a specific shape of problem. A dental practice or a clinic has one person on reception who can hold one call at a time, and every other caller is queuing or has already gone elsewhere. You already know what one appointment is worth to you, which makes the case for answering the fourth simultaneous call fairly easy to work out. A dealership or a service centre has the same problem pointed outwards — speed of callback is the thing they compete on, and an agent can make that call at eleven at night when no one is on the floor.

What makes this its own discipline is not the conversation. It is the timing. Natural silence between turns in human speech sits somewhere around half a second. Push the gap out towards a second and a half and people start talking over the agent, repeating themselves, and hanging up — not because the answers were wrong, but because it stopped feeling like a conversation. Every technical decision in this build serves that budget, including the decision to use smaller and faster models even where a larger one would be a little more capable.

How the build runs

1. Design the call flow from your actual calls. What genuinely comes in, in what proportion — new bookings, changes, urgent problems, price questions, insurance questions, wrong numbers. Each route mapped to what the agent says, what it must collect, and where it goes next. Four to six days.
2. Set up telephony and numbers. The line, the routing, the transfer path to your team, and recording with the notices that requires. Two to four days.
3. Choose and tune the transcription. Tested against recordings of your real callers rather than clean sample audio, because accent and line quality are the largest single source of failure in a live voice system. Four to six days.
4. Write the prompt for the phone, not for chat. Answers capped at a sentence or two, one question at a time, numbers and times spoken the way people say them out loud rather than the way they are written, and the exact wording for every transfer trigger. Four to six days.
5. Choose the voice, set the pacing, then work the latency leg by leg. The total delay is three separate delays — speech to text, the model's reply, and text to speech — and each is measured and reduced on its own. Optimising one and leaving the other two on defaults gets you nowhere near the target. Interruption handling is built here too, so a caller who starts speaking stops the agent instead of talking over it. One to two weeks.
6. Test on fifty real calls, then go live with recordings kept. Real conversations, of the kinds your flow says you get, including the confused caller who changes their mind three times and the one with an urgent problem. Every call recorded and transcribed, because the first month of real calls teaches you more than the whole build did. One week.

Typical tooling — Vapi, Retell or Bland where a managed voice framework fits, LiveKit where full control over the audio path is needed, Twilio or Vonage for numbers, Deepgram or AssemblyAI for transcription, ElevenLabs or Cartesia for the voice, and your own booking system or Cal.com for appointments.

What changes the quote

How many distinct call flows it has to handle. A practice that only books and reschedules sits at the bottom of the range. One that also triages urgency, answers insurance questions and handles payment queries is several flows, each needing its own testing.

Inbound, outbound, or both. Outbound is consistently the harder build. The opening seconds have to earn attention that an inbound caller brings with them, and there are calling rules to work within that do not apply to answering your own phone.

What it connects to. An agent that only takes messages is quick. One that holds real appointments in your diary, checks whether someone is an existing patient or customer, and writes back to your CRM is doing live work in your systems, with all the failure handling that implies.

Where these go wrong

The chat prompt is reused for the phone. It is the fastest way to build one and it fails immediately. The agent delivers three sentences of well-structured explanation, the caller interrupts halfway through, and the call ends badly. Phone language is short answers, one question at a time, and silence afterwards. It cannot be reasoned out on paper — it comes from listening to your own agent handle twenty calls and hearing where it talks too much.

Interruption is not handled. A caller who starts speaking while the agent is talking is completely normal human behaviour, and a system that ploughs on regardless, or restarts its sentence from the beginning, sounds broken within two exchanges. Barge-in handling is built in from the start rather than added when someone complains, because retrofitting it usually means changing the audio pipeline.

Latency is treated as one number. The model gets optimised because that is the interesting part, while transcription and speech generation stay on whatever the defaults were — and the total stays past the point where the conversation feels wrong. Each of the three legs has its own budget and its own measurement, and the one you did not look at is usually the one costing you the most.