An IVR migration worked example: map, review and pilot one route

Editorial correction: This URL previously presented an unsupported customer case study and a two-hour migration claim. Those claims have been removed. The scenario below is entirely hypothetical. It is not a real customer engagement, benchmark, testimonial or report of Burki performance.

Imagine a fictional home-services business with an existing phone menu for opening hours, new repair requests and current-job questions. The team wants callers to describe their needs naturally while preserving a route to staff. The objective is a useful, verified first route—not reproducing every menu branch immediately.

Step 1: define the authorized exploration

The owner identifies the number or test environment they control, the permitted calling window, a maximum expense and a person to contact if exploration reaches a live queue. They record known after-hours behavior and exclude branches that require real account credentials or would trigger a transaction.

The observed map is evidence of paths reached under those conditions. It is not proof that every hidden menu, holiday schedule or caller-specific branch has been discovered. Mark incomplete paths explicitly.

Step 2: distinguish observations from business decisions

Suppose the fictional exploration captures the following:

A map cannot infer permission to access customer records or promise a technician's arrival. The team chooses public information and new-request intake for the first assistant; current-job access remains on the existing route.

Step 3: review an editable draft

The draft asks about the service needed, location and preferred contact details. It uses approved business facts and identifies unknowns. A customer correcting “kitchen” to “bathroom” should update the request rather than produce two jobs.

The owner reviews each generated instruction and supported workflow step. Unsupported actions remain unresolved requirements. A transfer-shaped node does not establish an accepted telephone handoff, and a calendar-shaped step does not establish a working booking integration.

Step 4: test evidence, not a convincing closing line

Practice ordinary inquiries, missing information, corrections, an unavailable action and a request for a person. Browser trial actions are simulated. For a later funded action test, verify the returned identifier and destination record before counting success.

LiveKit documents SIP call transfer mechanics, but runtime capability alone does not prove the selected carrier and destination work. Keep route-specific acceptance separate from draft review.

Step 5: pilot with a way back

The fictional team would introduce only the accepted intake route, keep the original phone setup available and name someone to review early calls. They would track correct requests, unresolved calls, failed handoffs, repeat contacts and expense. No numerical improvement is assumed here.

In Burki, IVR Explorer and conversion can support exploration and drafting; they do not replace business approval or production acceptance. Use the migration checklist and draft review guide to prepare your own evidence. A credible case study comes later, from an actual deployment with permission to publish its results.