Voice agents vs chatbots: an architecture decision, not a feature list

Most teams treat "chatbot or voice agent" as a vendor question. It is really a plumbing question: one system moves text, the other moves audio in real time, and almost every difference in cost, latency and failure mode falls out of that single fact.

This is a build-side comparison for people who have to wire the thing up, not a feature list.

Two different pipes, not two features

A website chatbot is a short loop: user types, model answers, answer renders. You can drop it into a page with a script tag, and if the model takes two seconds nobody notices.

A voice agent is a chain of four hops that must finish inside a conversational pause:

1. speech-to-text turns the caller's sentence into words,
2. the model decides what to say,
3. text-to-speech renders it back into audio,
4. the telephony leg carries it to the handset.

Each hop adds delay, and delay is audible. A caller hears a slow response as hesitation, then starts talking over the agent, which produces a worse transcript and a worse reply. This is why voice work feels harder than chat work even when the model is identical.

Where the money actually goes

Chat pricing is a subscription: you pick a plan and the bill is roughly flat, with entry tiers in the low tens of dollars and paid plans reaching into the low hundreds per month.

Voice pricing is metered. Speech-to-text, text-to-speech and the phone line are all billed per minute, which lands somewhere around five to fifteen cents per minute depending on the stack. The uncomfortable consequence: the better the agent performs, the more minutes it consumes. A pilot that looks cheap because it only handles a few calls becomes a real line item the month it starts working.

Two ways to keep that predictable:

• Route by intent, not by channel. Let text handle everything that can be text, and keep the phone line for calls that genuinely need a human voice.
• Own the stack when volume justifies it. Self-hosting STT, model and TTS on a VPS replaces per-minute fees with a fixed server cost — but you inherit patching, security and uptime.

If you self-host, two details decide whether it works: put the server in a region near your callers (latency on a live call is far more noticeable than latency on a page load), and make sure snapshots and backups are included, because you will break the audio pipeline at least once while tuning it.

The plumbing nobody budgets for

Chat needs a widget and a knowledge base. Voice needs a phone number, a SIP or VoIP trunk, call routing rules, a recording policy and a way to replay calls when something goes wrong. That is not exotic, but it is a second system with its own failure modes — busy lines, codec negotiation, dropped transfers.

Practical order that saves rework: choose the telephony layer first, write the call flow second, and only then pick the voice stack. Teams that start with the model usually discover mid-project that their phone provider cannot do the warm transfer they designed around.

Escalation is the product, not the fallback

An automation that cannot hand off cleanly is worse than no automation, because it traps the caller. Design the handoff before the happy path:

• Write down what the agent may not answer — pricing promises, medical or legal advice, delivery dates it cannot verify — and script what it says instead.
• Make the transfer warm: pass a short summary and the caller's intent to the human, so the customer does not repeat everything.
• Keep a callback path for anything that cannot be transferred right now.

For a clinic this means booking by voice and reminders by text. For a repair service it means capturing the address by voice and confirming it back before dispatching. For a retailer with a busy site it usually means text first, with a human queue behind it.

Keep one conversation store

Chat and voice are two front doors into the same customer history. Log both into the same place — transcript, intent, outcome, whether a human took over — and review a sample of real conversations every week. Gaps appear in transcripts long before they show up as complaints or churn.

If the two channels write to separate tools, you will end up reconciling them by hand and you will stop reviewing anything.

Metrics that survive a vendor dashboard

Three numbers are enough to start, and all of them should be measured from your own transcripts rather than the vendor's summary:

• share of conversations resolved without a handoff,
• how often callers ask for a person,
• how many handoffs end with the caller hanging up.

Watch them per channel. A voice agent with a high handoff rate is usually a script problem, not a model problem — the agent simply lacks an answer it is allowed to give.

Decision table

Two rules hold across every row: decide the refusal list before launch, and review transcripts weekly.

A layered default that works

The configuration that survives contact with real traffic is boring: an agent answers first, resolves the routine questions, and hands the rest to a person with context attached. Chat covers the site and messaging apps, voice covers the phone, both write to one store. Measure the three numbers weekly and change one thing at a time.

FAQ

Does a voice agent replace a chatbot?
No. They cover different channels. Voice handles callers who pick up the phone; chat handles people already on your site or in a messaging app. Most businesses end up running both, with one shared history.

Which is cheaper to start?
Text. A chatbot needs a widget and content, while voice needs telephony before the model can answer anything, and the per-minute billing starts on day one.

How much can automation resolve on its own?
For routine questions — hours, prices, order status, bookings — a well-scoped agent handles the large majority and escalates the rest. Complex or high-stakes conversations still need a person.

How long does a pilot take?
For a narrow scope, a few weeks: one to write and test the script, one to connect the phone line and logging, one to run beside a human before going live. Delay usually comes from business rules, not the model.

What should we watch in the first month?
Containment, human requests, and abandoned handoffs — reviewed from transcripts, weekly, per channel.