DEV Community: Nick AMDY.IO

What is default AMD in Vicidial — and how it actually works

Nick AMDY.IO — Sun, 28 Jun 2026 00:57:52 +0000

A plain-English explanation of the answering machine detection built into every Vicidial/Asterisk install — what it is, why it exists, and the timing logic it uses under the hood.

If you run a Vicidial dialer, you have used default AMD whether you realized it or not. It is the quiet piece of logic that decides, in the first few seconds of every answered call, whether a person or a machine picked up. Get that decision right and your agents talk to humans. Get it wrong and you either dump live prospects into voicemail or burn agent time on answering machines. This is a from-scratch walkthrough of what default AMD is, why predictive dialers need it, and exactly how the built-in version makes its call.

What default AMD actually is

"Default AMD" — also called stock or built-in AMD — is not a Vicidial feature in the strict sense. It is a feature of Asterisk, the open-source telephony engine Vicidial is built on top of. Asterisk ships with a dialplan application called app_amd, configured by a file named amd.conf. Vicidial simply invokes that application on each answered call when you have asked it to.

Because it comes bundled with the platform, it costs nothing extra and is already installed on every standard Vicidial box. That is its biggest selling point and, as we will see, the root of its limitations. It is a piece of free, general-purpose plumbing that every operator inherits by default.

Why predictive dialers need AMD at all

To understand AMD you have to understand why a dialer over-dials in the first place. A predictive dialer's entire job is to keep agents busy. Most calls a dialer places never reach a live person — they hit voicemail, ring out, get a busy signal, or land on a disconnected number. If the dialer placed exactly one call per free agent, agents would spend most of the shift waiting. So the dialer deliberately places more calls than it has agents, betting that only a fraction will connect to a human.

That bet creates a problem: when a call is answered, something has to decide instantly whether it reached a human worth handing to an agent, or a machine that should be dropped or sent a message. AMD is that gate. It sits between "the call was answered" and "route this somewhere," and its verdict drives everything downstream. Without it, the over-dialing strategy collapses — you would have no way to separate the humans from the voicemails fast enough to act.

This is also where compliance pressure enters. Over-dialing produces abandoned and dropped calls, and regulators care about how many. AMD's accuracy directly affects those numbers, which is why operators obsess over it.

How default AMD works, step by step

When a call connects, app_amd does not transcribe what is said and it does not understand any words. It listens to the raw audio of the first few seconds and measures the timing of sound and silence. Specifically, it tracks:

Initial silence — how long the line stays quiet after the call is answered before any speech begins.
Greeting length — how long the first continuous burst of speech lasts.
Silence after the greeting — the pause once that first burst stops.
Word count and word/silence timing — how many distinct words it hears and how long each word and each gap between words runs.

As these measurements come in, app_amd compares them against the threshold values defined in amd.conf. Those thresholds include things like initial_silence (around 2500ms), greeting (around 1500ms), after_greeting_silence (around 800ms), total_analysis_time (around 5000ms), min_word_length, between_words_silence, maximum_number_of_words, and a silence_threshold that defines how loud audio must be to count as "sound" rather than line noise.

Once the analysis window closes — or once one of the thresholds is decisively crossed — the application reaches a verdict and writes it to a channel variable called AMDSTATUS. That value is one of three things:

HUMAN — the timing looked like a live person.
MACHINE — the timing looked like a recorded greeting.
NOTSURE — the audio did not match either pattern cleanly within the analysis time.

From there the dialplan takes over. It reads AMDSTATUS and routes accordingly: a HUMAN goes to a waiting agent, a MACHINE gets dropped or has a message played, and a NOTSURE is handled by whatever fallback you have configured. The classifier itself makes no routing decision — it only labels the call.

The core assumption: humans and machines on a stopwatch

Everything above rests on a single assumption: that humans and machines sound different on a stopwatch. The reasoning is intuitive. A live person answers with a short "hello," then pauses and waits for you to speak. A voicemail plays a longer, continuous greeting — "Hi, you've reached the Smith residence, we can't come to the phone right now…" — and ends with a beep. Measured purely as durations of speech and silence, those two patterns really do look different.

That is why the heuristic is reasonable. It captures a genuine, real-world difference in how people and machines behave when they answer. For a large share of calls, it works.

