VMware ESXi and vSphere Cluster Management

What Is an Automated Attendant in Asterisk?

Learn how an Asterisk automated attendant answers calls, collects DTMF menu choices, routes callers, handles voicemail, and differs from an IVR.

An automated attendant is a telephone menu that answers incoming calls and directs callers to the appropriate destination without requiring a live receptionist or operator for every call. In Asterisk, it is commonly implemented with a greeting, menu prompt, DTMF input, and call-routing logic.

The main purpose is call routing and self-service navigation. A caller hears an announcement, presses a telephone keypad key, and is sent to an extension, department, voicemail flow, announcement, submenu, or operator.

Key Terms

• Asterisk: A telephony platform that can provide PBX functions, including inbound call routing and keypad-driven menus.
• Extension: An internal telephone endpoint or dialing destination.
• DTMF: Dual-tone multi-frequency signaling generated when a caller presses a telephone keypad button.
• Menu prompt: A recorded or synthesized announcement explaining the available choices.
• Call routing: The decision and action that sends a call to a particular destination.
• Timeout: The action taken when the caller does not enter a selection within the allowed time.
• Invalid entry: A keypad input that is not assigned to an available menu action.

What an Automated Attendant Does

A typical caller experience is simple:

1. The caller dials the company number or another inbound number.
2. Asterisk answers or connects the call to the automated-attendant route.
3. The system plays a greeting, such as “Thank you for calling Example Company.”
4. A menu prompt tells the caller which keys to press.
5. The caller presses a touch-tone key.
6. Asterisk recognizes the DTMF digit and executes the routing action assigned to it.
7. The caller reaches the selected extension, voicemail destination, announcement, submenu, or fallback route.

An attendant does not need to provide complex answers to be useful. Its essential job is to make the correct destination easy to reach while reducing routine work for a receptionist.

How an Automated Attendant Works in Asterisk

The exact implementation depends on the dialplan and surrounding PBX configuration, but the logical flow is consistent:

1. Incoming destination: The telephone provider or trunk sends the call to an inbound number, often called a DID.
2. Greeting playback: Asterisk plays a recorded prompt or another configured message.
3. Digit collection: The system waits for DTMF input from the caller’s keypad.
4. Digit interpretation: Asterisk compares the entered digit with the available menu choices.
5. Action selection: The matching digit is associated with a destination or another call-handling operation.
6. Fallback handling: No-input, invalid-input, unavailable-destination, and repeated-failure conditions receive defined treatment.

For example, a prompt might say: “Press 1 for Sales, 2 for Support, 3 for our hours and location, or 0 for the operator.” The configuration must match those words exactly. If the recording says that key 2 reaches Support but the dialplan sends key 2 to Billing, callers will experience the system as broken even though DTMF collection works.

Conceptual Asterisk Call Flow

incoming number
  -> greeting and menu prompt
  -> collect DTMF digit
  -> map digit to action
       1 -> transfer to Sales extension or ring group
       2 -> enter Support submenu
       3 -> play hours and location announcement
       4 -> send caller to voicemail deposit flow
       0 -> transfer to operator
       # -> repeat menu, if announced
  -> no input or invalid input handling
  -> retry limit and final fallback

This is a conceptual model rather than a complete production dialplan. A real deployment also needs valid contexts, endpoints, permissions, time conditions, voicemail settings, and destination-failure handling.

Menu Structure and Caller Navigation

A well-designed attendant usually starts with a short main menu. Each choice can route directly to a destination or open a submenu, which is a secondary menu containing more specific choices.

For example, a main menu can offer Sales, Support, Information, and Operator. Selecting Support can open a submenu with Technical Support, Billing Support, and Return to the Main Menu.

Prompt Design

• State the available choices clearly and in the same order as the keypad assignments.
• Use caller-oriented names such as “technical support” instead of internal team names that callers may not recognize.
• Keep the prompt concise and avoid presenting too many choices at one level.
• Tell callers how to reach an operator when assistance is available.
• Announce repeat and return options when they are supported.

No Input and Invalid Input

If a caller does not press a key, the attendant encounters a timeout. It can replay the menu, provide a reminder, or send the caller to an operator or general mailbox.

If the caller presses an unsupported key, the system should play an invalid-selection message and explain the choices again. Both no-input and invalid-input paths should have a bounded retry policy. Replaying a menu forever is frustrating and can trap callers who are using a device that does not send DTMF reliably.

A practical policy might repeat the menu twice, then offer an operator or general voicemail. If no human destination exists, the system should provide a clear final message and disconnect gracefully.

Common Menu Selections and Destinations

Basic Company Main Menu Example

1. An incoming caller hears the company greeting.
2. Pressing 1 routes to Sales.
3. Pressing 2 routes to Support.
4. Pressing 3 plays the business address and hours.
5. Pressing 0 routes to a receptionist or general operator.

Department Submenu Example

After pressing 2 for Support, the caller might hear: “Press 1 for technical support, 2 for billing support, 9 to return to the main menu, or 0 for the operator.” Each digit then has its own routing rule. A submenu should always have a clear exit, such as a return-to-main-menu key or an operator option.

Voicemail Access in an Attendant Menu

Voicemail records messages when a person does not answer or when the caller is intentionally sent to a mailbox. An attendant can route an external caller to leave a message for an employee or department.

