How to Audit Your Dialer's AMD Accuracy: A Step-by-Step Measurement Framework

Why "We Think Our AMD Is Fine" Isn't an Answer

Ask most call center operations managers how accurate their answering machine detection is, and you'll get a shrug followed by a guess: "pretty good," "maybe 85%," "our agents complain sometimes." Almost nobody has a number pulled from actual disposition data, and that's a problem, because AMD accuracy is one of the few variables in an outbound operation you can measure precisely and improve with real ROI attached.

If you've already read our AMD false positive cost and ROI framework, you know the financial case for caring. This post is the other half: the actual measurement methodology. No vendor claims, no marketing benchmarks — just a repeatable way to pull your own numbers from your own dialer and know exactly where you stand.

The Two Numbers That Actually Matter

Every AMD system makes two kinds of mistakes, and they pull in opposite directions:

• False positive rate (FPR) — a live human answers, and AMD misclassifies the call as a machine. The call gets dropped or routed to a voicemail-drop flow, and a real prospect never talks to an agent. This is the expensive one: it silently kills conversions that never show up in any report because the call simply looks like "no connect."
• False negative rate (FNR) — an answering machine picks up, and AMD misclassifies it as human. The call routes to a live agent, who wastes 15-45 seconds listening to a voicemail greeting before hanging up. This is the visible, annoying one — agents complain about it constantly — but it's cheap by comparison.

Most dialer admins over-index on fixing false negatives because agents complain loudly about "wasted" calls to machines. Meanwhile false positives — the ones actually costing revenue — go completely unmeasured because nobody complains about a call that never happened. Any audit that doesn't separate these two numbers is not actually measuring anything useful.

Step 1: Pull a Clean Data Sample

You need a minimum of 1,000-2,000 dialed calls from a single, stable campaign to get a statistically meaningful read. Fewer than that and daily variance in answer patterns will swing your numbers by several points in either direction.

If you're on VICIdial, this comes straight out of the vicidial_log table joined against vicidial_agent_log for the disposition trail. Pull:

SELECT status, count(*) as call_count
FROM vicidial_log
WHERE call_date BETWEEN '2026-07-01' AND '2026-07-14'
AND campaign_id = 'YOUR_CAMPAIGN'
GROUP BY status
ORDER BY call_count DESC;

You're looking for the AMD-related status codes specifically — AA (answering machine detected), A (answered by human, no AMD flag), and whatever custom voicemail-drop or DAC statuses your instance uses. Asterisk-native setups will have this same data in AMD() application results logged to your CDR, just under different field names.

Step 2: Manually Re-Score a Sample of "Machine" Calls

This is the step almost everyone skips, and it's the only one that actually surfaces false positives.

Pull 150-200 calls that AMD classified as "machine" (status AA or equivalent) and have someone — not the same person who built the dialer campaign, ideally — listen to the actual recordings. For each one, mark it as:

• Correct machine detection — it really was a voicemail greeting or automated system
• False positive — a live person answered ("Hello? Hello?") and got dropped or routed to a message before an agent connected

In our own audits across VICIdial shops running Asterisk's stock AMD() app, this manual re-score consistently turns up a 15-25% false positive rate — meaning up to a quarter of the calls logged as "machine" were actually a live human who never got a chance to talk to anyone. That number tracks with the industry-standard Asterisk AMD accuracy ceiling; it's not a fluke of a poorly tuned instance, it's the baseline behavior of energy/duration-based detection.

Step 3: Calculate Your Real Rates

Once you have your manual re-score sample, the math is straightforward:

False Positive Rate = (false positives found in sample / total "machine" calls in sample) × 100

Estimated FP Volume = False Positive Rate × Total "machine"-classified calls in full dataset

Example: if your manual review of 200 "machine" calls found 34 false positives, your FPR is 17%. If your full two-week dataset logged 4,800 calls as "machine," you're looking at roughly 816 live prospects who got dropped or mis-routed and never spoke to an agent — in two weeks, on one campaign.

Run the same exercise in reverse — sample calls that connected to live agents and check how many were actually answering machines the agent had to hang up on — to get your false negative rate. It'll almost always be a smaller number by both count and cost, but it's worth having for the full picture.

Step 4: Segment by Carrier and Lead List

FPR is not a flat number across your entire operation — it varies significantly by:

• Originating carrier — some carriers deliver cleaner answer-supervision signaling than others, which directly affects energy-based AMD accuracy
• Lead list age and source — older, recycled lists tend to have more disconnected numbers and voicemail-only lines, skewing your baseline
• Time of day — evening call blocks see more answering machines proportionally, which can make your FPR look artificially better or worse depending on when you sampled

If you only pull one aggregate number, you'll miss that your FPR might be 12% on one carrier route and 28% on another. That's actionable information a single blended number hides completely — see our guide on caller ID reputation management for how carrier-level signal quality compounds with AMD accuracy issues.

Step 5: Set a Re-Audit Cadence

A one-time audit tells you where you stand today. It doesn't tell you if a carrier route degraded, a new lead list behaves differently, or a config change six weeks ago quietly made things worse. Build the re-score into a recurring process:

Cadence	What to check
Weekly	Aggregate machine/human split by campaign, flagged for sudden shifts
Monthly	150-200 call manual re-score per active campaign
Quarterly	Full carrier and lead-source segmentation, re-run this entire audit
After any config or carrier change	Immediate spot-check re-score of 50-100 calls

What a Good Audit Result Actually Looks Like

To benchmark against, here's roughly what we see across different AMD approaches when this exact methodology is applied:

AMD Type	Typical False Positive Rate
Asterisk stock AMD() app, default tuning	15-25%
Asterisk AMD(), hand-tuned thresholds	10-18%
Cloud voice API AMD (general-purpose)	8-15%
Purpose-built AI AMD (trained on greeting patterns)	1-3%

If your audit comes back in the 15-25% range, that's not a sign your team configured something wrong — it's the expected ceiling of energy/duration-based detection, and it's exactly why the industry has moved toward AI classification models trained specifically on greeting audio rather than silence-and-beep heuristics. We covered the mechanics of that shift in how AI voicemail detection works.

Turning the Audit Into a Business Case

Once you have a real FPR number and a real call volume, the ROI conversation with leadership writes itself: multiply your false-positive count by your average contact-to-conversion rate and your average deal or commission value. A 20% FPR on 10,000 monthly dials at even a modest 3% contact-to-sale rate is real, quantifiable revenue walking out the door every single month — not a vague efficiency complaint.

That's the number that gets budget approved for fixing AMD, and it's also the exact number amdify.io customers use to justify the switch. Amdify replaces energy/duration-based detection with a purpose-built AI model trained specifically to distinguish live greetings from machine greetings, dropping false positive rates from the 15-25% Asterisk baseline down to 1-3% — without changing your VICIdial or Asterisk dialplan architecture. Run the audit above on your own data first; if the number makes you wince, see how amdify.io fixes it.