Telephone menu · Procedure with template

Design an IVR menu: script, routes and acceptance tests

Content updated:

Short answer

A useful IVR menu groups reasons for calling that customers recognise and routes them to a destination that can resolve them. Keep options limited, write clear messages and define invalid-input, silence and closed-department handling.

Key verification: Test the six menu-tree scenarios before publishing it for customers.

Sources and limitations

A useful IVR menu helps the caller choose a destination that can handle their query. Start with the reasons for calling, write a few understandable options and prepare an exit for those who do not press anything or make a mistake. If all the options end up with the same person, maybe you don't need a menu.

The main job is to design the routes and the voiceover. The length of the wait, shift coverage, and subsequent recovery require your own decisions.

Group reasons, not internal departments

Review a sample of recent queries and group them by what the client needs: request a quote, consult a job or resolve an invoice. An internal name like "operations" may mean little to a first-time caller.

For each option, identify a main destination and another if the first one cannot serve. If there are no different destinations, try a direct entry. You can also start with two options and expand only when an observable need appears.

Design an IVR menu: script, routes and acceptance tests: table 1
Customer Need Example Option Destination Alternative Output
Request a service 1: new quote Commercial team General customer service
Consult a contracted job 2: service in progress Coordination Shift manager
Discuss an invoice 3: billing Administration Mailbox reviewed by administration

This tree is fictional. Three options are not a universal rule: the correct number is the one that reflects real destinations without forcing you to remember an unnecessary list.

A phrase that you can adapt

Thank you for calling [company]. To request a quote, press 1. To consult a service in progress, press 2. For billing, press 3. If you don't know which option to choose, wait and we will assist you in the general team.

The last phrase should only be used if that route exists and is served. If the general destination is a mailbox, say so. A promise of care that ends in a cutoff creates a confusing experience.

Pronounce the need before the number and use the same vocabulary on the web. Avoid mixing the menu with long promotions. Listen to the speech from a telephone, with normal background noise, to check that you understand the options without looking at the text.

Bring the tree to the call editor

  1. Save a copy or screenshot of the current flow and note who authorizes the change.
  2. Add the menu step within the corresponding service path.
  3. Associate each key with its destination and check that no branch is empty.
  4. Configure the no input or invalid key behavior depending on the available options.
  5. Prepare output from each destination if there is no response.
  6. Save, publish when appropriate, and run tests before finishing the job.

Aircall documents an IVR widget with per-key configurable message and branches; Supports uploaded audio, speech synthesis or direct recording. Consult your IVR guide . In CloudTalk, check the group destinations and routing options available on your plan; The group guide explains the organization of your agents.

Design the route of those who make mistakes

Decide explicit behavior for silence, invalid key, and selection of a closed department. A simple proposal is to repeat the message once and then offer general customer service or an identified mailbox, as long as your editor allows that route.

Do not chain repetitions without limit. Also don't send the person to the beginning after each transfer. The target should be given enough context to help her without asking her to select the same option again.

If you serve people who cannot comfortably use the keyboard, check the touchless route. The menu should not turn a valid query into a call with no destination.

Six tests before publishing

Design an IVR menu: script, routes and acceptance tests: table 2
Test What you should observe
Press each valid key Correct destination and person informed of the reason
Do not press anything Expected output, without endless repetition
Pressing an invalid key Message or understandable alternative
Destination busy Branch continues to useful output
Department closed Does not promise immediate service that is unavailable
Transfer from one destination to another Does not force you to return to the initial menu without need

Marks calls as tests and records date, route and result. If a branch fails, fix it before changing the rest of the tree.

How to review the menu after

Observe which options customers use, which transfers repeat, and where they abandon. An option that no one uses may be misnamed; one that receives almost everything may indicate that the distribution contributes little. Talk to the team before adding more levels.

If the selection works but the client waits too long, go to to configure the queue . If it only fails on specific dates, check the service calendar .

Sources and limitations

Documentary review: . Content type: Procedure with template.

Sources describe terms and capabilities stated by their owners. Proposed protocols and fictional examples do not establish product tests performed by CallsIQ.

How to report a correction

Check current terms

Consider these options if they solve the problem described. Confirm features, limits and availability in your country.

AircallOfficial plans and termsCloudTalkAffiliate link

The labelled commercial links may earn CallsIQ a commission or referral reward. Our commercial policy.

How this guide was prepared

Official sources, explained calculations and clearly labelled examples. Read about our methodology and use of AI in writing.