How to Design an Auto Attendant Phone System Menu That Callers Can Use

On this page

What should an auto attendant phone system say first?

The opening message should identify the business, explain what callers can do and move quickly to the main choices. Avoid placing long marketing messages, legal notices or several pieces of information before the first usable menu.

A practical opening script is:

“Thanks for calling Nexgen Australia. For sales, press 1. For support, press 2. For accounts, press 3. To hear these options again, press 8. To speak with an operator, press 0.”

The greeting should answer three immediate questions:

Microsoft’s IVR call-flow guidance recommends avoiding lengthy introductory messages and writing prompts so the caller’s expected response comes at the end of the sentence. This makes the action easier to hear and reduces the time before the caller can respond.

Use a separate announcement for genuinely important information, such as a temporary closure. Do not turn the greeting into a general-purpose advertisement that every caller must listen to in full.

For broader phone-system planning, link this section to [business phone system features -> related phone system guide].

How many options should an IVR menu have?

Start with three or four primary options, then add another only when it represents a genuinely different caller need. The Australian Bureau of Statistics Forms Design Standards Manual recommends limiting menus to four options, with the wider literature commonly placing practical menu sizes between three and seven.

The number of options should reflect caller decisions, not the number of teams inside the business. If callers cannot distinguish between “customer care”, “client services” and “support”, those may need to become one plain-English option.

The ABS guidance also notes that limiting the number of menu levels and choices is important because poor planning, rather than technical failure, is a major source of IVR frustration. Treat four options as a design limit, not a target to fill.

Should the most popular option be press 1?

Usually, yes. Place the option selected by the largest share of callers first, based on call data, staff feedback or a short review of call reasons.

For example, a service business may use:

A professional-services firm may need a different order. The correct sequence depends on what callers actually need, not on which department has the highest status internally.

Review the order after launch. If callers frequently select option 3 first, or staff repeatedly transfer callers from one option to another, the menu structure may be reflecting the business rather than the caller.

How should auto attendant menu options be worded?

Describe the caller’s goal in familiar words, then state the action. “For technical support, press 1” is easier to understand than “Press 1 for the technical support department.”

Use one consistent pattern for every option:

Avaya’s IVR design guidance recommends placing the option before the action, keeping option-action pairs consistent, avoiding jargon and ensuring that choices are clearly different from one another.

Which words should an IVR menu avoid?

Avoid internal abbreviations, department codes and terms that callers are unlikely to use. Choose the language a customer would use when explaining their reason for calling to a person.

Replace:

Do not make neighbouring options overlap. “Product advice”, “technical assistance” and “service support” may sound different to staff but indistinguishable to callers.

How deep should an auto attendant phone system menu be?

Keep the main menu to one level wherever possible, and use a second level only when it separates clearly different caller intents. Every extra level should justify the additional listening and decision time.

A simple structure might look like this:

“`text

Main menu

├── Press 1: Sales

├── Press 2: Support

│ ├── Press 1: Existing service

│ └── Press 2: New technical issue

├── Press 3: Accounts

└── Press 0: Operator

“`

The Telstra Auto Attendant Feature Guide supports mapping the IVR before configuration, defining each auto attendant for a clear purpose and testing the completed call flow by calling it.

A second level is appropriate when callers can understand the distinction without needing to know your internal structure. It is not appropriate merely because several departments report to the same manager.

Ring groups and queues are outside this article’s scope and are covered in [ring groups and queues -> WP 5646 refresh].

Should callers be able to press a key before the menu finishes?

Yes, when the system supports it and the menu is used frequently by repeat callers. Allowing callers to enter a valid selection before the full recording ends is commonly called key-ahead or barge-in.

The feature should not interrupt essential information, such as an urgent closure announcement or a safety message. It should also be tested carefully so background noise, accidental key presses or speech-recognition errors do not send callers down the wrong path.

The ABS manual distinguishes between keypad interruption and voice-interface barge-in, and recommends allowing callers to skip non-essential output while keeping essential messages interrupt-free. For a keypad-first auto attendant, the practical rule is simple: let confident callers move quickly, but never make important instructions impossible to hear.

What should happen if a caller presses the wrong key?

The system should explain the error briefly, repeat the relevant menu and provide a clear recovery path. It should not disconnect a caller after one mistake unless there is a specific security or compliance reason.

A useful error prompt is:

“That selection isn’t available. For sales, press 1. For support, press 2. For accounts, press 3. To speak with an operator, press 0.”

After two unsuccessful attempts, consider offering a person, voicemail or a callback request rather than repeating the same message indefinitely. Make the invalid-input response shorter than the original greeting so the caller can recover quickly.

The flow should also define what happens when the caller:

Avaya’s auto-receptionist documentation identifies no-input handling as a configuration decision, including whether the caller should connect to an operator or be disconnected.

How can an auto attendant let callers reach a person?

Give callers a clearly announced human option at the main menu, and keep it available in the places where they are most likely to need help. Do not hide the operator option behind several layers or describe it with an internal term such as “reception services”.

A consistent approach is:

