Replacing Your IVR with an AI Voicebot: A Migration Playbook

Most IVR-to-voicebot migrations don't fail because the AI can't understand callers. They fail because the migration was treated as a model swap instead of an operational cutover. The model is the easy part. The hard part is everything wired around it: telephony, call routing, agent workflows, and the fifteen years of institutional knowledge baked into your existing menu tree.

Here's the playbook we use, in the order problems actually show up.

Start by mapping the menu tree, not the model

Before touching a voicebot platform, pull the actual call flow out of your current IVR — not the diagram from the original vendor SOW, the live one. Menu trees drift. Options get added by phone, options get orphaned when a team gets reorged, DTMF shortcuts get bolted on for power users. None of that is in the design doc.

For each leaf in the tree, capture three things: call volume share, current containment rate, and how it terminates (self-service, transfer to a queue, or dead end). This becomes your intent list. A voicebot that handles 80% of the tree's volume but misses the 20% that's actually staffed queue transfers will look great in a demo and generate complaints in week one.

The gap that always gets underestimated: audio quality

Every ASR vendor's accuracy numbers are measured on clean, wideband audio. Your callers are on a cell connection in a parking garage, on a landline handset from 1998, or on a conference room speakerphone. Telephony audio is 8kHz, half the sample rate of what most demos run on, and it strips information the model was implicitly relying on.

Run a real accuracy test before committing to a vendor: record actual calls from your existing IVR (or route a small percentage through a shadow bot with no customer-facing effect), and measure word error rate on that corpus, not a benchmark set. Do this per accent and per background-noise condition your caller base actually has — a single blended WER number hides which segments you'll fail on.

Barge-in and DTMF passthrough are not optional

Two features get cut in early builds because they're annoying to implement, and both are things callers notice immediately:

Barge-in. Callers who've used phone systems for years interrupt prompts constantly. If your bot can't be interrupted, every caller who tries will assume it's broken and either hang up or mash zero.
DTMF passthrough. Some of your call volume is from IVRs feeding your IVR — partner systems, monitoring platforms, other automated callers that navigate by touch-tone. If the voicebot can't fall back to DTMF handling, you silently lose that traffic and won't notice until someone escalates a partner integration ticket weeks later.

Phase the rollout by traffic percentage, not by date

Don't cut over on a fixed date. Route a small percentage of inbound calls to the new system, watch containment rate and escalation-to-human rate for at least one full week (call patterns vary by day of week and time of month more than most people expect), then increase the percentage. Keep the old IVR warm as a fallback path the entire time — not as a "just in case," but as the explicit destination for any call the voicebot's confidence scoring flags as low-certainty.

The trap here is treating the ramp-up as a formality. Teams that go 5% → 100% in two steps miss the failure modes that only show up at scale: queue-transfer race conditions during peak hours, session state getting dropped when the platform autoscales, and long-tail intents that only appear once you're past a few thousand calls.

Agents need a different kind of training, not less training

A common assumption is that automating the front door means less work for contact center staff. In practice, agents now receive a different mix of calls — the ones the bot couldn't resolve, which skew toward complex, frustrated, or edge-case callers. If agents aren't told this is coming, average handle time appears to get worse post-launch, and the project gets blamed for a problem that's actually a staffing-mix shift.

Give agents visibility into what the bot attempted before transfer — the transcript, the detected intent, why it escalated. Without that context, every transferred call starts from zero, which is slower for the agent and worse for the caller who just repeated themselves to a machine for no reason.

What "done" actually looks like

Containment rate is the headline metric everyone tracks, but it's a lagging indicator and easy to game by making escalation harder than it should be. Track these alongside it:

False containment rate — calls the bot marked as resolved that the caller immediately called back about. This is the number that tells you if you're hiding failures instead of fixing them.
Time-to-transfer for low-confidence calls — a bot that takes ninety seconds of failed attempts before giving up is worse than one that fails fast.
Escalation context quality — measured qualitatively at first, by having agents rate whether the handoff context was useful.

None of this is exotic. It's the same discipline you'd apply to any production system change — the difference with voice is that failures are audible to the customer in real time, and there's no "check the logs later" grace period. Get the boring operational parts right and the model choice matters a lot less than the vendor comparisons make it seem.

If you're mid-migration and hitting one of these walls, or scoping one and want a second opinion on the rollout plan, get in touch — this is the kind of thing we help teams work through directly.