Auto Attendant Not Working? A Small Business Phone-Menu Test

Executive Summary

When an auto attendant is not working, the first useful question is whether the menu accepted the caller's digit. The second is whether the selected destination received and answered the call. Those questions require different evidence. Twilio documents both collected digits and application handling, while Webex documents reports containing a selected key and destination number. These are examples of available evidence, rather than guarantees about another provider's implementation. ^{[1] [2] [3]}

A greeting that repeats does not establish that input disappeared. Microsoft Teams can return a caller to its menu after an announcement, and Twilio's documentation describes unwanted looping when an application does not direct gathered input appropriately. A correctly selected route can also lead to a mobile that silences calls. Apple and Samsung document incoming-call controls that should be checked at that destination. ^{[4] [1] [5] [6]}

The recommended response is a controlled test with a written call log: verify the advertised option, make calls from independent originating paths, press a valid digit after the prompt, and record acceptance separately from delivery. Repeat another valid option, an unassigned choice, silence, and the after-hours path. Ask the provider which timing behavior is intended. Provider settings differ: Zoom documents 1 to 3 prompt plays with voice navigation disabled ^[7] and 1 to 5 with it enabled ^[7]; Webex documents a configurable no-input wait up to 60 seconds. ^[8] Neither is a universal setting for business phone menus.

Escalate with timestamps and a time zone, originating network and device, dialed number, exact input, observed behavior, and call identifiers where available. Vonage requests dated call examples for its diagnostic process and provides Call ID search in its reporting. Keep a monitored live or voicemail fallback while unresolved paths are investigated. ^{[9] [10]} As of October 9, 2026, autoattendant.io lists $29 per month for the company and a menu with up to nine options; that product description does not disclose its input-transport implementation or establish a diagnostic default. Replacement should follow evidence that a prospective service handles the affected paths, destinations, and fallback requirements.

Introduction and Background

A business phone menu can sound normal while a caller cannot get through. For an owner or office manager, the practical problem is lost access to the team: someone presses the advertised option, hears the greeting again, waits until the call ends, or reaches a different destination. Starting with a router setting or a replacement subscription leaves the essential observation unresolved. What happened between the keypad press and the intended answer?

Dual-tone multi-frequency (DTMF) is the keypad signaling used to communicate telephone digits during a call. Twilio's glossary describes the signals and documents its own method support. This report uses that glossary as a concise reference, rather than expanding the technical history. ^[11] An audible keypad tone at the caller's handset should be recorded as local feedback, not treated as proof that the receiving menu collected and acted on the digit. That diagnostic distinction follows from the separation between event transport, input collection, and application handling in the standards and documentation. ^{[12] [2]}

The report examines a caller-choice menu already operating in a small business. Its proposed workflow separates observations an owner can make from evidence a provider must inspect. Vendor examples establish that relevant controls and reports exist in particular products; they do not establish compatibility between products. The reviewed material supplies no measured failure prevalence for small-business menus and no industry reliability percentage.

The most important discipline is to keep a symptom descriptive. “The caller heard the sales greeting after pressing the service option” is more useful than “DTMF is broken.” “The intended mobile showed no incoming call” is more useful than “the transfer failed.” Account-wide routing logs can provide information absent from a user's ordinary call history, as Zoom explicitly documents. ^[13] A test sheet should preserve both the caller's experience and the provider's eventual explanation without substituting either for the other.

Key Changes: Separate Input Acceptance from Call Delivery

Replace a single pass/fail label with observable outcomes

The change proposed here is a change in troubleshooting process, not a claim of a new telecommunications standard. Divide each test into input acceptance, selected route, and destination outcome. Webex's key-detail reporting distinguishes a pressed key from the terminating destination number; Twilio's call API distinguishes a call identifier from a parent identifier used to relate call legs. These documented distinctions explain why one “connected” entry is insufficient to describe the entire customer experience. ^{[3] [14]}

Consider these outcomes, each a (Hypothetical Example):

