The demo always works. That is the problem.
A voice AI demo is a controlled conversation in a quiet room with a cooperative speaker and no downstream dependencies. It sounds impressive because the hard parts have been removed. The hard parts are not in the conversation. They are in what happens to the information after the call ends, and that is where most of these projects quietly fail six weeks after the steering committee applauded.
I want to make the case that voice AI is an integration project with a conversational front end, and that scoping it any other way produces a system nobody can operate.
The three tiers of a voice deployment
It helps to separate the stack into tiers with very different risk profiles.
The telephony and conversation tier handles the call itself. Latency budgets, barge-in, interruption recovery, noise and accent robustness, silence handling, call transfer. This tier is genuinely difficult and it is also the most commoditized. The gap between a purpose-built platform and an in-house effort is widest here, and it is widening.
The logic tier holds your qualification rules, routing decisions, and business constraints. This is small, it is yours, and it changes often. It should live somewhere you can edit without a deployment.
The integration tier writes to the systems of record. Calendar, CRM, ticketing, dispatch, billing. This tier is where the project lives or dies, and it is consistently the one that gets estimated at a fraction of its true size.
Teams that reverse this priority, treating the conversation as the project and integration as glue, ship something that produces transcripts. Transcripts are not an outcome. Nobody reads them.
What integration actually costs
Six problems come up in nearly every deployment and none of them are visible in a demo.
Identity resolution. The caller is a phone number. Your CRM is organized around contacts, accounts, or properties. Matching one to the other is ambiguous for repeat callers with multiple numbers, shared household lines, and businesses calling on behalf of customers. Get this wrong and you attach a new job to the wrong record, which is worse than attaching it to nothing.
Write failure semantics. The call ends and the calendar write fails. What now? The caller believes they have an appointment. The system believes nothing happened. Any design without an explicit answer to this defaults to the worst one, which is silence.
Idempotency. Retries are normal. A retried booking that creates a second appointment is a support ticket and an angry customer. Every write path needs a key that makes duplicate submission safe.
Partial success. The CRM write succeeded, the calendar write failed. You now have a lead with no appointment, and no human knows. This state needs to be detectable and it needs an owner.
Schema drift. Somebody adds a required field to the CRM on a Tuesday. Your voice system starts failing writes on Tuesday afternoon and nobody notices until Thursday, because failed writes are invisible unless you built for them.
Clock and timezone handling. Appointment booking across time zones and daylight boundaries produces a specific class of bug that is embarrassing in exactly the way customers remember.
None of these are exotic. All of them are boring distributed systems problems. That is the point. The AI part is largely solved and purchasable. The integration part is your normal engineering work, and it needs a normal engineering estimate.
Observability has to exist before launch
Voice systems fail quietly. No customer files a ticket to report that the automated agent was slightly confusing before they hung up and called a competitor.
Which means the instrumentation is not a phase two item. Before go-live, you need recordings, transcripts, structured outcomes per call, and the ability to slice by intent, hour of day, and failure mode. You need alerts on write failure rate, not just on system uptime, because a system that answers every call and writes none of them will show as green on every dashboard you own.
The single most useful metric is escalation rate segmented by intent, sorted descending. That is a prioritized defect list generated by real callers, and it is more valuable than any roadmap workshop.
Build versus buy, at the tier level
The build or buy question is usually asked about the whole system, which is the wrong altitude.
Buying the telephony and conversation tier is right for almost everyone. That surface is large, the failure modes are subtle, and the work is not differentiating unless voice is your actual product.
Building the integration tier is right for almost everyone, because it encodes how your business works and because owning it keeps the structured record of caller intent inside your organization. That record is the durable asset. The conversation is a commodity.
The logic tier should be configuration, not code, wherever possible, because operations people need to change qualification rules without filing a ticket.
Organizations that invert this, building the conversation and buying the integration through a low-code connector, end up with the expensive half in-house and the important half outside their control.
The escalation design question
There is a design decision that determines whether the deployment is trusted internally, and it gets made implicitly if you do not make it explicitly.
Is a transfer to a human a success or a failure?
If the system counts transfers as failures, it will be tuned to avoid them, and callers will end up trapped. The technical consequence is worse than the customer experience consequence, because you lose the signal. Every trapped caller is a defect you can no longer see.
The better framing measures how fast the right calls reach the right person with full context attached. That changes what you build. It means the transfer path carries the transcript, the extracted fields, and the reason for escalation, and it means somebody on the operations side reviews those weekly.
The scoping rule that saves the project
Before any voice project starts, write down the specific call types in scope, name the systems each one writes to, and state what happens when each write fails. If that document cannot be written in an afternoon, the scope is too broad and the project will produce a demo instead of a system.
The technology is ready. The integration work is the same work it has always been, and it deserves the same respect any other production integration gets. Projects that treat voice as an AI initiative fail. Projects that treat it as an integration with a voice interface tend to still be running a year later.