VMware ESXi and vSphere Cluster Management

Designing Effective Auto Attendants in Asterisk

Learn how to design a clear Asterisk auto attendant with concise prompts, schedules, operator handling, fallback routes, testing, and maintainable dialplan planning.

An auto attendant, also called an automated attendant, is a telephony feature that answers inbound calls and provides spoken menu choices for routing. It lets callers reach a destination without first speaking with a live receptionist.

For many organizations, the auto attendant is a caller's first direct interaction with the business. A clear menu builds confidence and improves the chance that callers complete their intended task. A confusing greeting, excessive choices, or missing fallback can cause wrong transfers and abandoned calls.

Start with caller tasks

Design the menu around what callers need to accomplish, not only around the company's internal departments. Callers may know that they need help with an order, an invoice, or a technical problem without knowing which internal team owns that work.

• Use familiar, plain-language names such as “Sales,” “Support,” and “Billing.”
• Describe each destination well enough for a caller to choose confidently.
• Give every top-level choice a distinct purpose and digit.
• Avoid overlapping labels such as “Customer Service,” “Client Services,” and “Account Services” unless their differences are obvious.
• Do not force callers to understand the organization's reporting structure.

Example: a simple main menu

A practical small-business menu might say: “For Sales, press 1. For Support, press 2. For Billing, press 3. To speak with an operator, press 0.” This presents four useful choices without exposing numerous internal teams.

Keep the greeting and prompts short

A greeting is the opening recorded announcement played to an incoming caller. A prompt is any recorded instruction or announcement played during call handling. The opening greeting should identify the business and move the caller to useful choices quickly.

Separate a short welcome from menu instructions when that makes recordings easier to maintain. Avoid placing promotions, long legal statements, or extensive company descriptions before the choices. Optional information can have its own menu option or play after the essential routing instructions.

A predictable prompt structure is:

1. Brief business identification or welcome.
2. Contextual status information, such as a closure or expected wait.
3. Available menu choices.
4. Operator instructions and fallback information.

Speak at a steady pace, pause briefly between choices, and use the same wording in recordings and written documentation. The first menu should not require callers to remember a long list of instructions.

Limit menu complexity

Keep the number of main-menu choices manageable. More than roughly five primary choices is a warning sign that the menu may need redesign. This is not a strict technical limit, but it is a useful usability test.

Use a submenu only when it groups related tasks and reduces the caller's cognitive load. For example, a Support submenu might offer product support and emergency support. Avoid deep trees, circular routes, and broad submenus that simply repeat the main menu.

CONCISE MENU                         OVERLOADED MENU
----------------                     -----------------
1 Sales                              1 New sales
2 Support                            2 Existing sales
3 Billing                            3 Renewals
0 Operator                           4 Product questions
                                     5 Technical support
                                     6 Account support
                                     7 Billing questions
                                     8 Payment status
                                     9 Shipping
                                     0 Operator

Few distinct decisions                Many similar decisions
Easy to scan and remember             Higher confusion and abandonment

The goal is not to minimize every menu mechanically. The goal is to make the next action obvious to a caller who may be unfamiliar with the business.

Plan schedules, closed hours, and holidays

Business hours are the periods when normal destinations and staffing are available. After-hours routing is the treatment used outside those periods. Holiday routing is special treatment applied on configured closure dates.

Use distinct announcements for normal hours, closed hours, and holiday closures. Each message should state what callers can expect and what they can do next.

• During open hours, route department choices to queues, ring groups, or other staffed destinations.
• After hours, explain that the office is closed and offer only appropriate options such as voicemail, emergency support, or business-hours information.
• On holidays, identify the closure when appropriate and provide the correct return date or next step.
• Review holiday dates, schedules, recordings, and routes before each planned closure.

Do not assume that a normal after-hours message is suitable for a holiday. A holiday may require a different return date, emergency instruction, or staffing arrangement.

Define the operator option

An operator option is a menu path for human assistance, commonly assigned to digit 0. Decide exactly what happens when the caller selects it:

• Ring a receptionist group.
• Enter an operator queue.
• Reach a receptionist voicemail box.
• Use an alternative assistance destination when the primary group is unavailable.

Tell callers when the option is available. For example, the open-hours greeting can say, “For an operator, press 0.” If the operator is not staffed after hours, do not imply that a person will answer immediately.

Always define a no-answer or unavailable fallback. A caller who presses 0 should not hear silence, encounter a dead end, or return unexpectedly to the beginning of the menu.

Handle invalid entries and timeouts

A timeout is the period Asterisk waits for a selection. An invalid entry is a keypad selection that is not assigned to a valid destination.