• Greeting repeats (Hypothetical Example): A caller presses the service option and hears the original prompt again. Record whether any route-specific announcement occurred first.
• Silence followed by disconnect (Hypothetical Example): A caller waits after pressing a valid key, then the call ends. Record the waiting stage instead of assuming an input timeout.
• Wrong destination answers (Hypothetical Example): A caller requests billing and a colleague handling new orders answers. Record what that colleague heard and which phone rang.
• Correct route, no answer (Hypothetical Example): The requested colleague's mobile rings but is unanswered. Record the successful route and the unanswered destination separately.

A repeated greeting belongs in the first observation category until evidence explains it. Teams documents an announcement destination that returns callers to the menu. Twilio's keypad tutorial also demonstrates why collected input needs subsequent branching logic. Neither example licenses a diagnosis of a particular customer's system. ^{[4] [2]}

Treat acceptance as an evidence label

Use confirmed accepted only when a provider's event record or an unambiguous route-specific outcome supports it. Use apparently accepted when the greeting stops and transfer audio begins but the route remains unverified. Use not confirmed when the prompt repeats or nothing distinguishable happens. These are proposed worksheet labels, not standardized provider status codes.

Sinch's current callback documentation exposes a digit sequence in a menu event. Its menu settings separately describe expected digit count and repeat prompts when valid or expected input is not entered. That shows how received input and acceptable application input can differ in a documented implementation. ^{[15] [16]} An owner should ask for the received sequence, rather than assume that every keypad sound represents an accepted choice.

Identify the waiting stage

Separate waiting for the menu from waiting for a person. Teams documents a queue timeout that applies after a caller remains in a queue; that is a different stage from collecting menu input. ^[4] Record the moment the greeting starts, the keypress, the first identifiable route response, and any destination ringing or answer. The proposed timestamps allow support to examine the stage that actually delayed.

Dialpad documents a Message destination that ignores keypad entries while playing and then returns to its initial menu. That is another reason to identify the current prompt stage before diagnosing ignored input. ^[17]

The owner should also name the ending accurately: a person answered, a voicemail greeting played, an announcement returned to the menu, or the call disconnected. Panasonic distinguishes local answering-machine storage from provider-hosted voicemail. ^[18] A voicemail answer can be a functioning fallback while still being an unsuccessful attempt to reach the intended person. Keep that distinction throughout the test and escalation.

Implementation Considerations and Process Changes

Verify the live menu before investigating transport

First compare the caller's actual greeting with the saved route configuration. Do not assume the digit spoken in an old recording is still assigned. Teams explicitly permits noncontinuous key mappings, so an unassigned digit between working choices is possible. ^[19] A menu that says an option exists while its active configuration does not assign it needs a configuration correction before a transport diagnosis.

The owner can prepare a compact configuration snapshot:

• Greeting: Write the exact advertised choice and the wording heard on the public number.
• Assignment: Record the destination associated with that choice in the active menu.
• Publication: Note whether the current edit was saved, previewed, and activated.
• Schedule: Record business hours, the configured time zone, and any holiday override.
• Destination: Confirm the intended number or group with the person responsible for answering.
• Fallback: Identify what should happen for silence, an invalid choice, and an unanswered destination.

Google Voice documents previewing an auto attendant before making changes active, followed by publication to add or replace the existing version. ^[20] That is a provider-specific example of why a correct draft and a correct live menu are separate checks. Compare both without assuming that every dashboard uses Google's activation process.

Schedule checks are equally concrete. Teams uses the attendant's configured time zone to calculate business hours. Zoom documents business, closed, break, and holiday routing, and Webex applies its after-hours menu to the holiday schedule. ^{[19] [21] [8]} A route appropriate for a closed office may look incorrect when the owner believes the open-hours menu is active. Record the actual business state rather than merely “tested this morning.” Nextiva's documented schedule assignment likewise determines which business-hours or after-hours menu plays; its page uses an older interface, so confirm the equivalent control in the current account. ^[22]

