The phrase covers three different products. A voicemail transcriber with a friendly greeting. A hosted answering service staffed by people. And an agent that can look at your schedule and create a booking. They are priced on different axes, so a straight comparison of monthly figures tells you almost nothing.
The Three Cost Structures
A human answering service prices per minute or per call. Quality is generally good and the cost scales linearly with volume, which is fine until volume grows. They take messages competently and book appointments poorly, because they are working from outside your systems.
A packaged AI voice product prices per month with a usage component. Setup is fast. What you are buying is a voice on top of a script, and the ceiling is what the vendor's integrations allow. If your booking rules are unusual, the product will not learn them.
A built agent has a build cost and then a running cost made of model usage, telephony, and hosting. It is the most expensive to start and the cheapest per interaction at volume, and it is the only one of the three that can be made to follow your actual rules.
What Drives the Build
- Voice or text. Voice adds speech recognition, latency budgets, interruption handling, and the difficulty of getting names and addresses right over a phone line. Text is far cheaper and often enough.:
- How many actions it can take. Reading availability is one integration. Booking, rescheduling, cancelling, and taking payment are four, each with its own failure handling.:
- Whether it needs to identify the caller. Looking someone up and speaking about their history is a different security posture than answering general questions.:
- How many ways a conversation can go. Scripted paths are cheap; open-ended handling of anything a customer might say is not.:
- Escalation. A clean handover with the conversation attached is real engineering, and it is the part that stops a bad interaction becoming a lost customer.:
The Running Cost People Miss
Model usage is usually the smallest line. Telephony minutes, transcription, and hosting are steadier. The cost that surprises people is maintenance: your services change, your hours change, your rules change, and an agent that is not updated starts giving answers that were true last quarter.
There is also evaluation. Knowing whether the thing is doing its job requires reviewing transcripts against outcomes, at least periodically. An agent nobody checks is an agent nobody can vouch for.
The interesting number is not what it costs per month. It is what one confidently wrong answer costs, multiplied by how often it happens.
The Cost of Getting It Wrong
An agent that quotes a price you do not offer has created a dispute with a customer holding a transcript. One that books a Saturday you do not work has created a wasted trip. One that mishandles a genuine emergency because it did not recognize urgency has created something worse than a bad review.
These are avoidable, and avoiding them is where the build cost goes: narrow scope, grounding in real data, an explicit instruction to escalate rather than guess, and logs that let you find out what happened. A cheap deployment skips all four, which is what makes it cheap. The distinction between something that can act and something that only talks is covered in more detail in the comparison of agents and chatbot widgets.
How to Decide
- Low call volume, simple messages: an answering service is cheaper than anything you would build, and better.
- High volume of repetitive questions with nothing to transact: a packaged product or a text assistant is the right size.
- Inquiries worth real money arriving out of hours: an agent that can genuinely book pays for itself quickly, because the comparison is against the bookings you currently lose overnight.
- No system of record yet: build that first. An agent with nothing to read from cannot do the job that justifies it.
- Safety-critical or regulated: use it to route to a person fast and keep it away from the answer.
The honest finding, more often than vendors admit, is that the constraint is not the agent. It is that there is no live source of availability for it to read, and no customer record for it to write to. That is a systems project, and doing it first is what makes the agent worth having.