Specify both behaviors before implementation:

• Repeat the menu once or a small, defined number of times after no input.
• Play a concise correction prompt after an unsupported digit.
• After the retry limit, send the caller to an operator, assistance destination, or voicemail.
• Never trap a caller in unlimited menu repetitions.

Create the call-flow diagram first

A call-flow diagram is a visual map of call states, choices, routes, schedules, and fallback behavior. Create it before writing the dialplan.

                         +----------------+
                         |  Incoming call |
                         +--------+-------+
                                  |
                         +--------v-------+
                         | Schedule check |
                         +---+--------+---+
                             |        |
                    holiday  |        | open hours
                             |        |
                    +--------v--+  +--v-----------+
                    | Holiday   |  | Open greeting|
                    | greeting  |  +--+-----------+
                    +-----+-----+     |
                          |           v
                          |      +----+-----+
                          |      | Main menu |
                          |      +--+--+--+--+
                          |         |  |  |
                          |       1 | 2| 3| 0
                          |         |  |  |  +--> Operator group
                          |         |  |  |         |
                          |         |  |  |      no answer
                          |         |  |  +<--------+
                          |         |  +--> Billing queue
                          |         +-----> Support queue
                          +---------------> Holiday options
                                    |
                         closed hours branch
                                    v
                           After-hours menu
                                    |
                         voicemail or emergency

       Main menu: no input --> limited retry --> assistance/voicemail
                  invalid --> limited retry --> assistance/voicemail

Use the diagram to verify that every digit has a destination, every schedule branch has a prompt, and callers can reach assistance or a defined fallback. Keep the approved diagram aligned with the deployed dialplan.

Map the design to an Asterisk dialplan

The following conceptual example defines the schedule branches, menus, destinations, operator fallback, and finite retry counters. Names are placeholders; adapt them to the queues, ring groups, voicemail boxes, and schedule logic in your system.

[inbound-auto-attendant]
exten => s,1,Answer()
 same => n,Set(INVALID_TRIES=0)
 same => n,Set(TIMEOUT_TRIES=0)
 same => n,Goto(schedule-check,s,1)

[schedule-check]
; HOLIDAY_CLOSED is set by the holiday schedule integration.
exten => s,1,GotoIf($["${HOLIDAY_CLOSED}" = "1"]?holiday-menu,s,1)
 same => n,GotoIfTime(09:00-17:00,mon-fri,*,*,open-hours,s,1)
 same => n,Goto(after-hours-menu,s,1)

[open-hours]
exten => s,1,Playback(aa-open-greeting)
 same => n,Goto(open-menu,s,1)

[open-menu]
exten => s,1,Background(aa-main-menu)
 same => n,WaitExten(5)
exten => 1,1,Goto(sales-queue,s,1)
exten => 2,1,Goto(support-queue,s,1)
exten => 3,1,Goto(billing-queue,s,1)
exten => 0,1,Goto(assistance,s,1)
exten => i,1,Set(INVALID_TRIES=$[${INVALID_TRIES} + 1])
 same => n,GotoIf($[${INVALID_TRIES} >= 2]?assistance,s,1)
 same => n,Playback(aa-invalid)
 same => n,Goto(s,1)
exten => t,1,Set(TIMEOUT_TRIES=$[${TIMEOUT_TRIES} + 1])
 same => n,GotoIf($[${TIMEOUT_TRIES} >= 2]?assistance,s,1)
 same => n,Playback(aa-timeout)
 same => n,Goto(s,1)

[after-hours-menu]
exten => s,1,Playback(aa-after-hours)
 same => n,Background(aa-closed-options)
 same => n,WaitExten(5)
exten => 1,1,Goto(general-voicemail,s,1)
exten => 2,1,Goto(emergency-support,s,1)
exten => 0,1,Goto(assistance,s,1)
exten => i,1,Goto(after-hours-failure,s,1)
exten => t,1,Goto(after-hours-failure,s,1)

[holiday-menu]
exten => s,1,Playback(aa-holiday)
 same => n,Background(aa-holiday-options)
 same => n,WaitExten(5)
exten => 1,1,Goto(general-voicemail,s,1)
exten => 2,1,Goto(emergency-support,s,1)
exten => 0,1,Goto(assistance,s,1)
exten => i,1,Goto(holiday-failure,s,1)
exten => t,1,Goto(holiday-failure,s,1)

[assistance]
exten => s,1,Dial(PJSIP/operator-group,20)
 same => n,Goto(assistance-mailbox,s,1)