Establish a temporary route that can be observed

Where the provider supports it, test a temporary direct route to a staffed destination without requiring a keypad choice. Teams documents immediate redirection, including redirection after an initial greeting. ^[4] A business should ask its own provider which equivalent control is supported and how to restore the original menu.

Before making the change, nominate a person to monitor it, write down the original setting, and identify the expected voicemail behavior. Test the public number from outside the business. A successful bypass suggests that this particular direct route works during that test; it does not prove every menu option or originating path is healthy.

Do not advertise a fallback as live unless someone will answer it. A voicemail fallback should also be checked by leaving a test message and confirming delivery to the responsible person. Zoom documents holiday routing directly to voicemail, which illustrates a supported alternative in that product rather than an automatic option everywhere. ^[21]

Check the receiving mobile without altering the network

If input appears accepted but the destination does not ring, test the intended mobile directly with its owner's cooperation. Compare the number stored in the routing configuration with the number actually tested. Samsung's support instructions include checking contact information and blocked numbers; Apple directs users to Phone and Focus settings for calls that do not ring. ^{[6] [5]}

The destination check should remain bounded:

• Availability: Ask the recipient to observe the phone during the test.
• Silencing: Review the relevant Focus or Do not disturb setting.
• Blocking: Check whether the test caller or displayed incoming number is blocked.
• Screening: Review unknown-caller treatment using the phone vendor's instructions.
• Voicemail: Note which greeting answers and whether the team receives the message.
• Comparison: Repeat through the business menu after the direct call, then preserve both results.

Apple describes settings that allow unknown contacts to ring and a review of unintentionally blocked contacts. ^[5] Changing those settings should follow the recipient's needs and vendor guidance. Dialpad describes external forwarding as an outgoing call bridged to the caller and documents a company-level enablement control. Verify eligibility and the actual account setting through the provider instead of assuming an external number in a draft creates a live route. ^[23]

A direct mobile answer verifies that direct call only; it does not establish that the provider created or delivered the business-number forwarding leg.

Run the Cross-Carrier Phone-Menu Test

Use the same input across independent paths

The proposed test starts with a known valid option after the spoken prompt finishes. Use different originating networks where possible, not just different handsets sharing the same account or calling application. Record the originating carrier, device type, and whether the call used a mobile dialer, landline, or internet calling application. This is a fault-isolation design, not a claim that any category is more reliable.

Ask the provider whether callers should be able to enter digits during the greeting. Barge-in means accepting input while the prompt is playing; support for that behavior must be confirmed for the configured menu. Google's documentation includes a special announcement that users cannot skip, and Twilio describes timeout timing in relation to nested prompt actions. ^{[20] [1]} These examples establish different prompt behaviors, not a universal rule about early keypad input.

Keep the baseline reproducible:

• Public number: Dial the same advertised business number on each baseline call.
• Active keypad: Enter the digit through the calling device's in-call controls.
• Timing: Wait for the prompt to finish unless the configured behavior being tested says otherwise.
• Input: Enter the advertised choice once, without adding a terminator unless instructed.
• Observation: Record the immediate response before describing the final destination.
• Recipient: Have the expected answerer observe the receiving phone.
• Identifier: Add the provider's call identifier if available.
• Repeat: Repeat a failed path without changing settings between the paired tests.

A household telephone can have line-specific dialing behavior: Panasonic instructs users to select its dialing mode according to telephone line service. ^[24] That is a reason to identify the actual device and consult its instructions, not to tell every caller to change a setting. The business owner should not issue blanket codec, router, or carrier adjustments.

Table 1 is a blank printable test grid. Duplicate its rows for each originating path and business state. Write “not confirmed” if acceptance cannot be observed; leave no ambiguous “failed” entry without a description.

The grid preserves the difference between a keypad event and a reached person. Webex key-detail reports and Vonage segment reporting show examples of provider evidence that can complement those observations. ^{[3] [10]} Fill the worksheet from the call first; add log findings later, with their source identified.