Asterisk commonly uses the VoiceMailMain application for mailbox owners who want to access and manage their voicemail. This is different from voicemail deposit:

• Voicemail deposit: The caller records a message for a mailbox, usually after an extension is unavailable or when a menu explicitly offers voicemail.
• VoiceMailMain access: A mailbox owner enters the voicemail-management flow to authenticate, listen to messages, delete or save them, and manage other mailbox functions according to the configured options.

An internal employee option might route to VoiceMailMain, while an external “leave a message” option routes to a particular mailbox or a general message-taking flow. These are separate destinations and should not be confused during configuration or testing.

voicemail option for callers
  -> select the intended mailbox
  -> record and submit a message

internal message-access option
  -> VoiceMailMain
  -> authenticate as mailbox owner
  -> review and manage messages

Automated Attendant Versus IVR

The terms are sometimes used loosely, but they describe different levels of interaction.

An automated attendant primarily routes callers according to menu selections. For example, key 1 transfers to Sales and key 2 transfers to Support.

An Interactive Voice Response (IVR) commonly accepts caller input, applies business logic, queries information sources such as databases or external services, and supplies a result. An IVR might ask for an account number, look up the account’s status, and read that status to the caller instead of merely transferring the call.

Asterisk can implement both simple attendants and advanced IVR applications. The distinction is about the behavior and complexity of the call flow, not necessarily a particular product label.

Design Considerations

• Keep the top level brief: Organize choices around caller goals and avoid an overly long list.
• Use intuitive assignments: Keep key meanings consistent across related menus.
• Write concise recordings: Long prompts increase abandonment and make navigation harder, especially for mobile callers.
• Plan error behavior: Define what happens after no response, an invalid key, and repeated failures.
• Plan operating schedules: Decide how business-hours, after-hours, holiday, and emergency calls are handled where applicable.
• Validate destinations: Confirm that extensions, queues, ring groups, mailboxes, announcements, and submenus exist and are maintained.
• Provide safe fallbacks: Include an operator, general mailbox, or another useful path when a department or extension is unavailable.
• Support different callers: Account for mobile devices, accessibility needs, callers with limited hearing or dexterity, and callers who do not know the correct department.
• Test every branch: Verify recordings, DTMF recognition, transfers, voicemail deposit, VoiceMailMain access, time conditions, and failure paths before deployment.

Menu Error and Timeout Behavior

Conceptual Routing Examples

The following pseudocode illustrates the relationship between a keypress and a destination. It is not a complete copy-and-paste dialplan; actual Asterisk syntax and application arguments depend on the deployment.

inbound-main:
  play greeting-and-menu
  collect one DTMF digit

  if digit is 1: transfer to sales-extension
  if digit is 2: go to support-submenu
  if digit is 3: play hours-and-location
  if digit is 4: begin voicemail deposit for general-mailbox
  if digit is 9: repeat inbound-main
  if digit is 0: transfer to operator
  if no digit: retry or use fallback
  if digit is invalid: play invalid message, then retry

support-submenu:
  play support-menu
  1 -> transfer to technical-support
  2 -> transfer to billing-support
  9 -> return to inbound-main
  0 -> transfer to operator
  timeout or invalid -> retry with a limit

For a production dialplan, map every announced key to an intentional action. Also define what happens if the target does not answer, is busy, is unavailable, or forwards elsewhere.

Troubleshooting Common Problems

Callers Hear the Menu but Selections Do Not Work

Likely causes: DTMF signaling is not being recognized, the entered digit has no menu mapping, or the endpoint and inbound call path use incompatible DTMF handling.

• Verify DTMF detection along the inbound call path.
• Confirm that every announced key has a configured action.
• Test from the phone types, mobile networks, and trunks that callers commonly use.

Callers Reach the Wrong Department or Extension

Likely causes: The key-to-destination mapping is wrong, the recording no longer matches the configuration, or a submenu points to the wrong target.

• Compare each prompt statement with the current routing map.
• Test every main-menu and submenu branch.
• Review recent extension, department, or ring-group changes.

The Menu Loops Indefinitely

Likely causes: No-input or invalid-input handling returns to the menu without an attempt limit, or a submenu has no exit route.

• Set a bounded retry policy.
• Define a final operator, general-mailbox, or graceful-disconnect fallback.
• Validate every submenu return path.

Calls Are Sent to Voicemail Unexpectedly

Likely causes: The target extension is unavailable or forwarding, the attendant intentionally routes to voicemail, or business-hours logic applies after-hours treatment.

• Confirm extension reachability and forwarding behavior.
• Review the intended action for the selected menu option.
• Test both business-hours and after-hours conditions.

Callers Cannot Find the Right Option

Likely causes: The menu has too many choices, uses internal terminology, or hides important options in submenus.

• Simplify the top-level menu.
• Use names callers understand.
• Provide an operator or general-help path.

Exam-Relevant Notes

• An automated attendant is primarily a menu-based call-routing feature.
• DTMF digits are the touch-tone input used to select menu options.
• A submenu is a secondary menu reached from another menu.
• A timeout handles the absence of keypad input; an invalid-entry path handles an unsupported digit.
• Voicemail deposit and VoiceMailMain access serve different purposes.
• An IVR generally goes beyond fixed routing by processing input, applying business logic, or consulting external information.
• A usable attendant needs retry limits, valid destinations, fallback paths, and testing of every branch.

Related learning: automated attendant concepts in Asterisk.