Vicidial AMD Not Working? 9 Causes and the Fix for Each

When Vicidial operators say "AMD is not working," they mean one of four things: real people are being dropped as machines, voicemails are reaching agents, everything comes back NOTSURE, or detection takes so long the human already hung up. The symptom is easy to see in your reports. The cause almost never is.

That is because Vicidial's detection is two systems stacked on each other — Asterisk's app_amd producing the verdict, and Vicidial's campaign settings deciding what to do with it — and the failure is just as often in the second layer, the carrier path, or the list itself as in amd.conf.

This guide walks the nine failure patterns we see most on production Vicidial servers, in the order you should check them.

The 9 causes at a glance

#	Symptom	Layer	First fix to try
1	Humans marked as machines	amd.conf	Raise after_greeting_silence, maximum_number_of_words
2	Voicemails passed to agents	amd.conf	Lower maximum_number_of_words toward 3–4
3	Everything NOTSURE	amd.conf	Check total_analysis_time vs maximum_word_length
4	Drops concentrated on one carrier	Carrier	Check false-answer supervision on that route
5	Detection starts too late	Dial plan	Start AMD before Answer(), check detect loops
6	Verdict ignored, all calls dial on	Vicidial	Set amd_send_message, check campaign AMD settings
7	Human drops invisible in stats	Reporting	Run the 50-call recording audit
8	Accurate at 10am, dead by evening	List	Split tuning by list age and hour
9	AMD does nothing after an upgrade	Build	Confirm app_amd loaded and amd.conf actually read

Causes 1–3: the verdict itself is wrong

1. Humans marked as machines

The classic signature: your drop rate looks great, agents are "productive," but conversions sag and nobody can say why. Three thresholds working together cause it. maximum_number_of_words at the default of 3 classifies any answer longer than three words as a machine — and real receptionists answer with six to ten. after_greeting_silence at 800 ms fires the machine verdict the instant a human pauses to think. And initial_silence below 1000 ms drops cell-phone users whose handset latency delays first audio past the window.

Fix: set maximum_number_of_words=5 (6 if your lists include business lines), leave after_greeting_silence at 800 ms or slightly above, and never run initial_silence under 1500 ms on consumer lists.

2. Voicemails passed to agents

The mirror image. Agents sit through 20-second voicemail greetings because detection said HUMAN. Two amd.conf causes: maximum_number_of_words raised so high to protect humans that even scripted greetings score as speech, and greeting set long enough that a voicemail's opening line fits inside the "human greeting" window.

Fix: bring maximum_number_of_words back to 4 and pull greeting to 1500 ms or below. If machines still leak through on one carrier specifically, that is false-answer supervision (FAS), and the fix is acoustic detection or a different route — not more threshold surgery.

3. Everything comes back NOTSURE

NOTSURE is not a fuzzy verdict; it is a timeout. Asterisk ran total_analysis_time (default 5000 ms) without any rule firing. Either the config is self-contradictory — maximum_word_length set longer than the analysis window, so the word-count rule can never complete — or clean audio is not reaching Asterisk during the window at all: a codec mismatch, a carrier that bridges audio late, or detection starting before the far end answers.

Fix: first check the arithmetic — the greeting thresholds must fit inside total_analysis_time. If the config is sane, record two or three NOTSURE calls and listen to what Asterisk actually heard. Silence points at dial-plan timing, noise points at the carrier path.

Causes 4–6: the path around amd.conf

4. Failures clustered on one carrier

Sort your AMD dispositions by carrier and look for skew. When one route drops humans at triple the rate of the others, the thresholds are not the problem — the route is. The main mechanism is false-answer supervision: the carrier returns answer billing on a number that never truly picked up and plays its own announcement, which timing AMD scores as a human greeting.

Fix: no amd.conf edit fixes a carrier announcement, because the audio genuinely contains speech — it is just not your prospect. Move the affected lists off the route, or detect acoustically.

5. Detection starts too late

Humans decide within the first second of pickup. If your dial plan starts AMD only after a chain of waits, playback, or AGI hops, the analysis window opens after the greeting is over. Symptom: AMD "works" on manual test calls but misfires at volume, because predictive pacing adds the latency that pushes the answer past the start of analysis.

Fix: start AMD() as early as the dial plan allows. Watch a live call and confirm AMD is running during the first seconds, not after.

6. Verdicts produced but ignored

Asterisk says MACHINE on every voicemail and agents still get connected. That is layer two. amd_send_message left empty or set to CONTINUE means the dialer acknowledges the verdict and dials on regardless. drop_call_seconds set high means the system waits out the machine before acting.

Fix: in the campaign's Answering Machine Detection section, set amd_send_message=HANGUP and drop_call_seconds between 6 and 8. Then place one test call to your own voicemail and one from a real cell phone, and watch both dispositions land. Two minutes, validates the whole chain.

Causes 7–9: the ones nobody checks

7. Your stats say AMD works — the recordings disagree

AMD-dropped calls are not counted as abandons, so a config that hangs up on 6% of real humans shows a clean compliance dashboard forever. The only honest instrument is your own recordings: pull 50 random calls dispositioned as AMD, listen to the first 8–10 seconds of each, count the live humans. More than 3 of 50 is a broken config no matter what the reports say.

8. Accurate at 10am, broken by 7pm

If accuracy tracks the clock, the config is fine and the list is not. Fresh leads answer fast and clean; aged leads answer slower, route to voicemail more, and transit different carriers. A static threshold set during onboarding is tuned for whichever context you tested in and wrong for most of the rest.

Fix: split tuning by list age and dial window — or accept that the treadmill is the product and step off it.

9. AMD stopped doing anything after a rebuild

After an Asterisk upgrade, sometimes detection simply stops: every call HUMAN, zero MACHINE dispositions, no errors anywhere. The usual culprit is app_amd not loaded in the new build, or amd.conf replaced by a package default that nothing reads.

Fix: asterisk -rx "module show like amd" to confirm the module is loaded, then module reload app_amd after every config change.

When tuning stops being the answer

Notice what the exercise proves: three of the causes are inside amd.conf, three are in the carrier path and dial plan, and three are in the reporting and the list itself. Timing-based detection fails at the boundaries of its inputs, and its inputs drift with every list, hour, and route. Tuning is how you chase that drift, not how you end it.

Acoustic AI AMD ends it. AMDY classifies the acoustic signature of the answer audio and returns a decision in 1/8 of a second at 99% accuracy — no thresholds to re-balance, and carrier false-answers classified outright. It installs alongside Vicidial in minutes.

One note: better AMD supports your TCPA and abandon-rate posture, but it is not legal advice.

The full version of this guide, with the internal-link reference tables and the production settings block, lives on the AMDY blog.