When AMD marks live people as answering machines: how to diagnose it

If your agents complain that real customers are vanishing before they can talk to them, your dialer is probably hanging up on live people it decided were answering machines. That is an AMD false positive, and it quietly burns leads. The good news is that VICIdial records every detection decision, so you can prove it is happening and then tune it down.

What AMD actually does

AMD (answering machine detection) stands for Answering Machine Detection. When a call connects, Asterisk listens to the first few seconds of audio and tries to decide whether a human just said hello or a voicemail greeting is playing. VICIdial wraps this in a script called ViciAMD. A short, choppy greeting reads as human; a long, smooth, uninterrupted stream of speech reads as a machine. When AMD calls it a machine, the call is dispositioned away from an agent and may get a voicemail drop instead of a live conversation.

The catch is that a chatty person who answers with a long sentence, or a noisy line, can look exactly like a recording. That is where false positives come from.

Reading the AMD Log Report

The AMD Log Report shows the result of the built-in detection function for every call your dialers placed. Each row tells you what AMD decided and lets you tie that decision back to the lead. The statuses you care about are:

• AA — answering machine. AMD heard what it believes is a recording, and the call was handled as a machine.
• AMD — the call was sent through detection and ended up on the machine path. If you see this on numbers a human clearly answered, that is your smoking gun.
• HUMAN or a live disposition — AMD let the call through to an agent. Plenty of these is what you want.

To find false positives, pull a day of AA and AMD results and spot-check the recordings. If you keep hearing real people answering on calls that were marked as machines, the detection is too aggressive.

How a greeting becomes a verdict

flowchart TD
  A[Call answered] --> B[viciamd listens to first seconds]
  B --> C{Long smooth speech}
  C -->|Yes| D[Marked AA machine]
  C -->|No| E[Short choppy greeting]
  E --> F[Marked HUMAN sent to agent]
  D --> G{Recording shows a real person}
  G -->|Yes| H[False positive lower sensitivity]
  G -->|No| I[Correct detection]

If the recording in step G turns out to be a live customer, you have a tuning problem, not a carrier problem.

Turning sensitivity down

AMD sensitivity is set per campaign. The detection has thresholds for how long silence and speech must run before it commits to a decision. Making it less eager means it waits a beat longer and gives short human greetings room to register. Practical moves:

• Loosen the speech-length threshold so a talkative hello is not instantly read as a recording.
• Change one variable at a time, then re-pull the AMD Log the next day and compare your AA rate.
• If a market or list is consistently noisy, consider disabling AMD for that campaign rather than fighting the thresholds.

Watch out for going too far the other way: loosen it too much and real machines start reaching your agents, which wastes talk time. Tune in small steps and measure.

Where to go next

For a field-by-field walkthrough of the report itself, see how to read the AMD Log Report. And for the full first-response checklist when something outbound looks wrong, start with the VICIdial troubleshooting playbook.

If you would rather tune campaigns than maintain Asterisk, VICIfast runs a managed, hardened VICIdial box that is live in under 40 seconds. See our plans and pricing.