The ABS guidance states that callers should have the option to speak with an operator during normal business hours and should be told clearly when that is not possible. It also recommends offering a message or callback path outside business hours.

A human escape route does not make the auto attendant unnecessary. It gives callers confidence that the system is helping them rather than preventing access to the business.

Should an auto attendant use keypad input, voice input or both?

Use keypad input as the dependable baseline, then add voice input when it improves the caller’s task and the platform can recognise likely wording accurately. Offering both can make the menu more accessible, but it also creates another interaction that must be tested.

A combined prompt could say:

“For sales, press 1 or say ‘sales’. For support, press 2 or say ‘support’.”

Keypad input is useful when callers are in noisy environments, have strong accents or need to enter private information. Voice input can be convenient when callers want to describe an intent in ordinary language, but unclear prompts and recognition errors can quickly undermine the experience.

The ABS IVR design guidance describes keypad and automatic speech recognition as complementary input methods, with keypad entry offering a useful alternative when speech recognition is unsuitable or fails.

Do not introduce voice recognition simply because it is available. Test common accents, background noise, pauses, business names and the phrases callers actually use.

How should business hours and after-hours menus be structured?

Use separate business-hours and after-hours messages, but keep the menu logic recognisable so callers do not have to learn an entirely different system. State the relevant hours, date or next available contact method clearly.

For example:

“Thanks for calling Nexgen Australia. Our office is currently closed. Our business hours are Monday to Friday, 8:30 am to 5:00 pm Australian Eastern Time. To leave a message, press 1. To hear these hours again, press 2.”

Create distinct rules for:

Telstra’s configuration guidance recommends defining business-hour and holiday schedules before configuring the auto attendant. This reduces the risk of a correct menu playing at the wrong time.

Before each holiday period, test the actual number from an external phone. A schedule that looks correct in an administration portal can still produce the wrong greeting if the time zone, date range or holiday rule is incorrect.

For wider guidance on call handling outside menu design, add [after-hours call handling -> related phone system guide].

What is a good auto attendant phone system script?

A good script is short, specific and organised around caller intent. It gives each option one clear action and avoids unnecessary explanations.

Main menu script

“Thanks for calling Nexgen Australia. For sales, press 1. For support, press 2. For accounts, press 3. For general enquiries, press 4. To speak with an operator, press 0.”

Support submenu script

“For help with an existing service, press 1. To report a new issue, press 2. To return to the main menu, press 9. To speak with an operator, press 0.”

No-input script

“We didn’t receive a selection. For sales, press 1. For support, press 2. For accounts, press 3. To speak with an operator, press 0.”

After-hours script

“You’ve reached Nexgen Australia outside our normal business hours. To leave a message, press 1. To hear our business hours, press 2. To return to the main menu, press 9.”

Avoid saying “please” and “thank you” in every sentence. Avaya’s prompt guidance recommends using courteous language sparingly so callers can complete the interaction without unnecessary words.

How do you test an IVR menu before launch?

Test the menu as a caller, not just as the person who configured it. Write down the intended path, call from different devices and verify every valid, invalid and no-input outcome.

Use this test matrix:

Microsoft’s IVR testing guidance recommends calling the workflow, listening to each prompt and verifying that voice responses are recognised correctly. Test with people who did not design the menu; they are more likely to expose unclear terminology and assumptions.

For implementation support, link naturally to [hosted phone system setup -> related service page].

How do you know whether an auto attendant menu needs to change?

Look for evidence that callers are choosing the wrong path, abandoning before reaching a destination or repeatedly asking staff how to navigate the menu. The menu should be revised when caller behaviour and staff feedback show a persistent mismatch.

Useful review signals include:

Change one element at a time where possible: option order, wording, menu depth or fallback behaviour. Record the version and review the result after enough calls have passed to show a meaningful pattern.

An auto attendant is not finished when it is switched on. It is finished when callers can predict what to press, recover from mistakes and reach an appropriate person or message without unnecessary effort.

What are the most common auto attendant phone system design mistakes?

The most common mistakes are oversized menus, internal language, hidden human assistance and untested time rules. Each one adds friction before the caller reaches the actual purpose of the call.

The ABS Forms Design Standards Manual identifies menu structure and wording as central design issues, while Avaya’s IVR recommendations emphasise familiar language, clearly differentiated options and reliable navigation instructions.

FAQ: What is an auto attendant phone system?

An auto attendant phone system answers an incoming business call with a recorded greeting and menu options. It can let callers choose a department, person, information message, voicemail or operator.

FAQ: Is an auto attendant the same as IVR?

An auto attendant is commonly the front menu that directs incoming calls. IVR is a broader term that can include multi-level menus, keypad input, speech recognition, information prompts and other automated call-flow steps.

FAQ: How many options should a phone menu include?

A practical starting point is three or four primary options, with each option representing a distinct caller need. If more choices are unavoidable, group related needs under a clear category rather than listing every internal team.

FAQ: Should every auto attendant include a way to reach a person?

Yes, where a live person is available, the menu should clearly explain how to reach them. Outside business hours, provide an accurate alternative such as leaving a message or requesting a callback.