AMD tuning in Vicidial: the narrow middle almost everyone misses

Almost every Vicidial operator who tunes Answering Machine Detection believes they are dialing in a number. Pick a drop_call_seconds, watch the dashboard, nudge it, done. The reality is that AMD tuning has two opposite failure modes, and the band of settings that lands between them is narrow, moving, and almost never where you parked it.

Stock AMD in Vicidial is Asterisk’s app_amd, configured in amd.conf. It listens to the first few seconds of audio, measures silence and word timing, and sets AMDSTATUS to HUMAN, MACHINE, or NOTSURE. The Vicidial layer wraps that with drop_call_seconds and amd_send_message (HANGUP or CONTINUE). It is a timing heuristic, which is exactly why it has two cliffs instead of one sweet spot.

Failure mode one: too aggressive

Set amd_send_message=HANGUP with drop_call_seconds=4–5 and your accuracy on paper looks excellent — 88–94% of dispositions match what they should be. The dialer drops machines fast, agents connect to humans quickly, and every surface metric says you nailed it.

Underneath, you are hanging up on 2–4% of valid human contacts. A real person says “hello”, pauses to figure out who is calling, and the four-second timer decides that pause is a machine’s greeting gap. Click. Gone. And here is the part that makes it dangerous instead of merely bad: those drops never appear in your abandon rate.

AMD-dropped calls are not counted as FCC/FTC abandons. So your compliance dashboard shows a clean, comfortable abandon number while your actual human-facing abandon — the people who answered and got cut off — is closer to 5–6%. The metric you trust is reassuring you about a problem it structurally cannot see. Conversions drift down week over week and nothing on the dashboard explains why, because the dashboard is healthy by design.

Failure mode two: too soft

Overcorrect — amd_send_message=CONTINUE or drop_call_seconds=10+ — and accuracy collapses to 70–78%. Now 12–18% of your calls waste 6–10 seconds sitting on a machine before anyone acts, because you told the system to wait for near-certainty before dropping.

That waste compounds in ways the surface metrics hide:

• Dial ratios inflate artificially — the system counts machines it is babysitting as active calls, so a “healthy” 3× dial ratio is partly fictional.
• Agents idle 15+ seconds between real human connects despite that 3× ratio looking fine on the report.
• Trunk channels stay occupied on confirmed machines, throttling how many real numbers you can reach per hour.

The too-soft config feels “safe” because you stop worrying about dropping humans. But you trade that safety for agent idle time and a dial ratio that lies to you. Both cliffs cost money; they just bill it to different lines.

The narrow middle — and why it moves

Here is the uncomfortable truth that no single forum post about “the best amd.conf settings” will tell you: the correct configuration is context-dependent, and the context changes during the same shift.

• Fresh teleforwarded leads at 10am answer quickly and cleanly — they tolerate a tighter drop_call_seconds=6.
• Aged leads (over 60 days) at 7pm answer slower, land on more voicemail, and route through different carriers — they need 8–9 to preserve human connects.

Use the 10am setting on the 7pm list and you slide into failure mode one. Use the 7pm setting all morning and you drift into failure mode two. There is no single right number. It drifts with list age, time of day, and carrier — and the narrow middle is wide enough to hit only if you keep moving with it. Most operators set it once during onboarding and never touch it again, which guarantees they are mistuned for most of every day.

The 50-call test — do this today

You do not need a consultant or a spreadsheet model to find out which cliff you are standing on. You need ten minutes and your own recordings.

• Pull 50 random calls your system dispositioned as AMD (machine) — random, from a real production list, not a hand-picked sample.
• Listen to the first 8–10 seconds of each recording.
• Count how many are actually live humans who were dropped.

The threshold is brutal and simple: if more than 3 of 50 are real humans, your AMD is eating valid connects. Three out of fifty is 6% — and remember, none of those show up in your abandon rate, so this is the only way you will ever see them. Run it on this morning’s calls before you read further into any tuning guide. The number you get is more honest than any dashboard.

If you want the parameter-by-parameter reference for what each knob actually does, the amd.conf cheat sheet breaks it down, and this piece on dialers hanging up on real people walks through the human-drop problem in depth.

The punchline: you are on a treadmill

Even if you pass the 50-call test today, you will fail it next week when your list ages, the dial window shifts, or a carrier changes how it presents answer audio. Tuning amd.conf is not a setup task you finish; it is a treadmill you run forever. And no matter how well you run it, you are still trading accuracy against human-drops, because timing-based AMD can only ever guess from silence and word gaps. The trade-off is built into the method.

Acoustic AI AMD removes the trade-off instead of re-balancing it. AMDY is an AI model that classifies the acoustic signature of the answer audio — the actual sound of the pickup, not a transcript — and returns a decision in under 200ms at 99% accuracy. There are no timing thresholds, so there is nothing to re-tune as your lists drift. It also sees carrier false-answers (FAS) that stock timing-based AMD structurally cannot, the calls where the carrier returns answer supervision on a number that never actually picked up.

The scale of that gap is not subtle. Across roughly 2.3 billion answered calls a month, the network breaks down to about 12.5% live humans, 73% machines, and 14% carrier false-answers. A timing heuristic was never built to separate that 14% from a real human or a real machine — it just guesses, and every guess is a re-tune waiting to happen. See the full breakdown in default AMD vs AMDY, and the hub Vicidial AMD guide for how it installs.

One note on compliance: better AMD supports your TCPA and abandon-rate posture, but it is not legal advice and does not replace your own dialing policy. Pair accurate detection with the rules your operation already follows.

FAQ

What is drop_call_seconds in Vicidial?

drop_call_seconds is the Vicidial campaign setting that tells the dialer how many seconds of analysis to allow before it acts on the AMD result and drops a call it believes is a machine. It sits on top of Asterisk app_amd (configured in amd.conf), which produces the AMDSTATUS of HUMAN, MACHINE, or NOTSURE. A low value (4-5) drops faster and risks cutting off real people; a high value (10+) wastes agent and trunk time sitting on confirmed machines.

Why does my FCC abandon rate look fine but conversions are dropping?

Because AMD-dropped calls are not counted as abandons. When your AMD is too aggressive it silently hangs up on some live humans, but those drops never show up in your abandon metric, so the dashboard looks healthy. Meanwhile your real human-contact rate falls and conversions decline. The abandon number reassures you while the AMD quietly eats valid connects. Run the 50-call test to see the real human-drop rate.

How do I know if my AMD is dropping real people?

Pull 50 random calls your system dispositioned as AMD (machine). Listen to the first 8-10 seconds of each recording and count how many are actually live humans. If more than 3 of 50 are real people, your AMD is too aggressive and eating valid contacts. Do this today on a real list, not a test list.

What is the ideal amd.conf setting?

There is not one. The correct configuration drifts with list age, time of day, and carrier. Fresh teleforwarded leads at 10am tolerate a tighter drop_call_seconds of 6; aged leads over 60 days at 7pm need 8-9 to preserve human connects. Any single static setting is right for one context and wrong for the rest. That drift is the whole point, and it is why heuristic AMD is a treadmill.

Does AMDY need tuning?

No. AMDY is an AI model that classifies the acoustic signature of the answer audio and returns a decision in under 200ms at 99% accuracy. There are no timing thresholds to tune, no amd.conf to re-balance, and it catches carrier false-answers that stock timing-based AMD misses. You keep your carrier and stop re-tuning forever.