[assistance-mailbox]
exten => s,1,Voicemail(assistance@default,u)
 same => n,Hangup()

[after-hours-failure]
exten => s,1,Goto(general-voicemail,s,1)
[holiday-failure]
exten => s,1,Goto(general-voicemail,s,1)

[sales-queue]
exten => s,1,Queue(sales-queue)
 same => n,Goto(assistance-mailbox,s,1)
[support-queue]
exten => s,1,Queue(support-queue)
 same => n,Goto(assistance-mailbox,s,1)
[billing-queue]
exten => s,1,Queue(billing-queue)
 same => n,Goto(assistance-mailbox,s,1)
[general-voicemail]
exten => s,1,VoiceMail(general@default,u)
 same => n,Hangup()
[emergency-support]
exten => s,1,Dial(PJSIP/emergency-support,20)
 same => n,Goto(general-voicemail,s,1)

This example uses separate [open-hours], [after-hours-menu], and [holiday-menu] contexts, so each referenced route is defined. The open menu's i and t extensions increment counters and transfer the caller after two failed attempts. In production, validate application syntax and adapt queue, endpoint, schedule, and voicemail behavior to the Asterisk version and deployment.

Plan prompt recordings for maintenance

Record prompts as a managed set rather than as unrelated audio files.

1. Write the approved script before recording.
2. Use stable, descriptive names such as aa-open-greeting, aa-main-menu, aa-after-hours, and aa-holiday.
3. Store source recordings and deployed files in a controlled location with a change date or version record.
4. Review pronunciation, volume, pauses, and DTMF instructions on representative phones.
5. Replace related prompt and routing changes together.
6. Remove or archive obsolete choices from the active configuration so callers cannot hear options that no longer work.

Normal-hours, after-hours, and holiday prompts should correspond to their respective routing paths. A recording that says “our team is available” must never be used on a route that sends the caller directly to voicemail.

Document menu options

Test before release

Validate the menu from the caller's perspective, not only by checking whether the dialplan loads.

• Call through every inbound route and verify the correct greeting.
• Test every valid digit from representative desk phones, mobile phones, and external trunks where applicable.
• Test no-input timeout and confirm the retry count ends at the documented fallback.
• Enter unsupported digits and verify correction prompts and finite retries.
• Press 0 when the operator is available and when the operator is unavailable.
• Test queue no-answer, voicemail, and transfer failure paths.
• Test open hours, closed hours, weekend periods, and holiday dates.
• Verify DTMF recognition across the relevant SIP, PSTN, and other inbound call methods.
• Confirm that prompts match the destinations callers actually reach.

Review and maintain the design

Menus become inaccurate when departments, staffing, hours, or procedures change. Periodically verify department names, queue coverage, operator availability, business hours, holiday rules, recordings, and fallback destinations.

Use caller feedback, transfer errors, repeated invalid entries, and missed-call patterns to find confusing choices. Frequent wrong-department transfers usually indicate vague labels, too many choices, or insufficient context. Frequent abandonment often indicates a long opening announcement or an overloaded menu. Repeated menu loops indicate missing or unlimited retry handling.

For a structured review, compare the deployed design with the auto attendant design considerations, then update the call-flow diagram, prompts, schedule rules, and dialplan as one change set.

Common troubleshooting cases

Callers reach the wrong department

Rename options using caller-friendly language, reduce the number of top-level choices, and add short descriptions that clarify the purpose of each destination.

Callers abandon before selecting

Shorten the greeting, put essential routing choices first, and move optional promotional or descriptive information to a separate path.

Callers are stuck repeating the menu

Set explicit limits for invalid and timeout retries. After the limit, transfer to a human-assistance destination or voicemail. Make the operator option clear when it is genuinely available.

The greeting gives incorrect availability information

Audit schedule logic and special-date settings. Update the recording and routing together, and establish a pre-holiday review procedure.

Pressing 0 does not help

Check operator coverage, configure a no-answer fallback, and ensure the prompt explains what digit 0 does during the relevant schedule.

Exam-relevant design points

• An auto attendant answers and routes inbound calls using spoken prompts and caller input.
• IVR is the broader interaction system; DTMF is the keypad input used in this design.
• Caller tasks and plain-language labels are more useful than exposing internal organizational structure.
• More than roughly five top-level choices should trigger a complexity review.
• Open-hours, after-hours, and holiday paths need correct prompts and routing.
• Digit 0 needs a defined destination and an unavailable-operator fallback.
• Invalid entries and timeouts require finite retries and a final destination.
• A call-flow diagram should show valid choices, schedules, retries, and failure paths before implementation.