It is also why the heuristic is fragile. The moment a human breaks the expected rhythm, the stopwatch lies. A person who answers with a long "Helloooo… hello? who is this?" can read as a MACHINE. Someone in a noisy room, on a bad cell connection, or who simply pauses before speaking can trip the thresholds the wrong way. And machines have drifted too — some voicemail greetings are now short and clipped, which looks human. The timing model has no way to tell the difference because it never hears what was said, only how long it took.

Where the settings live

Default AMD is configured in two places, and it helps to know which lever lives where.

On the server: amd.conf

The timing thresholds — initial silence, greeting length, analysis time, word counts, the silence threshold — all live in amd.conf on the Asterisk server. This is where the actual detection behavior is tuned, and it is edited at the file level, not through the Vicidial web admin.

In Vicidial: the campaign toggle

Whether AMD runs at all is controlled per campaign by the Detect Answering Machine setting. Alongside it sit the Vicidial-layer fields that decide what happens after a machine is detected — notably drop_call_seconds, which governs drop timing, and amd_send_message, which controls whether the dialer hangs up or continues into a message (HANGUP vs CONTINUE). So Asterisk decides what kind of call it is; Vicidial decides what to do about it.

The honest assessment

Default AMD is free, built in, and works often enough that millions of calls a day run through it without anyone thinking twice. For a lot of operators, that is a perfectly fine starting point. There is no shame in running stock.

But it is, fundamentally, a heuristic — a set of stopwatch thresholds applied to audio it does not understand. That is why tuning amd.conf is a perennial chore and why "our AMD accuracy is off" is one of the most common complaints in the Vicidial world. In practice stock AMD lands somewhere around 70–85% accuracy, and it tends to misclassify roughly 5–15% of live humans as machines — every one of which is a connect your agents never get. You can chase those numbers with tuning, but you are tuning a model that listens to timing instead of sound, and there is a ceiling to how far that goes.

FAQ

Is AMD built into Vicidial?

Yes. Vicidial runs on Asterisk, and Asterisk ships with a built-in answering machine detection application called app_amd. Vicidial calls it on answered calls when you enable "Detect Answering Machine" on the campaign. You do not need to buy or install anything extra to get default AMD — it is already there.

What is app_amd?

app_amd is the Asterisk dialplan application that performs default AMD. When a call is answered it listens to the first few seconds of audio, measures the timing of silence and speech, compares those numbers against the thresholds in amd.conf, and sets a channel variable telling the dialplan whether it thinks a human or a machine picked up.

What does AMDSTATUS mean?

AMDSTATUS is the channel variable app_amd sets after it analyzes the answer audio. Its value is HUMAN, MACHINE, or NOTSURE. Your dialplan reads AMDSTATUS and decides what to do next — send a HUMAN to an agent, drop or leave a message on a MACHINE, and handle NOTSURE with whatever fallback rule you choose.

Where do I turn AMD on or off in Vicidial?

At the campaign level. Open the campaign in the admin and set "Detect Answering Machine" to Y or N. Related fields like the answering machine message and the AMD action live alongside it. The detection thresholds themselves live in amd.conf on the Asterisk server, which is edited at the server level rather than in the web admin.

Is default AMD good enough?

It is free, built in, and works often enough for many operators — but it is a timing heuristic, so accuracy typically lands around 70–85% and it will misclassify a share of live humans as machines. For low-volume or low-stakes campaigns that may be acceptable. For high volume, where every dropped human is a lost connect, the tuning ceiling becomes the problem.

AMD tuning in Vicidial: the narrow middle almost everyone misses

Nick AMDY.IO — Tue, 23 Jun 2026 23:36:20 +0000

Originally published at app.amdy.io

Most Vicidial AMD configs fail in one of two opposite directions — and both quietly cost you money. Here's the trap, and the 50-call test that exposes it.

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.

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.

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.

The real cost of 'free' AMD

Nick AMDY.IO — Mon, 22 Jun 2026 20:49:02 +0000

The answering machine detection in your dialer costs nothing on the invoice — and it may be the most expensive line item in your operation. Here's the math.

The AMD built into Vicidial is free in the only sense that matters to a spreadsheet: it never appears on one. There is no per-call charge, no monthly fee, no contract. You flip it on in amd.conf and it works.

