A UK insurance broker's IVR menu had nine DTMF options, built and deployed in 2019. When we audited their call logs, 67% of callers pressed 0 on every single call — the option to bypass the menu and reach a human. Average time on hold after pressing 0: 4.2 minutes. The IVR they paid £11,000 to build was, in practice, a hold queue with added friction. Their voice agent now handles the same call volume, routes without menus, and averages 1.8 minutes to resolution. That is the case for IVR replacement in one paragraph.
If your IVR is more than five years old and hasn't been substantially overhauled, this guide covers what migration actually involves: auditing call flows, porting numbers, configuring SIP, and building fallbacks that hold when the agent doesn't.
What your IVR is actually costing you: abandonment rates, DTMF failure data, and maintenance overhead
Ofcom's Consumer Experience Research identifies call abandonment as a primary frustration for UK consumers — higher than wait time itself for many service categories. DTMF menus are a direct contributor: options that don't match the caller's situation, digit recognition failures on mobile networks with poor signal, and menus that have grown by accretion rather than design all push callers to abandon before selection.
The maintenance angle is under-discussed. A legacy IVR typically ties you to a vendor SLA: changes to prompts or routing require re-recording audio files, raising a support ticket, and waiting for a scheduled deployment window. We have audited IVRs directing callers to "press 3 for our Newcastle office" three years after that office closed. The vendor charges £350 to fix it.
Rough cost picture for a maintained UK SME IVR: initial build £8,000–£15,000; annual maintenance contract £2,000–£5,000; ad hoc change requests £300–£600 each. In lead-generation contexts, abandoned call cost at 35% DTMF abandonment typically exceeds the maintenance contract within a year. For IVRs with more than six options, abandonment before selection runs 40–50% in call log data we have reviewed.
AI voice agent vs IVR: the functional comparison that closes the business case
Before pitching a migration internally, you need a comparison that addresses an ops lead's actual concerns: cost, reliability, and call handling quality.
| Feature | Legacy IVR | AI Voice Agent |
|---|---|---|
| Call routing | DTMF key press | Natural language intent detection |
| Update process | Re-record + vendor deployment (days) | Edit prompt + publish (minutes) |
| Abandonment at routing step | 25–35% | 8–12% |
| Routing overhead | 45–90 sec before agent | 10–20 sec intent capture |
| Multi-intent calls | One path per call | Handles intent shifts mid-conversation |
| Integration | Fixed CTI screen-pop | Dynamic API calls during conversation |
| Maintenance cost | £2,000–£5,000/year | Platform fee + internal iterations |
| Fallback | Hold queue | Warm transfer + voicemail option |
The comparison that lands with decision-makers is the update process. When a business changes its service offering or adjusts operating hours, an IVR update means a vendor ticket. A voice agent update is a ten-minute prompt edit with immediate deployment.
What the table doesn't capture: AI voice agents introduce LLM latency and potential hallucination risk that DTMF routing does not. NICE's IVR documentation makes a valid point that deterministic routing still outperforms intent detection for tightly-scoped flows where input must be exact — banking PIN verification, prescription reference numbers. If your IVR handles a single unambiguous structured input, a full conversational agent adds complexity without benefit. A hybrid approach — voice greeting with DTMF escalation for structured data — is the right call in those cases.
Mapping your IVR decision tree to a voice agent conversation flow
Start with a full audit of your current IVR tree. Document every node: each option, each sub-menu, each routing destination. Most SME IVRs have grown by addition rather than redesign, so expect options nobody calls about and missing paths that default to "press 0 for reception."
The goal is intent clustering. Group every call type into four to eight core intents. The insurance broker's nine options collapsed to four after analysis: new claim, policy amendment, new quote, and general enquiry. The general enquiry category — 30% of calls — went to a warm transfer rather than a dead end.
Here is a working Retell agent configuration for that broker's inbound flow:
{
"agent_name": "InboundBrokerAgent_v2",
"voice_id": "11labs-Rachel",
"begin_message": "Hi, you've reached Hartfield Insurance. How can I help?",
"general_prompt": "You handle inbound calls for Hartfield Insurance. Identify whether the caller wants to make a new claim, amend a policy, get a quote, or something else. Confirm surname and policy number before transferring. Ask one clarifying question if intent is unclear — do not guess.",
"functions": [
{
"name": "transfer_to_claims",
"description": "Transfer caller to claims team for new or existing claim enquiries.",
"parameters": { "type": "object", "properties": {}, "required": [] },
"transfer_destination": "+441632960001"
},
{
"name": "transfer_to_human",
"description": "Transfer when intent is unclear after two clarification attempts.",
"parameters": { "type": "object", "properties": {}, "required": [] },
"transfer_destination": "+441632960000"
}
],
"max_call_duration": 600,
"end_call_after_silence_ms": 8000,
"recording_enabled": true
}
Note recording_enabled: true — this is not optional. See the compliance section below. For detailed turn-by-turn prompt patterns and latency budgets, see our call flow design guide for voice agents.
UK telephony migration: number porting, SIP configuration, and cutover planning
Number porting is the step that catches SMEs off-guard. Your existing geographic or non-geographic number belongs to your current carrier. Moving it requires a Porting Authorisation Code (PAC). The UK porting process typically takes 3–10 business days once a PAC is issued; Ofcom's General Conditions require completion within one business day of issuance, but enforcement is inconsistent.
The migration sequence we use:
- Provision a secondary SIP number and run the voice agent on it for two to three weeks of live parallel testing.
- Request a PAC from the current carrier once you have confidence in the agent's performance.
- Port the existing number to the new SIP provider.
- Decommission the old IVR after 48 hours of clean operation on the ported number.
Keep the old IVR provisioned on its original carrier until you have 48 hours of clean call data — SIP failover back to it costs roughly £30/month and is worth maintaining during the transition. We cover the full Twilio SIP trunk configuration, recording webhook setup, and carrier failover in our SIP trunking setup guide.
Compliance during migration: call recording continuity and ICO obligations
The ICO's guidance on PECR and UK GDPR requirements mean recording continuity during migration is a legal obligation for any regulated business that currently records calls — not optional.
Key risks during the migration window: a recording gap if the agent's recording configuration is untested before go-live; recordings landing in a new storage location without matching access controls; and consent disclosures that differ between the old IVR audio and the agent's opening statement.
Before cutover, run the agent on the parallel number with recording enabled and confirm recordings are writing to your destination (typically S3 or the platform's native storage). For FCA-regulated businesses, the change from "this call may be recorded" to "this call is handled by an AI and will be recorded" is a material disclosure change requiring documented compliance sign-off.
We built a dual-output recording setup for a financial services client — simultaneous write to platform storage and the client's compliance archive for the first 90 days — detailed in our Voice AI and Document Analysis case study.
Caller experience design: conversation patterns that match or beat button-press menus
The most common failure mode in voice agent deployments is an opening that narrates an IVR rather than starting a conversation: "You can ask me about billing, support, appointments, or say 'operator' for a person." That is a DTMF menu read aloud. It carries the same structural flaw: the caller must match their problem to a category you pre-defined.
A better opening: state who you are, ask an open question, let the caller drive.
- Weak: "You can ask about claims, amendments, or new quotes, or say 'operator' to speak to a person."
- Better: "Hi, you've reached Hartfield Insurance. How can I help?"
The second version consistently outperforms because it does not front-load the conversation with category labels the caller may not recognise as applying to their situation.
Two patterns that beat DTMF in testing: Disambiguation on partial intent — when the agent detects partial intent ("I need to change something on my policy"), ask one clarifying question rather than listing all possible options. Graceful degradation — when intent cannot be resolved after two attempts, hand off with context: "I'm going to connect you with one of the team — I'll let them know you were calling about [brief summary]." The caller does not have to repeat themselves to the human agent.
Fallback and failover: maintaining uptime during and after the cutover
Design fallback before go-live. A voice agent that fails silently is worse than an IVR that fails noisily.
Three layers to implement:
Confidence-threshold transfer. When the agent cannot identify intent after two clarification attempts, transfer to a human via a transfer_call function (Retell) or transferCall tool (VAPI). Set a hard trigger condition — do not rely on the LLM to independently decide when it is out of its depth. For the handoff patterns that preserve context across the transfer, see our voice agent transfer-to-human guide.
No-agent-available fallback. When the transfer destination has no available human, route to a voicemail handler that captures name, number, and reason, then dispatches a notification to the ops team. A 20-step n8n workflow handles this.
Infrastructure failover. If the AI provider or LLM endpoint returns errors at call initiation, the SIP trunk should route to a fallback — the old IVR number kept warm for 30 days, or a human reception queue. Twilio's elastic SIP trunking supports failover routing natively.
Monitor elevated transfer rates as a leading indicator of agent degradation. If transfers spike above 30% of total calls, something in the prompt or upstream LLM is breaking down. See our voice agent monitoring and alerting guide for the full alerting stack.
What changed in 2025–2026: no-code IVR migration tools in Retell and VAPI
The most significant development for IVR migrations in 2025 was Retell AI's IVR Import capability, which accepts an uploaded call flow diagram or DTMF menu tree and generates an initial agent configuration from it. This removed the manual transcription step that previously added a week to most migrations. The generated config requires human review — the tool maps menu options to intents but does not cluster related intents or simplify redundant paths — but it produces a working first draft in minutes rather than days.
VAPI's 2025 workflow editor introduced node-based visual call flow building. Operations teams accustomed to IVR tree configuration can now see a visual flow rather than working in JSON, which shortens the time from brief to first live call test. For a full capability and cost comparison across platforms, see our Twilio vs Retell vs VAPI breakdown.
The broader 2025–2026 shift: cloud telephony providers including Twilio and Vonage added native voice agent connectors, reducing the SIP configuration overhead that previously required a specialist. For straightforward SME deployments, the carrier-to-agent path can now be provisioned in a day.
Good / Bad / Ugly: three IVR-to-voice-agent migrations and what each one got wrong
Good: The insurance broker described above. What worked: starting with a call log audit before writing a single line of configuration. The 67% press-0 data made the business case undeniable and defined the success metric — time to resolution — upfront. The voice agent ran on a secondary number for six weeks before porting, giving time to tune intent detection against real caller language rather than the sanitised language in the brief.
Bad: A financial services firm that migrated without simplifying. They had a 12-option IVR and mapped every option directly to a named agent intent. The result was an agent that listed available topics in its opening message, effectively rebuilding the IVR in voice. Completion rates improved marginally; caller satisfaction scores did not. The fix — collapsing 12 intents to five and removing the topic list from the opening — took another two weeks. Migration without simplification ports the problem rather than solving it.
Ugly: A regional GP surgery that skipped the fallback. They deployed a voice agent for appointment booking with no transfer-to-human path. When the LLM misinterpreted a caller describing symptoms as a booking request, the call completed from the agent's perspective with no appointment made, no alert raised, and no handoff. The patient believed they had an appointment. They did not. The surgery reverted to a human-fronted model within a week. Voice agents without clinical intent detection and mandatory escalation for health-related language have no place in clinical settings without substantial additional safety design layered in.