Answering Machine Detection for Voice AI: Design Every Call Outcome

Answering machine detection (AMD) is the step that decides whether a person, a voicemail greeting, or an automated phone menu picked up an outbound call, and in a voice AI deployment each of those answers should be its own call state with a defined action, log entry and retry rule.

Many outbound calls end at a voicemail greeting or a phone tree, not a person. When detection lives in a separate dialer bolted in front of the agent, those calls become leftovers someone sorts after the campaign. This guide designs them in, so builders know what to configure and ops leads know what lands in the CRM.

What does answering machine detection actually decide?

It decides who or what answered, early enough for the agent to change what it does on the same call. In Retell, that decision comes from two separate detectors:

• Voicemail detection recognizes a voicemail greeting, then either hangs up or leaves a message.
• IVR detection recognizes an automated phone menu and, with IVR Hangup turned on, ends the call.

Both run on outbound phone calls (and on web calls, which is how you test them). They have no effect on inbound calls, because a person is calling you. Detection runs only during the first 3 minutes after the call connects, and that window is not configurable. Time spent in a phone menu or talking with a person counts toward it.

Two more outcomes sit next to AMD. Phones that screen unknown callers can ask the agent for its name and reason for calling before the person decides to pick up. And some calls never connect at all (no answer, busy, declined, blocked), so detection never runs. A complete design covers all of them.

Why treat voicemail and IVR as call states instead of cleanup?

Because the right action has to happen during the call, and the outcome drives the next attempt. If the agent only learns it reached a machine after the call ends, three things go wrong:

1. The agent pitches its full opener to a greeting, or talks over it.
2. The CRM records a "completed" call that reached nobody.
3. The retry logic cannot tell "left a message an hour ago" from "never got through", so it either over-dials people or gives up on reachable ones.

A call state pairs one detection signal with one action and one disposition.

What call states does an outbound voice agent need?

At minimum, these eight. The detection and logging columns describe documented Retell behavior. The retry column is a rule your team sets in its own dialer or backend.

When should the agent leave a voicemail instead of hanging up?

Leave a message when the message does useful work even if nobody calls back, and hang up when a later attempt would do the job better. Reminders, callback requests and deadlines are good candidates for a message. Sales openers, and anything you would not want a family member or coworker to hear on speaker, usually are not.

Retell gives you two message types:

• Static sentence: fixed text with dynamic variables, such as Hi {{first_name}}, this is the clinic confirming your appointment. Please call us back.
• Prompt: instructions the agent uses to generate the message, such as summarizing why it called and asking for a callback.

Either way, the agent waits for its turn to speak, so the message does not start over the greeting. Watch the defaults: new blank dashboard agents start with voicemail detection on and set to hang up, but existing agents, imported configurations and transfer agents keep their settings, and API-created agents need voicemail_option set explicitly. The API also accepts an optional detection_prompt describing what should count as voicemail.

For message wording, see 5 best voicemail practices when using AI voice agents.

What should the agent do when it reaches a phone tree?

First decide whether the menu is a dead end or a route. If a consumer reminder campaign lands on a company switchboard, the number is probably wrong, so turn on IVR Hangup and log ivr_reached. If the person you need sits behind a menu, as with insurer, supplier or billing lines, navigate it instead and leave IVR Hangup off, since it would end the call on detection.

For navigation, single-prompt and multi-prompt agents use the Press Digit tool, and conversation flow agents use the Press Digit node. A few documented settings matter:

• Pause Detection Delay sets how long the agent waits after the menu pauses before pressing. It defaults to 1,000 ms and accepts 0 to 5,000 ms. Raise it for slow menus.
• The agent can press 0 to 9, * and #, alone or as a sequence such as an extension.
• In a flow, write transitions for success and for failure, such as reaching the right department, the menu repeating three times, the wrong company, or an after-hours or voicemail message.

That last transition matters because of the 3-minute window. A voicemail reached after a long menu, or after someone transfers the call, may not trigger voicemail detection, so the flow has to recognize it itself.

If hang-up on voicemail is on but a call is not hanging up, the system most likely classified the greeting as an IVR. Turn on IVR Hangup to cover it. More on menus at Navigate IVR.

What should be logged for every call outcome?

Log the platform's disconnection reason, and map it to a disposition field your own systems own. Retell provides three layers:

• call_status: registered, not_connected, ongoing, ended or error.
• disconnection_reason: the specific outcome from the table above.
• in_voicemail in call_analysis: whether the call reached a voicemail.

The call_ended webhook carries every call field except call_analysis, which arrives with call_analyzed. Calls that never connect skip call_started but still send both. Webhooks retry up to 3 times without a 2xx within 10 seconds, so deduplicate on event plus call_id.

For richer dispositions, add post-call extraction fields. A selector field works well for a disposition, and Retell's IVR docs include ready-made field definitions such as reached_human, ivr_outcome and ivr_path. Retell does not fill custom extraction fields for calls that did not connect or had no conversation, so build the disposition from disconnection_reason first and use extraction fields to add detail.

Ops leads can track the analytics dashboard's Voicemail Rate metric and chart voicemail_reached calls by agent version, which shows whether a new version sends more calls to voicemail. To push dispositions into a CRM record, see the CRM-to-voice AI workflow.

Who owns the retry rule?

Your dialer or backend does. Retell's docs describe no automatic redial, and state that Retell does not cap how often your agent calls a number. Batch calls have no per-call delay setting and do not check the do-not-call flag; the Create Phone Call API checks it only with honor_internal_dnc: true.

Retell does give you the inputs for a retry policy:

• Contacts record every outbound phone call as a conversation, including voicemail and unanswered calls. A cooldown on last_conversation_timestamp therefore covers dial attempts too.
• List contact conversations returns each call's disconnection reason, so you can count attempts by outcome, for example "two voicemails left this week, stop".
• Do-not-call detection ends the call with user_requested_dnc and marks the contact. Treat that as a permanent stop.

Ask legal which call-frequency rules apply to your industry and region before you set the caps.

Watch one side effect. Carriers can flag a number as spam when it makes many short calls in a short period, and the calls then fail as dial_failed. A campaign that hangs up on every voicemail produces exactly that pattern, so pace it and register your numbers. The outbound phone number checklist covers verification and branded caller ID.

How do you test answering machine detection before launch?

Test every state in the table before the first real campaign. Retell supports two passes:

1. Web call: play a recorded voicemail greeting or menu prompt into a web call. The agent uses the same detection and actions, without reaching a real inbox or menu.
2. Phone call: place real outbound test calls, which also test the carrier audio path.

A short test set:

• A standard voicemail greeting, with leave-a-message on and with hang-up on
• A business after-hours message
• A keypad menu, including one wrong option and one repeated menu
• A phone call screen asking for name and reason
• A person who answers with a long pause
• Each test lands with the expected disconnection_reason and the right disposition in your CRM

Build call states into your outbound campaigns

AMD works best when it is part of the workflow, not a filter in front of it. Retell keeps voicemail detection, IVR handling, call screening and disconnection reasons on the same platform as the agent, so each outcome can carry its own action and log entry. To run these call states across a contact list, start with Retell batch calling.