Answering-machine detection (AMD) listens to a call for a few seconds the moment it is picked up, decides whether a real person or a machine answered, and only then hands the call to the bot. Its job is to keep conversation cost and bot capacity from being spent talking to voicemail greetings. This page explains what AMD does, where it sits in the call flow, how it is configured, and how to read the machine-detection numbers you see on a campaign.
AMD is a deployment-wide setting managed by your administrator in system settings, not a per-campaign switch in the campaign wizard. There is no AMD toggle on a campaign. What you control as an operator is how you read its results — see Reading the numbers.

What AMD does

When a contact’s phone is answered, something has to decide very quickly whether the line was picked up by a human (“Hello?”) or by an answering machine (“You’ve reached… please leave a message after the tone”). AMD makes that decision in the first couple of seconds, before the bot says anything.
  • If a human is detected, the call is attached to the bot and the conversation begins as normal.
  • If a machine is detected, the call is closed without ever attaching the bot, so no conversation minutes are spent on a voicemail greeting.
  • If the result is uncertain, the call follows the configured fallback — usually attaching to the bot anyway, so a real person is never dropped by mistake.
The decision is made from the audio alone — how long the greeting is, how many words it contains, how much silence comes first, and whether a voicemail beep tone is heard. It does not use the bot, the Language model (LLM), or the Speech-to-Text (STT) engine; it is a fast, lightweight screen that runs ahead of them.

Where it sits in the call flow

A normal answered call moves from ringing, to attaching the bot, to an in-progress conversation. With AMD enabled, a short screening step is inserted between answer and attach.
ringing → screening → attaching → in-progress

               └─ machine detected → call closed (no bot attached)
If AMD is switched off for the deployment, answered calls skip screening and go straight to attaching the bot. The screening step is brief — about two seconds — so callers feel only a small pause before the bot greets them.

Settings

AMD is tuned once per deployment in system settings. You will not see these controls in the campaign wizard; they are listed here so you understand what each one affects when you ask your administrator to adjust the screen.
SettingTypical defaultWhat it controls
EnabledOffWhether AMD runs at all for the deployment. When off, every answered call attaches the bot directly.
Listen window~2 secondsHow long the screen listens before it must decide. Kept short so callers feel little delay.
Initial-silence threshold~2 secondsSilence at the start of the call that, on its own, suggests a machine rather than a person saying “hello”.
Greeting-length threshold~2 secondsA spoken greeting longer than this leans towards “machine” (voicemail greetings tend to run long).
Maximum greeting words~4 wordsA greeting with more words than this leans towards “machine”.
Beep detectionOnListens for the voicemail beep tone. A beep is a strong machine signal.
Action on machineClose the callWhat to do when a machine is detected — close the call (the usual choice) or attach the bot anyway.
Action on uncertainAttach the botWhat to do when the screen cannot decide — attach the bot (the safe default) or close the call.
Keep the listen window modest. AMD adds its delay to every answered call before the bot speaks, so a long window slows the start of genuine conversations as well as catching machines.
The two “action” settings are the aggressiveness dial. Setting action on machine to attach the bot anyway turns AMD into reporting-only — nothing is suppressed. Setting action on uncertain to close the call makes AMD stricter, but risks dropping real people whose greeting was simply slow or quiet. Change these only with your administrator and only with a clear reason.

Outcomes

Every screened call ends in one of three decisions. Each decision maps to what happens to the call.
DecisionWhat it usually meansWhat happens to the call
HumanA short greeting followed by a pause — a person saying “hello?”.Attached to the bot; the conversation proceeds and is counted as connected.
MachineA voicemail beep, a long greeting, too many greeting words, or a long opening silence.Closed without attaching the bot. Counted as a machine answer on the campaign.
UncertainThe listen window ran out before a confident decision.Follows the action on uncertain setting — normally attached to the bot.
A call closed as a machine is a final outcome for that attempt — the contact is not treated as having had a real conversation. Whether the dialler tries the same contact again depends on your campaign’s retry rules, not on AMD. See Pacing and retries.

Reading the numbers

You do not switch AMD on or off as an operator, but you do see its effect on the campaign detail and monitor page. The relevant figures are:

AMD Machine

A count in the campaign stats grid of how many answered calls were screened out as machines. It only appears once at least one machine has been detected.

Answer Rate

The share of dialled calls that were answered. Machine answers are still “answered” at the carrier level, so AMD shows up as the gap between Answer Rate and how many calls actually became conversations.
Use the AMD Machine count as a health check on the screen, not just as a list-quality figure:
  • A very high machine rate on a list you expected to be mostly mobiles may mean the screen is too aggressive and is closing real people. Ask your administrator to review the action and threshold settings.
  • A near-zero machine rate on a list with many landlines or known voicemail numbers may mean the screen is too lax and machines are slipping through to the bot.
  • A steady, moderate rate that tracks the quality of the contact list is the healthy case.
The machine count is a campaign total. To see which individual attempts were screened out, open the call list on the monitor page and review each contact’s attempt trail. The Dispositions reference explains how machine answers and other automatic outcomes are labelled.

How AMD interacts with other features

AMD does not retry on its own. A machine answer is a finished attempt; whether that contact is dialled again is decided by your campaign’s Max Attempts and Retry on System Dispositions settings. If you want machine answers to be retried later, configure that in Pacing and retries.
Scheduled callbacks are screened by AMD just like first attempts. If a callback reaches a machine, it is closed as a machine answer and its callback status updates accordingly. See Callbacks.
Because a machine-detected call is never attached, the bot never speaks to it — there is no transcript, no post-call analysis, and no LLM or TTS cost for that call. Only calls that pass the screen become bot conversations.
AMD runs before any conversation, so the “redial after a short connect” and “stop redials after a meaningful connect” rules in the wizard only ever apply to calls that actually reached the bot. A machine answer is not a “connect” for those rules.

Safety net

Screening is meant to last only about two seconds. If the dialler stops unexpectedly while a call is mid-screen, a background safeguard closes any call left in the screening state after a short grace period and tears down the underlying call leg first. This means an answered call is never left hanging and quietly burning minutes if something goes wrong during the screen.

Operator notes

  • AMD is a deployment-level setting. If you need it turned on, off, or retuned, raise it with your administrator — it cannot be changed from the campaign wizard.
  • A short pause before the bot greets a caller is normal when AMD is enabled; it is the screen listening.
  • Watch the AMD Machine count alongside Answer Rate to judge both list quality and whether the screen is tuned correctly.
  • If operators report the bot talking over voicemail greetings, or genuine customers being dropped at answer, capture a few example calls and share them with your administrator so the thresholds can be reviewed.

What’s next