Test valid, invalid, silent, and closed-hours behavior separately

Repeat another assigned choice before concluding that the entire menu fails. Then test an intentionally unassigned digit and a call with no input. These are control tests: their expected results should come from the active configuration, not from an owner's guess about conventional phone menus.

Sinch documents separate match handling and no-match or timeout commands. ^[25] Zoom documents prompt repetition followed by configured routing when callers provide no valid input. ^[7] A repeat, fallback, or disconnect can therefore be intentional in a control test. Record whether the documented action occurred and how the valid-option test differed.

Test the after-hours path as its own case. Confirm the greeting, destination, and fallback for the schedule being exercised. Zoom's time-zone control governs its business-hours setting. ^[21] If a supported administrative override is used, record it and restore it; if not, test at a genuinely closed time. Avoid changing the system clock or improvising unsupported scheduling workarounds.

Interpret Patterns and Escalate with Evidence

Let the pattern narrow the next question

Table 2 maps proposed diagnostic patterns to the next owner action and provider question. These patterns are working hypotheses, not definitive cause labels. A useful next test changes one factor while preserving the others.

A working option and a failing option on the same call path make the option-specific configuration worth checking first. Conversely, an originating-path difference warrants investigation without assigning blame to that caller's device or carrier. The table organizes evidence; it cannot substitute for event and routing logs. Zoom documents account-wide routing detail, and Sinch exposes a menu-input event that can help answer distinct parts of the question. ^{[13] [15]}

Send a packet support can correlate

An escalation should say what was expected, what happened, and which calls demonstrate the difference. Vonage's diagnostic checklist requests dates, times, a time zone, phone numbers, and device types. Its request for recent examples belongs to its call-quality process, but it illustrates the value of identifiable samples. ^[9]

Include the following fields in a secure support submission:

• Business number: The number actually dialed, including country context.
• Timestamp: The call's date, local time, and explicitly named time zone.
• Origin: Calling number, originating network, device, and calling application if relevant.
• State: Open, closed, holiday, or temporary override, plus recent configuration changes.
• Exact input: The digit sequence, its timing, and any terminator used.
• Expected route: The intended person, number, group, or voicemail.
• Observed sequence: Greeting, response to input, transfer audio, ringing, answer, repeat, or disconnect.
• Identifiers: Call ID and related leg identifiers where the provider supplies them.
• Comparison: A successful call made under comparable conditions.
• Requested answer: Whether input arrived, which branch ran, and what happened to the destination leg.

Vonage provides Call ID search and reports encompassing call segments. Twilio documents a unique CallSid and a parent identifier relating another leg. ^{[10] [14]} Aircall documents copying a call ID from Call Details and says its call UUIDs expire after 7 days, so follow its support process promptly where that service is used. ^[26] Universally unique identifier (UUID) is the expanded name; another provider may use a different identifier.

Those names belong to their respective systems. Ask the business provider for its own identifiers instead of assuming it uses either format.

Minimize customer data. Prefer controlled test calls over collecting customer conversations, submit detailed numbers through the provider's approved support channel, and retain only what the diagnostic process needs. Aircall's Input IVR documentation describes a setting that prevents the collected input from being stored or displayed. That is a product-specific data control, not a general permission to capture customer information. ^[27] Recordings should follow the organization's applicable consent process. This report does not recommend recording public callers merely to establish that a keypad choice is being ignored.

Appendix for the provider

An interactive voice response (IVR) application handles caller input and response logic. The owner observes behavior; the provider verifies event transport and application handling. Twilio's glossary documents support boundaries for its input implementation, while RFC 4733 specifies event carriage in Real-time Transport Protocol (RTP) packets. ^{[11] [12]} That is a technical reference for the provider, not an instruction for the owner to change Session Initiation Protocol (SIP) settings.

The escalation questions should cover these stages:

