AMD False Positive Rate vs. False Negative Rate: The Number Vendors Don't Want You Comparing
Every AMD vendor pitch deck has the same slide: a big percentage, usually somewhere between 95% and 99%, next to a logo and the word "accuracy." MightyCall claims 97%. Several cloud telephony platforms cite numbers in the mid-90s. A recent academic paper on real-time voicemail detection reported 96.1% combined accuracy across a 764-call test set. These numbers get repeated in sales calls, RFP responses, and comparison blog posts until they start to sound like a settled fact.
They're not. "Accuracy" is a single number that hides two very different failure modes, and which one a vendor is optimizing for determines whether their AMD engine will help your campaign or quietly bleed it dry. If you're evaluating AMD vendors, sizing a migration, or trying to figure out why your current engine "tests fine" but performs badly in production, you need to stop asking "what's your accuracy?" and start asking a more specific question: accurate at avoiding which mistake?
Two Ways to Be Wrong, One Number to Hide Them
AMD is a binary classification problem — every call gets sorted into "human" or "machine" — which means every AMD engine makes exactly two kinds of mistakes:
- False positive: the engine classifies a live human as a machine. The call gets dropped, routed to a voicemail-drop flow, or hung up before an agent ever connects. The prospect who answered the phone hears dead air or a click and hangs up, annoyed.
- False negative: the engine classifies an answering machine or voicemail system as a human. The call gets bridged to an agent, who then wastes 15–30 seconds pitching a voicemail greeting before realizing no one is there.
A composite "accuracy" number — (correct classifications) / (total calls) — blends both error types into one figure, and it's trivially easy to post a high composite score while being terrible at the error type that actually costs you money. Here's the trick: most outbound lists skew heavily toward answering machines and voicemail. On a typical cold B2C list, somewhere between 55% and 75% of connected calls land on a machine, not a human. An AMD engine that's tuned to aggressively call almost everything "machine" will rack up a high composite accuracy score simply because it's right most of the time by volume — while silently torching the 25–45% of calls that were actually live prospects.
This is the mechanism behind the gap you may have already seen cited elsewhere on this site: legacy, energy/silence-based AMD on stock Asterisk typically runs a 15–25% false positive rate in production, even though the same engine might report 80%+ "accuracy" in a vendor data sheet. The composite number and the number that matters for your P&L are not the same number. For more on how that legacy detection method actually works under the hood, see our breakdown of how AI voicemail detection works compared to the traditional silence-timing approach.
Why This Split Exists: AMD Is a Precision/Recall Tradeoff
If you've worked with any classifier — spam filters, fraud detection, medical screening — this will be familiar. Every AMD engine sits somewhere on a tunable curve between two extremes:
| Tuning posture | What it optimizes for | What it costs you |
|---|---|---|
| Aggressive (fast decision, low silence threshold) | Speed — hands calls to agents almost immediately | Higher false positive rate; live answers get misread as machines |
| Conservative (longer analysis window, higher confidence threshold) | Safety — rarely misclassifies a human | Higher false negative rate; agents waste time on voicemail; abandonment clock still ticking during analysis |
A vendor can report almost any composite accuracy number they want simply by choosing where on this curve to benchmark, and by choosing a test set that doesn't resemble your actual call mix. A test set built from a 50/50 human/machine split (common in academic papers and vendor whitepapers) produces a very different accuracy number than your real list, which might run 30/70. This is exactly why the 96.1% figure from the research paper mentioned above was measured with a reported 0.3% false positive rate over roughly 77,000 production calls — that's the detail that actually tells you something, and it's the detail most vendor marketing omits.
The question to ask every vendor
Not: "What's your accuracy rate?"
Instead: "What is your false positive rate, measured separately from false negative rate, on a call mix similar to mine?"
If a vendor can't break the number apart, or won't tell you what test set it came from, treat the composite figure as marketing copy, not an engineering spec. We cover the full list of questions worth asking before signing in our AMD vendor evaluation checklist — this false positive/false negative split is the single most important line item on that list.
Why False Positives Are the More Expensive Mistake
Both error types cost money, but they are not symmetric, and most call centers under-weight false positives because the damage is invisible in standard dialer reporting.
A false negative is visible and self-limiting. The agent hears a voicemail greeting, logs it, and moves to the next call. It costs 15–30 seconds of agent time per occurrence. It shows up in your reporting as a "machine" disposition (just a late one), so you can see the problem and quantify it directly.
A false positive is invisible and compounding. The call never reaches an agent, so there's no disposition that flags it as a mistake — it just looks like a hangup, a no-answer, or gets silently redirected into a voicemail-drop flow. You don't see it in your reports because your reports are built from the same AMD classification that made the error. Each false positive also carries three downstream costs:
- A burned contact attempt against your Regulation F 7-in-7 limit or internal attempt cap — see our call attempt counting guide if you're in collections, where every wasted attempt is a scarcer resource.
- A real prospect who had a bad experience. They answered, heard nothing or a click, and are now less likely to answer your number again — which also degrades your carrier reputation signals over time.
- An FCC abandoned-call compliance risk, if the misclassification results in the call being dropped without a live agent connection within the required window. We go deeper on that exposure in our AMD false positives and FCC abandoned-call compliance piece.
Run the numbers on a mid-size operation: 50 agents, 4,000 outbound attempts per agent per month, a 35% live-answer rate. That's roughly 70,000 live human answers per month. At a 20% false positive rate (typical for stock Asterisk AMD), you're silently dropping around 14,000 real conversations every month — read our false positive cost ROI framework for the full math on converting that into a dollar figure specific to your average deal value.
How to Actually Measure Both Numbers on Your Own Traffic
Vendor-reported numbers, even broken into false positive and false negative rates, are still measured on someone else's call mix. The only number that matters is the one from your dialer. Here's the fast version of the methodology (the full step-by-step is in our AMD accuracy audit framework):
- Pull 300–500 recent calls that your AMD engine classified as "machine" and were never bridged to an agent.
- Manually review the recordings. Score each as a true machine detection or a false positive (a human who was misclassified).
- Separately pull 300–500 calls classified as "human" and bridged to an agent, and have QA flag how many were actually voicemail (false negatives), using agent disposition notes or call recordings.
- Calculate both rates independently: false positive rate = (misclassified humans) / (total machine classifications); false negative rate = (misclassified machines) / (total human classifications).
- Weight the cost of each using your actual average revenue per contact and attempt-budget constraints — false positives are usually 3–5x more expensive per occurrence once you account for the lost contact, not just the wasted analysis time.
Most operations doing this exercise for the first time are surprised that their real false positive rate is double or triple what their dialer's summary dashboard implies, precisely because dashboards built on top of the AMD engine's own classifications can't see the engine's own mistakes.
What a Properly Tuned Engine Looks Like
A well-built AMD system doesn't eliminate the precision/recall tradeoff — it moves the whole curve closer to the origin, lowering both error types simultaneously through better signal processing (spectral and prosodic features, not just silence timing) and models trained specifically to separate the human-greeting/machine-greeting boundary rather than relying on a fixed silence threshold. That's the difference between the 15–25% false positive rates typical of rule-based Asterisk AMD and the 1–3% range achievable with a purpose-built AI AMD engine — and it's why amdify.io reports both numbers separately rather than hiding behind a single accuracy figure. If you're evaluating your current setup, ask your vendor for their false positive and false negative rates on a call mix that matches yours, run the audit on your own traffic, and compare the result against amdify.io before your next contract renewal.