But "free" AMD is not free. It is a heuristic — Asterisk app_amd timing silences and greetings — that classifies the answer of a call by stopwatch instead of by sound. That trade-off has a price. It just gets paid out of buckets your accounting never connects back to AMD: dropped revenue, regulatory risk, idle agents, wasted carrier minutes, and DIDs you have to keep replacing. Here is each bucket, with the math.

1. Dropped live leads

Stock AMD's headline failure is the false positive: it decides a real person is a machine and hangs up. Heuristic Asterisk AMD runs around 70–85% accuracy and wrongly drops 5–15% of live humans. Every one of those is a prospect who answered the phone and got dial tone back.

Walk through it — the numbers below are illustrative only, plug in your own:

You place 10,000 dials a day.
Your list answers at 30% → 3,000 answered calls, of which the humans are the ones you care about.
Stock AMD wrongly drops 8% of those humans → 240 live prospects vanish, every day.
At a hypothetical $25 net value per connected lead, that is $6,000/day — roughly $180,000 a month — in opportunity walking out the door.

Change any input and the headline changes, but the shape does not: the dollars lost to dropped humans dwarf any per-detection AMD fee by orders of magnitude. The worst part is you never see it. The dropped call is logged as a machine; the prospect just never picked up again. There is no row in any report that says "human you hung up on."

2. FTC / TCPA exposure

The second cost is the one that does not show up because the first one is hidden. The FCC's safe harbor expects an abandonment rate at or under 3% of answered calls. When your AMD hangs up on a human it mistook for a machine, that drop is recorded as a machine — not as an abandoned call to a person.

So your dashboard shows a comfortable sub-3% abandon rate while your true human-abandon rate is higher, padded with all the live people the heuristic silently discarded. The tighter you tune amd.conf to kill machines aggressively, the more humans you drop — and the cleaner your reported number looks. That is the aggressive-tuning trap: the metric you watch to stay compliant is the same metric the failure mode hides behind.

This cost is regulatory risk, not a line item, which makes it easy to ignore until it is not. AMD supports your compliance program; it is not legal advice and it does not replace your own dialing policy or counsel. The point is narrower: a detector that can't distinguish a dropped human from a machine cannot give you an honest abandon rate.

3. Agent idle time

Tune amd.conf the other way — softly, to avoid dropping humans — and you trade the lead-loss bucket for the labor bucket. A cautious heuristic waits longer before it commits. It listens through 6–10 seconds of a voicemail greeting before deciding it was a machine, and it hands borderline calls to agents to sort out.

That waiting is paid labor. An agent sitting through a recorded greeting, or idling between real connects while the dialer second-guesses itself, is on the clock the whole time. Multiply a few wasted seconds per machine across thousands of machine-answers a day — and remember the network sees roughly 73% of answered calls as machines — and the burned agent-minutes add up to real payroll. By contrast, AMDY decides in under 200 ms, so the agent is only ever connected to a person.

4. Carrier billing for false-answers

Across roughly 2.3 billion answered calls a month, about 14% are carrier false-answers (FAS) — the line reports "answered" and starts billing, but no one ever picked up. Stock AMD has no concept of FAS; app_amd only knows HUMAN / MACHINE / NOTSURE. So those connects look real, your agents get routed to dead air, and your carrier bills you for time on a call that never happened.

At 14% of answered volume, that is one in seven "connects" you are paying for with nothing on the other end — both in carrier minutes and in agent attention. A detector that classifies FAS as its own bucket simply drops those calls before they cost you.

5. Caller-ID reputation

Some of the numbers your dialer hits are honeypots and spam-traps — numbers that exist to catch dialers. Stock AMD can't see them; acoustically a trap answers like anything else. So you keep dialing them, and the carriers and analytics networks that watch those traps flag your caller IDs.

Once a number is tagged "Spam Likely," its answer rate falls — people don't pick up a flagged number. To keep your volume, you buy and rotate fresh DIDs, which get flagged in turn, and the cycle repeats. That is a recurring, compounding cost — DID churn — driven entirely by detection you don't have. AMDY classifies honeypot/spam-trap answers as their own bucket so you can stop dialing them and protect the numbers you already own.

6. Engineering time

Finally, the cost of keeping the "free" thing working. Heuristic AMD is a pile of timing thresholds — initial_silence, greeting, after_greeting_silence, total_analysis_time — that someone has to tune for your lists, your carriers, and your call patterns.

