Why "Accuracy" Isn't the Right Metric — Cost Is
Every AMD vendor pitch leads with an accuracy number. 92%. 95%. 97%. Those numbers are useful, but they're not what your CFO cares about, and they're not what actually shows up on a P&L. What matters is the dollar cost of the calls your AMD gets wrong — and once you run that math, the case for tightening AMD accuracy stops being a "nice to have" and starts looking like one of the highest-leverage line items in your entire outbound operation.
This is a framework for putting a real number on that cost, so you can compare it against what a better AMD solution actually costs to run.
The Two Ways AMD Gets It Wrong
AMD errors fall into two buckets, and they cost you in different ways:
False positives (machine flagged as human): Rare with most modern systems, but expensive when it happens — an agent gets bridged onto a live answering machine greeting, burns 15-20 seconds figuring out it's not a person, and the actual human on a follow-up attempt may never get called back promptly.
False negatives (human flagged as machine): This is the expensive one, and it's the one that plagues Asterisk's default AMD engine at scale. A real person picks up, the AMD engine misreads the greeting pattern as a voicemail box, and the system either plays a pre-recorded voicemail drop at a live human or hangs up entirely. You paid for the connect. You just never got to use it.
Building the Cost Model
Here's the framework, with placeholder numbers you can swap for your own:
| Variable | Example Value | Where to Get It |
|---|---|---|
| Outbound calls per day | 5,000 | Dialer reporting |
| % of calls that connect (human or machine) | 35% (1,750 calls) | Dialer reporting |
| % of connects that are actually human | 40% (700 calls) | Dialer reporting / manual QA sample |
| AMD false positive rate (human misread as machine) | 20% (Asterisk default range is 15-25%) | Manual QA review of a call sample |
| Live humans lost to AMD misclassification per day | 700 × 20% = 140 calls | Calculated |
| Average revenue or value per live conversation | $35 (varies heavily by vertical — insurance and solar run higher, debt collection and surveys run lower) | Your own conversion data |
| Daily cost of AMD false positives | 140 × $35 = $4,900/day | Calculated |
Run that same 140 calls/day out over a 22-day working month and you're looking at roughly $107,800/month in live conversations that never happened because the dialer thought a human was a machine. Even a modest per-call value of $10 puts you at $30,800/month. This is the number that should be driving your AMD purchasing decision, not the accuracy percentage on a spec sheet.
Why This Compounds Beyond the Missed Call
The direct cost above is just the first layer. A few second-order effects worth building into your model:
- Agent utilization drops. If your dialer is running predictive pacing and a chunk of your "connects" are silently voicemail drops that should have been live transfers, your pacing algorithm is calibrated on bad data — it thinks it's delivering more live connects per agent than it actually is, which either starves agents or over-dials and increases abandonment. We cover the mechanics of that trade-off in our call abandonment guide.
- Lead lists get burned faster. A lead that was actually a live answer but got logged as "voicemail" in your CRM often doesn't get flagged for a priority callback — it just sits in the file, sometimes never called again, even though you already paid for and used the contact attempt.
- KPI reporting lies to you. Connect rate, answer rate, and conversion rate all get distorted when a meaningful slice of your "machine" bucket is actually mislabeled humans. If you're benchmarking performance using the framework in our call center KPIs guide, a bad AMD engine quietly corrupts the inputs to nearly every metric downstream of connect rate.
What "Good" Actually Looks Like
Asterisk's built-in AMD, running on default settings, typically lands in the 15-25% false positive range depending on call volume and greeting variety. Tuned manually with more aggressive silence and speech thresholds (see our best AMD dialer settings guide), you can sometimes get that down into the low double digits — but tuning is a constant trade-off between false positives and false negatives, and it degrades again as soon as your lead demographics or carrier mix shifts.
AI-powered AMD, which analyzes the actual acoustic pattern of the greeting rather than just silence/energy thresholds, is a different category. We cover the mechanics of how that detection actually works in this breakdown. The practical number that matters for your model: going from a 20% false positive rate down to 2-3% doesn't just improve a KPI — using the model above, it turns a $107,800/month leak into roughly $12,000-16,000/month, a swing that pays for the AMD upgrade itself several times over in the first month.
Run Your Own Numbers
Before you evaluate any AMD vendor, pull three numbers from your own dialer reporting:
- Daily human connects (from a manual QA sample, not just what the dialer logs as "human" — you need to catch what it's currently misclassifying)
- Your best estimate of current AMD false positive rate (pull 100-200 recorded "machine" calls and listen — this is tedious but it's the only way to get a real number)
- Average value per live conversation in your vertical
Multiply those out and you'll have a real dollar figure to hold up against any AMD vendor's pricing. Most call centers are surprised by how large the number is — and how quickly a false-positive-rate improvement pays for itself.
That's the gap amdify.io was built to close. It plugs into VICIdial and Asterisk-based dialers and moves AMD false positive rates from the 15-25% range down to 1-3%, which in the model above is the difference between a five-figure monthly leak and a rounding error. If you want to see what that looks like against your own call volume, amdify.io is worth a look before your next AMD vendor decision.