The licence is rarely the expensive part. Integration scope, intent count, language coverage and testing depth are what move the number — and each one is a decision you can make differently.
Ask a vendor what voice AI costs and you will get a per-minute or per-resolution rate. It is a real number and it is rarely the one that decides your budget.
What decides the budget is how much has to be built behind the conversation, and that is set by decisions you control.
Integration scope
A voice assistant that answers from a knowledge base is a content project. One that checks an order, books an appointment or processes a return is an integration project, and integration is where the cost sits.
Three things drive it. How many systems the assistant has to reach. What state those interfaces are in — a documented API is a different proposition from screen-scraping a green-screen terminal. And whether the assistant needs to write as well as read, because write access brings a permissions and audit conversation that read access does not.
The cheapest useful deployment reads from one system and writes to none. That is not a compromise; for a status enquiry it is the correct design.
Intent count
Every intent is design, build, test and maintenance. The cost is roughly linear in intent count, and the value is not: in most contact centres a small number of intents cover a large share of volume.
Start with the top few by volume, measure, then extend. A launch covering forty intents takes longer, costs more, and delays the point at which you learn whether any of it works.
Language and channel coverage
Adding a language is not a configuration toggle. It is conversation design, testing against real speakers, and ongoing maintenance every time the underlying policy changes. The same is true of each channel: voice and chat share intent logic but almost nothing else about the interaction.
Scope this to what you actually need rather than what you might one day want.
Testing depth
The temptation is to test the paths you designed. The cost of not testing the others arrives later, in production, in front of customers.
Budget for testing against held-back real interactions, for accents and audio quality you did not design for, and for the failure paths — what a caller hears when the order system is down is a design decision, and if nobody made it deliberately, one got made by accident.
Ongoing maintenance
Products change, policies change, and a conversational system that reflects last quarter's returns policy is worse than no system at all, because it is confidently wrong.
Plan for a review cadence and a named owner for the knowledge the assistant answers from. This is a running cost, and leaving it out of the business case is the most common way a voice deployment looks cheaper than it is.
A worked example
Two deployments, same vendor, same contact centre.
The first covers three intents — order status, delivery date, resend tracking — reading from two systems, English only, voice only. It is live in weeks and the running cost is the licence plus a quarterly knowledge review.
The second covers eighteen intents including returns and refunds, writes to the order system, supports three languages across voice and chat, and needs a compliance review because refunds touch payment data. It is a different order of project, and roughly speaking every one of those decisions independently multiplies the work.
Neither is wrong. But they are frequently discussed as though they were the same purchase.
The assumptions to check
- Your intent volumes come from real interaction data rather than an assumption about what customers ask
- The systems behind the top intents have usable interfaces, verified rather than assumed
- Someone has agreed what happens on failure before launch
- The knowledge sources have a named owner for after go-live
Key takeaways
- The licence rate is rarely what decides the budget
- Integration scope, intent count, languages and channels are the main drivers, and each is a choice
- Read-only against one system is a legitimate and much cheaper first deployment
- Test the failure paths, and budget for ongoing knowledge maintenance
- Measure resolution and repeat contact, not containment alone
If you want a view on which intents are worth starting with, bring your interaction data to a first conversation.