And it drifts. The mix of lists changes, carriers reroute, voicemail greetings shift, and the thresholds that worked last month start dropping humans or letting machines through again. So an engineer re-tunes amd.conf, validates it, and watches it drift right back out. Those hours are salary spent maintaining a detector that is structurally never quite right — because it is guessing from a stopwatch instead of listening.

Totaling up "free"

Add the buckets together and the invoice line that reads $0 is actually one of the most expensive things in your operation. You pay for free AMD in dropped revenue (live humans hung up on), in regulatory risk (an abandon rate that lies to you), in idle agents (labor burned on machines and dead air), in carrier minutes (FAS you can't see), and in DID churn (caller IDs flagged by traps you keep dialing). None of it is on a bill, which is exactly why it persists.

Put a real detector against that. AMDY is an AI/ML model that classifies the acoustic signature of the answer audio — the sound of the pickup, not transcribed words — at 99% accuracy in under 200 ms, sorting human, voicemail, FAS, honeypot/spam-trap, fax, and silence into separate buckets. It installs on Vicidial, Asterisk, FreeSWITCH, or Issabel with one bash command in about five minutes, and it is telco-agnostic, so you keep your carrier.

The pricing sits in context against everything above: $0.00010–$0.00025 per detection, with 50,000 detections a month free on the Sandbox plan. A single recovered live lead pays for hundreds of thousands of detections. Put differently — in the worked example above, one day of dropped leads was hypothetically worth $6,000; 50,000 detections cost between $5 and $12.50.

FAQ

Isn't the AMD in Vicidial free?

The license is free, but the detection is not. Vicidial's AMD is Asterisk app_amd configured in amd.conf — a heuristic that times silences and greetings. It costs nothing to enable, but it misclassifies 5–15% of live humans as machines and can't see carrier false-answers or spam traps. You pay for it in dropped leads, idle agents, wasted carrier minutes, and DID churn — none of which show up on an invoice, which is exactly why it feels free.

How much revenue does bad AMD cost?

It depends on your dial volume, answer rate, and lead value, so the only honest answer is to run your own numbers. As an illustration only: on 10,000 daily dials with a 30% answer rate, that is 3,000 humans reaching the dialer; if stock AMD wrongly drops 8% of them, that is 240 live prospects vanishing every day. At a hypothetical $25 net value per connected lead, that is $6,000/day in opportunity gone — far more than any per-detection AMD fee.

Does free AMD create TCPA risk?

It can mask it. When AMD hangs up on a human it thinks is a machine, that drop is usually logged as a machine, not as an abandoned human call. Your reported abandon rate can sit comfortably under 3% while your true human-abandon rate is higher. The risk is regulatory, not a line item — and it is worse precisely because the metric you watch looks clean. AMD supports your compliance program but is not legal advice; pair it with your own dialing policy and counsel.

How is dialing spam traps expensive?

Stock AMD can't tell a honeypot or spam-trap number from a real person, so your dialer keeps calling them. Carriers and analytics providers use those hits to flag your caller IDs as "Spam Likely", which drops answer rates across all your numbers. Lower answer rates mean you buy and rotate more DIDs to keep volume up — a recurring cost driven entirely by detection you don't have.

How do I calculate my AMD ROI?

Add up the hidden buckets — recovered live leads, reduced FAS minutes, agent time saved, and DIDs you stop burning — then subtract the AMD cost. AMDY runs $0.00010–$0.00025 per detection with 50,000 free every month, so the cost side is tiny next to a single recovered lead.

The 3% rule: how AMD accuracy keeps you TCPA-compliant

Nick AMDY.IO — Mon, 22 Jun 2026 20:35:54 +0000

The FTC caps abandoned calls at 3% of answered calls. The way most operators hit that number on paper is exactly what creates hidden risk. Here's how detection accuracy changes the math.

Not legal advice
This article explains how detection accuracy relates to the abandoned-call rule. It is educational, not legal advice. Pair anything here with your own written compliance policy and qualified counsel before changing how you dial.

Every outbound operation running a predictive dialer eventually meets the 3% rule. It is one of the few hard numbers in an otherwise judgment-heavy area of compliance, which is exactly why it gets gamed. The number on your compliance dashboard can look pristine while the real experience your callers create is anything but. The lever that closes that gap is detection accuracy — and most operators never realize it.

What the 3% rule actually says

The FTC's Telemarketing Sales Rule (TSR) limits the share of abandoned calls a predictive dialer may produce. In plain terms: when a live person answers and no representative is connected to them within two seconds, that is an abandoned call. The rule caps those abandoned calls at no more than 3% of calls answered by a live person, measured per calling campaign, over a defined period — commonly 30 days.

It comes with a safe-harbor framework. To rely on it you generally need to keep your abandonment rate under the cap across the measurement window, play a recorded identification message promptly whenever a call is abandoned, maintain records demonstrating compliance, and honor do-not-call requests. The cap is the headline, but the recordkeeping and the prompt message matter just as much.

The critical detail for this discussion: the denominator is calls answered by a live person, and the numerator is live-person calls you failed to staff in time. Calls dropped because your dialer believed it reached an answering machine are not counted as abandons. That single carve-out is where the trouble starts.

The trap: cosmetically compliant, practically reckless

Here is the move almost every shop discovers eventually. Tune AMD aggressively so it declares "machine" fast and drops the call. Because machine drops do not count as abandons, your reported abandon rate sinks comfortably below 3%. The dashboard turns green. Compliance signs off.

The problem is that the same aggressive tuning that drops machines quickly is also dropping people. Stock heuristic AMD running in Asterisk's app_amd typically lands around 70–85% accuracy and misclassifies 5–15% of live humans as machines. Every one of those is a real person who answered the phone and got hung up on. They never enter your abandon math, because the system labeled them a machine — but they experienced exactly what the rule exists to prevent.

So you can be cosmetically compliant and practically reckless at the same time. The number you report to regulators looks great. The number of human beings who picked up and heard dead air is quietly climbing. The fast-greeting answer — "Hello? Who's this?" with no pause — is one of the most common ways a real person gets misread as a machine.

Aggressive AMD does not make you compliant. It hides the cost of being non-compliant inside a bucket regulators do not measure. That is a fragile place to build a calling operation.

Why accuracy is the real lever

The way out is not better gaming — it is better detection. Accurate AMD changes the math on both sides of the rule at once.

Fewer humans dropped means fewer true abandons

When detection is accurate, the share of real people wrongly labeled as machines collapses. AMDY classifies the acoustic signature of the answer audio — the sound of the pickup, not a transcript of words — at 99% accuracy with a decision in under 200 ms. Fewer false positives on humans means fewer real people experiencing a drop, which is the outcome the rule is actually trying to protect. You are not improving a number; you are improving reality.

You can dial conservatively and still skip voicemail

The honest path to staying under 3% is to dial at a lower ratio so that, when a person answers, a rep is almost always free to take it. Operators resist this because a lower dial ratio usually means more idle agents waiting on voicemails. Accurate AMD breaks that tradeoff: it reliably skips machines, so you keep agent-efficient pacing without leaning on aggressive tuning to manufacture headroom. You stay genuinely under the cap rather than engineering the appearance of it.

Put concretely — on a hypothetical 10,000 daily dials, shaving the human-misclassification rate from 10% down to near zero takes hundreds of real people per day out of the "dropped as machine" bucket and back into live conversations. That is the difference between a number that looks compliant and an operation that behaves compliantly.

The other compliance-adjacent jobs AMD touches

The abandon cap gets the attention, but accurate detection quietly supports two more requirements.

Connecting a live rep fast. The two-second window starts the instant a person answers. Detection latency eats into that window — every millisecond AMD spends deciding is a millisecond your rep is not on the line. A decision in under 200 ms leaves nearly all of the window for the connection itself, which makes hitting the requirement on genuine human answers far easier.

Keeping clean records. Safe harbor leans on evidence. A single dialer flag that says "machine" is weak proof. A queryable per-detection log — one entry per call, with the classification and timing — is far stronger evidence of what your system decided and when. AMDY keeps exactly that, alongside its analytics reports, so you can reconstruct any campaign's behavior instead of trusting a checkbox.

None of this replaces your obligations. It makes the obligations easier to meet and easier to prove.

The honest framing: AMD supports compliance, it is not compliance

It would be dishonest to sell accuracy as a compliance button. Accurate AMD helps you stay genuinely under 3%, connect humans inside the window, and keep defensible records. It does nothing for the rest of a compliant program. You still need consent management, adherence to calling-time rules, DNC list scrubbing, proper recorded messages on abandonment, and a written policy your team actually follows.

Treat AMD accuracy as one strong input into a compliant operation — the input that stops you from quietly dropping real people while your dashboard says everything is fine.

Again: this is not legal advice
The 3% rule, the safe-harbor conditions, and how AMD drops are treated all involve legal judgment that depends on your jurisdiction, campaign structure, and facts. Use this article to inform a conversation with qualified counsel and to build your own written compliance policy — not as a substitute for either.

FAQ

What is the FTC 3% abandoned call rule?

Under the FTC's Telemarketing Sales Rule, a predictive dialer's abandoned calls must not exceed 3% of calls answered by a live person, measured per calling campaign over (typically) a 30-day period. An abandoned call is one where a live person answers but no rep is connected within two seconds. The rule includes a safe-harbor framework — abandonment rate capped over the period, a recorded message played on abandonment, and proper records kept.

Do AMD-dropped calls count as abandoned?

Generally no — a call your dialer drops because AMD classified it as an answering machine is not counted as an abandoned (live-person) call. That is exactly where the trap lives: aggressively tuning AMD to drop more "machines" makes your reported abandon rate look lower, but if that AMD is misclassifying real humans as machines, those people still experienced a dropped call. The number on the dashboard improves while the real-world experience gets worse. This is a compliance gray area, not a loophole — confirm treatment with your own counsel.

Can good AMD make me TCPA-compliant?

No. AMD supports compliance; it is not compliance. Accurate detection helps you stay genuinely under the 3% cap and connect humans faster, but TCPA/TSR compliance also requires consent management, calling-time restrictions, DNC scrubbing, recordkeeping, and your own legal policy. AMD is one input to a compliant program, not a substitute for one.

How does AMD accuracy affect my abandon rate?

Accuracy works on both sides of the rule. Higher accuracy means fewer real humans wrongly dropped as machines (fewer true abandons), and it lets you dial at a lower, more conservative ratio while still skipping voicemail — so you stay under 3% honestly instead of manufacturing the number. Inaccurate AMD forces a choice between idle agents and dropping humans; accurate AMD removes that tradeoff.

Is this legal advice?

No. This article is educational and describes how detection accuracy relates to the abandoned-call rule. It is not legal advice. Pair it with your own written compliance policy and qualified legal counsel before making dialer or campaign decisions.

Default AMD vs AMDY: an honest head-to-head

Nick AMDY.IO — Mon, 22 Jun 2026 18:41:33 +0000

Stock Asterisk AMD is free and built in. AMDY is an acoustic AI classifier you add in five minutes. Here's exactly where each wins — no spin.

First, the honest part: stock AMD is not useless

Let's start by giving default AMD its due, because pretending it has no merit would be dishonest and you'd stop reading. Stock Asterisk AMD — the app_amd application configured in amd.conf — has three real advantages. It is free: no line item, no contract, no per-call charge. It is built in: it ships with Asterisk and Vicidial, so there is no extra dependency to install, secure, or keep running. And for some campaigns it is genuinely good enough.

If you run low-stakes, low-volume outbound — a list where a missed connect costs you nothing, where you are not racing an abandon-rate ceiling, and where caller-ID reputation isn't on the line — the heuristic does the job. It listens for the timing pattern of a long, uninterrupted greeting (the hallmark of voicemail) versus a short utterance followed by silence (the hallmark of a person), sets AMDSTATUS to HUMAN, MACHINE, or NOTSURE, and hands that flag to your dialer. For a lot of operators that has been the whole story for fifteen years.

The case for AMDY isn't that stock AMD is broken. It's that "good enough" has a cost, and that cost is invisible until you measure it. Here is the full picture, line by line.

The head-to-head

	STOCK ASTERISK AMD	AMDY
Method	Timing & silence heuristic	AI on the acoustic signature
Accuracy	70–85%	99%
Speed	Waits out the greeting window	<200 ms
Fast / silent answers	Misread	Handled
Carrier false-answers	Missed	Classified
Honeypot / spam-traps	Invisible	Detected
Output buckets	Human / Machine / NotSure	Human, voicemail, FAS, honeypot, fax, silence
Tuning	Constant re-tuning	None
Analytics	A flag	23 reports + per-detection log
Carrier lock-in	n/a	Telco-agnostic — keep your carrier
Cost	Free, but hidden costs	$0.00010–$0.00025 per detection; 50K/mo free

A table flattens nuance, so the rest of this article expands the rows that actually move money: accuracy and dropped humans, carrier false-answers, and the hidden cost of "free."

Accuracy and the live humans you never hear from

The single biggest difference is the rows that read 70–85% versus 99%. Stock AMD is a heuristic: it infers a machine from timing and silence, not from what the audio actually is. That works until a real person breaks the pattern — and people break it constantly. Someone who answers "Hello? Who's this?" with no pause looks, on a stopwatch, exactly like the front of a voicemail greeting. Someone who picks up and says nothing for a beat trips the silence logic. The result is that heuristic AMD drops roughly 5–15% of live humans as machines.

That number is the quiet one, because a dropped human never shows up in a report as an error. The call just ends. You don't hear the prospect who was about to say yes; you see a slightly lower connect rate and assume the list was tired. AMDY classifies the acoustic signature of the answer audio — the sound of how the line was answered, not a stopwatch on the greeting — so a fast greeting or a silent pickup is just another shape it recognizes. It reaches a decision in under 200 ms, which is why it doesn't need to "wait out" the greeting window the way the heuristic does.

Carrier false-answers: the row stock AMD can't see

Across roughly 2.3 billion answered outbound calls a month, only about 12.5% are a live human. About 73% are machines, and about 14% are carrier false-answers (FAS) — the network signals an answer when no person ever picked up. FAS is the row where the two tools genuinely diverge in kind, not just degree.

Stock AMD has no concept of FAS. Its world has three buckets — HUMAN, MACHINE, NOTSURE — and a carrier false-answer doesn't fit any of them cleanly, so it usually gets passed to an agent as a "connect" that turns out to be dead air. At 14% of answered calls, that is a large, recurring tax on agent time that the heuristic literally cannot label. AMDY classifies FAS as its own bucket, alongside human, voicemail, honeypot/spam-trap, fax, and silence. It also detects honeypots and spam-traps — numbers planted to catch dialers — which are invisible to stock AMD and which, left unhandled, quietly burn your caller-ID reputation.

The hidden cost of "free"

"Free" is the strongest argument for stock AMD and the most misleading. The license cost is zero; the operational cost is not. Every dropped live human is a lead you paid to generate and then hung up on. Every FAS connect is paid agent time spent listening to silence. Every campaign that needs the heuristic re-tuned — nudging initial_silence, greeting, after_greeting_silence in amd.conf to chase a moving target — is engineering time and a window where the numbers are wrong. None of that appears on an invoice, which is exactly why it's easy to ignore.

AMDY has a visible price — a fraction of a cent per detection — precisely so the trade is honest. The model is monthly base plus included detections plus flat per-detection overage: Sandbox is $0 for 50,000 detections a month with no card; Starter is $79 for 500K then $0.00025 each; Growth is $299 for 5M then $0.00015; Scale is $999 for 25M then $0.00010. To put that in context, carrier and CPaaS AMD add-ons run roughly $0.004 to $0.0075 per call — ten to seventy times more, at lower accuracy. The honest comparison is not "free vs paid." It's "hidden cost vs a known fraction of a cent."

What you give up — and what you don't

The fair worry with adding any tool is what it changes. With AMDY the answer is: very little. You don't remove stock AMD — you disable app_amd for the campaign and let AMDY make the call. You keep your carrier and your dialer; it's telco-agnostic. Install is one bash command, about five minutes, native on Vicidial, Asterisk, FreeSWITCH, and Issabel. And because every detection is logged, you trade a single AMD flag for 23 analytics reports plus a queryable per-detection log — so for the first time the human-vs-machine numbers are something you can audit instead of assume.

So which should you run?

Here is the honest call. If you run a few low-volume campaigns, your margins aren't tight, and you genuinely don't care about a handful of dropped leads, stock AMD is fine — keep it, save the money, move on. But if dropped live prospects cost you real revenue, if abandon-rate math is squeezing you, or if caller-ID reputation matters to your operation, the gap between 70–85% and 99% is not a rounding error — it's the difference between connecting with the people you paid to reach and hanging up on them. And you don't have to take any of this on faith: you can test AMDY free on your own traffic, against your own lists, and read the numbers yourself.

Originally published at https://app.amdy.io/blog/default-amd-vs-amdy