• Transport: Which telephone-event method was negotiated and delivered on the relevant path?
• Collection: What digits arrived, and did expected length or termination rules affect collection?
• Timing: When did input become eligible, and which timeout expired?
• Application: Which matching, no-match, or no-input branch executed?
• Destination: Which target and outgoing leg were selected, and what outcome was recorded?
• Retest: What was changed, and which paired calls will verify the result?

Sinch documents expected digit count and commands for no match or timeout. ^{[16] [25]} Aircall explicitly documents that its Input IVR widget alone cannot route calls. ^[27] The provider should explain those controls in the customer's actual implementation, then give an approved retest procedure. The owner should not blindly alter codecs, gateways, routers, or carrier settings.

Data Analysis and Evidence

Measure the named test sample

The useful numerical result is successful valid-option tests divided by attempted valid-option tests, with unresolved cases reported alongside it. Define success before testing: the intended route is reached and the planned answer outcome occurs. Keep input acceptance and destination success as separate tallies, so a voicemail answer is not silently substituted for a human answer.

This matters because provider metrics have different meanings. Zoom defines its classic Call Connected event by the party in the To column answering. ^[13] A dashboard label must be interpreted before it becomes a business performance measure.

(Hypothetical Example): a business records 20 attempted valid-option tests. Fourteen reach the intended person, four have confirmed unsuccessful destination outcomes, and two remain unresolved. The observed human-answer result is 14 / 20 = 70%, calculated from that invented sample. The unresolved share is 2 / 20 = 10%. These are author calculations illustrating the worksheet, not measured product reliability, an industry benchmark, or a forecast of customer experience.

Keep invalid-choice and no-input controls outside that denominator. Describe their results separately against the expected configuration. Also report changes between test runs: a routing correction, a provider adjustment, a destination setting, or a revised schedule. Combining pre-change and post-change calls hides the question the retest is supposed to resolve.

Track time to identifiable route response separately from time to human answer. The first proposed measure starts at the keypress; the second includes subsequent waiting for the team. Aircall documents active-conversation duration separately from other call-history timing and includes a field identifying who ended a call. These are additional provider-specific checks for the waiting stage and disconnect observation. ^[28] Preserve the raw timestamps when acceptance remains uncertain. Do not manufacture a connection-time figure from a caller's recollection that “it took ages.”

Compare documented controls, not presumed defaults

Table 3 gives current documented examples relevant to the test. It is a limited comparison of control descriptions, not a compatibility certification or a complete vendor-selection table.

Aircall's different standard and input widgets illustrate why values must be attached to the named control: 3 seconds after a prompt and 5 seconds per digit describe different stages, not contradictory performance measurements. ^{[29] [27]}

The comparison illustrates why copying a timeout or retry count from another vendor's help page is a weak diagnostic step. Numeric limits describe those products' controls, not recommended settings for all businesses. For external forwarding, Zoom also documents a direct-number prerequisite on the associated auto receptionist. ^[7] A route must be valid under its own provider's requirements before its destination outcome can be meaningfully assessed.

The evidence supports a testable process. It does not supply a trustworthy ranking of carriers or handsets by menu-input reliability. Use the named sample, identify missing observations, and preserve successful comparison calls alongside unsuccessful ones.

Implications and Future Directions

Keep the fallback monitored and reversible

A fallback is useful only when its answer and message-delivery behavior are checked. Assign a named person to monitor it, test it from an outside line, and record the condition for returning to the menu. Keep the diagnostic changes reversible so subsequent tests compare known states.

Do not infer from an answered call that someone handled the customer's request. Panasonic distinguishes a telephone's local answering machine from provider voicemail. ^[18] Record the actual destination greeting or person and verify the resulting message is available to the team.

Accessibility should be checked separately from ordinary keypad tests. Ask the provider what supported alternatives are available when a caller cannot use the menu, then test those paths against the business's stated needs. A live or monitored message route should not require the very keypad action currently under investigation. Public emergency calls belong on the applicable public emergency service, outside business diagnostics; never place an emergency test call to evaluate a commercial menu.

