Most IVR replacements fail in the same way. The old menu tree gets switched off on a Thursday, the new voice agent goes live on the Friday, and by the following week someone has quietly routed the main number back to the queue because complaints outran the savings.
The migration is not technically hard. It is operationally unforgiving, because the thing you are replacing is the front door of the business and every mistake is heard by a customer before it is seen by you.
What follows is the staged plan Modern Intelligent Solutions uses to move a contact centre from a legacy IVR to an Arabic-first voice agent without taking the phone line down. Three phases, each with a gate you have to pass before the next one starts.
Why the menu tree stopped working
Keypad menus solved a real problem: they routed calls without staffing the routing. The cost was pushing your org chart onto the caller, who has to translate "I was charged twice" into press four, then press two.
Two things changed. Callers now expect to say what they want in their own words, in their own dialect. And the routing decision, which is what the menu was for, can now be made from what the caller actually said rather than from which digit they guessed. A voice agent that answers in native Saudi dialect, resolves the call or routes it with context attached, is doing the IVR's job without making the caller do the translation.
That is the opportunity. It is also why migration is risky: you are replacing a dumb system that fails predictably with a capable one that fails in ways your monitoring has never had to catch.
Before phase one: know what your line actually does
Skip this and every later measurement is guesswork.
Pull one week of call logs. Not a sample — a full week, including the after-hours tail. For each call you want the reason it was made and whether it was answered. Then sort the reasons by volume and answer a blunt question about each one: should a machine ever handle this?
The answers land in three bands. Administrative, high-volume and unambiguous — opening hours, location, order or application status, booking and rescheduling. Those are the automation candidates. Then a middle band that depends on your policies and risk appetite. Then a band that a machine should never take, which in most organisations means complaints that have already escalated, anything financial or contractual, policy exceptions, and any caller who asks for a human.
Write the third band down and treat it as fixed. It will come under pressure the first time someone is measured on containment rate, and the list only survives if it was agreed before the numbers existed.
Most teams find the top five reasons cover the large majority of their inbound volume. That concentration is what makes the migration tractable — you are not teaching an agent your whole business, you are teaching it five conversations.
Phase one: shadow mode
Run the voice agent in parallel with the live IVR, handling nothing.
Calls continue to route exactly as they do today. The agent listens, classifies the intent, and records what it would have done. Nobody's call is affected, which is the entire point: you are collecting evidence at zero risk to the customer.
What you are looking for over two to four weeks is whether the agent's understanding matches reality. Does its intent classification agree with what the call was actually about? How often does it produce no confident classification at all? Where does recognition degrade — background noise, specific dialects, callers who open with a long unstructured sentence?
Latency is worth watching here even though nothing is live, because it is a property of the deployment rather than the script. Around 1.2 seconds reads as conversation. Materially slower and callers start talking over the agent, which degrades recognition, which slows the response further.
The gate for phase two is not a single number. It is that intent classification is reliable on the specific reasons you plan to automate first. An agent can be excellent overall and still be wrong about the one intent you were counting on.
Phase two: partial automation
Turn the agent on for the narrowest useful slice — usually the two or three highest-volume administrative reasons from your audit. Everything else routes as it does today.
Two design decisions determine whether this phase succeeds.
The first is the fallback. Escalation must be instant, and the human must receive the transcript, the classified intent, and anything the agent already collected, so they can continue rather than restart. A transfer that drops context is worse than no automation, because the customer has now explained themselves twice and is angrier than when they called. Build this path before the automation it backs up.
The second is what the agent is allowed to write. If it books or reschedules an appointment, it does so through your existing scheduling system's API, writing into the calendar your staff already use. There is no separate ALLO calendar to reconcile, and that constraint is deliberate — a second source of truth for appointments creates a class of problem that outlives the migration.
Watch resolution and escalation rates per intent, not in aggregate. The aggregate will look fine while one specific conversation is going badly, and per-intent is the only view where you can see which one.
The gate for phase three: the automated intents hold their resolution rate for a few weeks without a rise in repeat calls. Repeat calls are the number that catches the failure your containment rate hides — a call the agent closed and the customer had to make again is not a resolved call.
Phase three: widening the scope
Expand one intent at a time, against the same evidence. Each addition gets its own shadow period if it differs meaningfully from what the agent already handles.
This phase is mostly operational discipline rather than engineering. The agent's coverage grows, the exception list stays fixed, and someone keeps listening to archived calls. Every call is transcribed, topic-classified, sentiment-analysed, quality-scored and archived, which makes review possible — but the review still has to be somebody's job, because an agent nobody listens to drifts in exactly the ways the dashboards were not built to notice.
Deployments typically go live within about a week; the phased rollout is what takes time, and it should.
What to hold onto
The teams that get through this treat the voice agent as production software rather than a launch. They keep the phone line working throughout, they expand on evidence, and they never let the never-automate list get renegotiated by whoever owns the containment metric that quarter.
The migration is incremental or it is a rollback.
If the line you are migrating belongs to a clinic, the same staged approach applies with one additional rule — no clinical call is ever automated. See AI voice agents for Saudi clinics. For the engineering side of taking an agent into production, production hardening for AI integrations covers permissions, observability and the handover design.
