An IVR Map Coverage Checklist for Finding Missing Paths

An IVR map coverage checklist helps you decide whether a phone-tree diagram is complete enough for the decision you want to make. A visually tidy tree can still omit the branch that most frustrates callers: silence, invalid input, an unavailable department or a menu that changes outside business hours.

Coverage is not simply the number of boxes drawn. It is the relationship between the choices callers can encounter and the paths someone has actually observed. Keep discovered, verified and unknown paths visibly separate.

Establish the mapping boundary

Name the telephone number, test date, business-hours state and authorised exploration scope. If the menu changes by language, caller type or account status, note which version the map represents.

A hypothetical business might have an open-hours tree with sales and support, plus an after-hours message. A map collected only on a weekday afternoon cannot be called a complete representation of both. It can still be useful if that limitation is explicit.

Burki's IVR testing guide introduces the broader review process. Treat an automatically discovered map as observed material for review rather than a guarantee that every reachable state was explored.

Audit each node with the same questions

For every menu node, ask what the caller hears, what input it expects and what happens next. Capture the prompt wording or a concise faithful summary. Then mark each advertised option with the observed destination.

Use a table such as this:

This makes uncertainty inspectable. An unknown route is more honest and useful than a guessed terminal box labelled “support.”

Look for loops and shared destinations

A phone tree is not always a simple tree. Several choices may lead to the same queue, and a repeat option may return to an earlier prompt. Draw those relationships accurately rather than duplicating them as unrelated destinations.

Check whether a caller can get trapped in a loop without a useful exit. For example, an invalid digit may repeat the menu indefinitely, while silence may disconnect immediately. Those differences can shape the redesign even when all ordinary choices work.

Keypad navigation depends on DTMF delivery over the actual route; LiveKit documents that capability in its DTMF guide. A digit being sent does not itself verify the destination, so retain the observed next prompt or endpoint.

Weight gaps by caller importance

Not every missing path deserves equal effort. Ask the business which enquiries occur most often and which failures create the greatest operational harm. Prioritise those routes for manual confirmation.

Do not invent percentages when call-distribution data is absent. Use a qualitative priority such as common, consequential or low-frequency, and record who supplied the judgement. Replace it with measured information when reliable data becomes available.

A useful first review might discover that the main support path is verified but the overflow destination is unknown. That is a concrete next action, not a reason to discard the whole map.

Keep the map current

Assign an owner and a review trigger. A new department, changed opening hours or a revised greeting should prompt a check of the affected paths. Preserve the previous map so reviewers can see whether a difference reflects a real system change or incomplete exploration.

The map should support a decision: improve a prompt, remove a loop, test a fallback or plan a reviewed conversational replacement. Burki's conversational IVR guide provides the broader design context. Start by marking every current branch as observed, verified or unknown; that alone makes the diagram more operationally trustworthy.