Retest before deciding to switch providers

After a configuration or provider change, rerun the same originating paths, valid choices, business states, and fallback tests. Mark the change and its time on the worksheet. A single successful call is a useful observation, but it does not close a case that previously varied by option, origin, or schedule.

If a service cannot explain accepted digits, selected routes, or related call legs, ask what alternative diagnostic evidence it provides. Vonage documents segmented reporting, and Sinch documents identifiers for individual call legs. ^{[10] [15]} Those are examples of traceability, not features promised for every small-business plan.

A vendor change becomes reasonable when the documented needs and observed test results show an unresolved mismatch. Before migrating, test the prospective service with the same troublesome origin paths and intended mobiles. Confirm activation, after-hours behavior, invalid/no-input outcomes, and monitored fallback. Keep number migration and full outage planning in a separate project. This report's decision is narrower: restore a working contact path, obtain an explanation that fits the evidence, and verify the correction.

Frequently Asked Questions (FAQs)

Why is “press 1” not working on the phone menu?

The advertised digit may be unassigned, the menu may not collect the input, the application may handle it differently than expected, or the destination may not answer. Teams permits gaps in assigned keys, while Twilio's tutorial separates gathering input from branching call logic. ^{[19] [2]} Verify the live choice, then record acceptance and destination behavior separately.

Does hearing a keypad tone prove the menu received it?

No. Treat the sound as local feedback. Twilio's glossary distinguishes forwarding tones from detecting and reacting to them, and RFC 4733 describes telephone-event carriage separately. ^{[11] [12]} The useful confirmation is the receiving provider's event evidence or an unambiguous route-specific outcome, not the caller's audible tone alone.

Why does the menu accept a choice but not transfer the call?

Ask which branch ran and which outgoing destination was attempted. External forwarding may have product-specific prerequisites: Zoom documents a direct-number requirement for its associated auto receptionist. ^[7] If the intended mobile was selected, check direct-call behavior and incoming-call controls rather than repeatedly changing the greeting.

What if the auto attendant is not ringing a mobile phone?

Compare a direct call with the business-menu call while the recipient watches the phone. Samsung documents blocked-number and Do not disturb checks, and Apple documents Phone and Focus checks. ^{[6] [5]} Send the provider both call examples if the direct path works but the business path does not.

How should a small business test an auto attendant?

Use the printable grid, independent originating paths, a valid choice after the prompt, another valid choice, an invalid choice, silence, and the closed-hours route. Preserve timestamps and call IDs where available. Vonage's diagnostic checklist and Call ID report illustrate the kinds of records support can use. ^{[9] [10]} Reuse the same test conditions after changes.

Conclusion

A phone-menu problem should be reduced to observable stages: the caller entered a choice, the menu collected and interpreted input, a route was selected, and a destination produced an outcome. The recommended worksheet makes uncertainty explicit instead of turning every repeat, wait, or unanswered mobile into the same failure label.

Start with the live greeting, assigned choices, publication state, schedule, and intended destinations. Establish a monitored fallback when callers cannot reliably reach the team. Then compare unchanged tests across independent origins and distinguish valid-option tests from invalid-choice and no-input controls. Keep local keypad feedback separate from confirmed input acceptance.

Escalate with identifiable call examples and a precise question: what input arrived, which branch executed, and what happened to the intended destination? The owner supplies the observations; the provider supplies transport, event, and routing evidence. Technical changes should follow the provider's approved process.

Finally, measure only the named test sample. Preserve unresolved cases, record changes, and distinguish reaching the intended route from a person answering. Retest the same conditions after a correction. If replacing the provider becomes necessary, use those same conditions to evaluate the replacement before committing. The practical endpoint is a working, monitored contact path and an explanation supported by repeatable calls, rather than a diagnosis inferred from the sound of a keypad or the appearance of one dashboard entry.