Reviewing an IVR conversion draft before callers use it
Check prompts, inferred branches, missing connections and fallback behavior after converting an IVR map into an assistant workflow.
Table of Contents▼
An IVR map can save transcription and drafting work. It cannot independently confirm the business policy behind each menu. Burki's conversion output is an editable assistant workflow draft that still needs a business and technical review.
This guide describes that review. It is not a customer case study or a measured promise that a particular number of branches can be migrated in a fixed time.
Understand what was observed
Start with the exploration record. Check which menus were reached, the prompts captured and any incomplete branches. Account authentication, opening hours and depth limits may change what an exploration can see. A destination inferred from a prompt needs confirmation from the business owner.
If the map labels a path “claims,” determine whether it starts a new claim, answers general questions or connects to a specialist. Those are different assistant responsibilities.
Review the generated instructions
Read the opening prompt and every conversation step. Remove stale phone-menu wording such as “press 1” from a conversational route unless keypad input is deliberately retained. Replace inferred facts with approved business facts and identify questions the assistant must not answer.
Do not give the assistant broader authority than the old menu. A billing route might collect a request; that does not authorize refunds, account disclosure or taking payment details.
Resolve the graph's operational gaps
| Draft element | Required review |
|---|---|
| Conversation prompt | Clear purpose, approved facts and an understandable next question |
| Collected information | Required fields, validation and what happens when the caller corrects them |
| Condition | The evidence used to choose a branch, including an unknown value |
| External action | Actual connection, permissions, success result and timeout behavior |
| Human handoff | Supported runtime and carrier, approved destination and recovery path |
| End of call | No premature success announcement while an action is still pending |
Existing unsupported steps should produce actionable validation, not disappear or run as if supported. A transfer-shaped node is not proof that a live transfer has passed acceptance.
Practice without publishing
Test the exact draft revision. Ask an ordinary question, choose an unexpected branch and correct a previously supplied detail. Compare the transcript with actual workflow transitions and action outcomes. In a browser trial, external actions are simulated; no calendar booking or telephone call should be inferred from a practice response.
Edit and repeat the affected scenario. Publishing is a separate decision, and telephone readiness requires the configured number, funding and provider checks.
Keep a record of the decision
Record which routes are ready, which remain unknown and which stay on the existing IVR. Include the approved draft revision and the controlled telephone-test evidence for the route you will expose. If a critical case is unresolved, keep that route out of the rollout rather than hiding it inside a generic success label.
Start with an authorized IVR exploration or use the broader migration checklist.
Ready to try Burki?
Create an assistant and check your available browser practice allowance.
Create your assistantTrial eligibility and available practice are shown in your workspace.