IVR-to-AI migration: preserve the business rules, test the new route

Migrating an IVR means preserving useful business behavior while changing how callers reach it. Your current phone menu may be awkward, but it often contains important routing rules, opening hours and exceptions. Capture those before replacing the entry point.

Inventory the existing route

List the published numbers, owners, carrier setup, destinations and rollback contact. Ask each department which calls it expects and which require authentication. Include after-hours behavior, invalid keypad input, language options and queues that cannot accept a transfer.

Record what you actually observe. A reachable billing menu is evidence of that path; it is not proof that account-specific or after-hours branches have also been explored.

Use IVR exploration as evidence collection

Burki's IVR Explorer uses funded, bounded calls to inspect an authorized telephone system and save its map. Depth, duration, carrier capacity and conditional prompts can limit coverage. A partial map can still be useful when its gaps are explicit.

Compare the map with existing documentation and staff knowledge. Resolve contradictory destinations before generating a replacement. Do not assume every DTMF combination was tried, every prompt was recorded or every route is current.

Convert into a draft, not a cutover

Conversion creates an editable assistant workflow. Review inferred instructions, conditions and requested information. Treat each external action as a separate integration task. A node called “book appointment” is not connected to a calendar merely because it appears on the graph.

For each route, answer three questions: what can the assistant say, what may it change, and what evidence proves completion? Keep unsupported steps inspectable and resolve their readiness errors before real usage. See reviewing an IVR conversion draft.

Test before changing production routing

Use browser practice to test the draft's instructions and corrections. Then verify a controlled telephone route using numbers and destinations you are authorized to call. Include unknown requests, caller interruption, failed actions and hangup during processing.

If human handoff is required, verify answer, rejection, timeout and recovery on the specific supported carrier/runtime configuration. Do not infer transfer acceptance from an imported graph or a successful browser call.

Introduce one measured route

Keep the previous route available while you introduce a narrow scenario. Define the switchback procedure and the person who can execute it. Watch call outcomes, caller complaints, unresolved requests and cost; count business actions separately from completed calls.

Number continuity depends on carrier configuration and any forwarding or porting arrangements. Do not promise that a number remains unchanged without checking that route. Similarly, published time-to-migrate or savings figures are not a substitute for your own inventory and test results.

A migration is ready when the team can demonstrate the selected outcomes and recover from a failed path. It is not ready just because a graph was generated. Use the test worksheet to record that evidence.