How often is answering machine detection wrong? Measured numbers, not vendor claims

Why your AMD dashboard cannot tell you the error rate

Every answering machine detection system produces a log of verdicts. None of them produces a log of correct answers. When your ViciDial report says 82% machine, it is telling you what the classifier concluded, and the classifier is exactly the thing whose correctness is in question. The measurement is circular.

The direction of error also hides asymmetrically. A machine wrongly sent to an agent is visible: the agent hears a voicemail greeting and complains. A human wrongly hung up on leaves no trace anywhere in your stack. They are not in your abandonment count, because they were never queued. They are not in your callback list, because the record was dispositioned as a machine. This is the same asymmetry we describe in predictive dialer abandonment rate, and it is why AMD tuning drifts toward aggression over time.

What we can publish: the measured classification distribution

What aggregate data does support is the outcome distribution: what share of answered outbound calls end up in each class. Across 3,680,697,808 detections processed by AMDY between 1 July 2026 to 31 July 2026, the platform-wide split was as follows.

Read that top line carefully. Across 3,680,697,808 detections between 1 July 2026 to 31 July 2026, 79.72% of answered outbound calls were a recorded system of some kind, and only 12.70% were a live person. Roughly four out of five times your dialer reports a connect, there is nothing on the other end that can be sold to.

Two caveats that matter more than the headline. First, this is platform-wide across all customer traffic, list types, geographies and dialing hours; a single campaign can sit far outside it. Second, the carrier false answer share here counts only detections carrying an explicit FAS class label. Some false answers present as pure silence and land in the silence class instead, so 2.67% is a floor on FAS, not an estimate of it. Background on that failure mode is in carrier false answers and SIP trunks and false answer supervision.

The ten largest individual classes

Grouping hides something useful, which is how much of the machine bucket is a specific identifiable system rather than a generic recorded voice. In the same window, 3,680,697,808 detections resolved into 44 distinct class labels. These were the ten largest.

The largest single machine class is generic — a recorded system the model did not attribute to a named platform — at 25.25% of all detections. Everything below it is a specific carrier or provider voicemail system. That granularity is the practical argument for classification over a binary verdict: a stock app_amd result has three possible values and cannot express any of these distinctions, as covered in the AMD glossary.

What about the undecided calls?

In the same window, AMDY emitted 44 distinct classification labels and none of them is an undecided class. Every detection returned a class. That is a property of how the classifier is built rather than evidence that it was right, and it is worth stating plainly for that reason: returning an answer on every call is not the same as returning a correct answer on every call.

Stock Asterisk detection works the other way. app_amd has an explicit undecided value, NOTSURE, which it returns whenever its analysis window closes with no threshold decisively crossed. That is arguably the more honest design, and it moves the problem to your dialplan. What to do about it is the subject of this companion piece on routing NOTSURE.

How this compares to published vendor accuracy claims

Vendors publish precision figures. MightyCall states 97% precision for its AI answering machine detection, a claim we cover in MightyCall alternatives. AMDY’s own marketing states 99% accuracy. Neither of those numbers, ours included, is derivable from the aggregate table above, and you should not treat this article as evidence for AMDY’s figure.

The reason is worth being blunt about. A precision figure is only meaningful with three things attached: the labelling procedure that produced ground truth, the traffic the sample was drawn from, and which of the two error directions it describes. A vendor number that omits all three is unfalsifiable. Ask for those three things before you believe any accuracy claim, including ours.

The audit that produces a real error rate on your traffic

Since no vendor figure transfers to your lists, the only number that matters is the one you measure yourself. The procedure is dull and takes about an hour.

• Pull a random sample of at least 50 recorded answers from the last full dialing day, spread across the hours you actually dial rather than clustered in one.
• Listen to each recording and write down what it really was before you look at what the engine returned. Reversing that order contaminates the labels.
• Compare your labels to the engine verdicts, and report the two error directions separately: humans classified as machines, and machines classified as humans.
• If you run stock Asterisk detection, count the NOTSURE share separately again, and check what your dialplan actually does with it.
• Repeat on a second day before you change any threshold. One day of sampling on 50 calls is a wide confidence interval.

The step-by-step version with the ViciDial specifics is in how to test your AMD accuracy before going live, and the tuning failure modes the audit usually exposes are in the narrow middle.

Method and measurement window

This is the query the figures came from, unmodified:

-- amd_hourly_classification is a TimescaleDB continuous aggregate.
-- Never scan raw amd_logs for this; it is roughly a terabyte compressed.
WITH t AS (
  SELECT classification AS c, SUM(count)::numeric AS n
    FROM amd_hourly_classification
   WHERE bucket >= '2026-07-01' AND bucket < '2026-08-01'
   GROUP BY 1
)
SELECT c,
       n::bigint,
       ROUND(100 * n / (SELECT SUM(n) FROM t), 2) AS pct
  FROM t
 ORDER BY n DESC;

The takeaway

Roughly one in eight answered outbound calls is a person. That figure is measured, and it is the honest starting point for any conversation about detection accuracy. The error rate on top of it is not measured by anyone’s dashboard, including ours, and the only way to get it is to sit down with 50 recordings. Do that before you trust a percentage in a sales deck.

FAQ

How often is answering machine detection wrong?

No dialer report can tell you, because a detection log records what the engine decided and never whether the decision was correct. Producing a real error rate requires listening to a sample of recorded answer audio and hand-labelling it, then comparing those labels to what the engine returned. Any accuracy percentage published without a described labelling procedure — ours or a competitor’s — is a claim, not a measurement.

What percentage of answered outbound calls reach a live human?

Across 3,680,697,808 detections processed by AMDY between 1 July 2026 and 31 July 2026, 12.70% were classified as a live human and 79.72% as some form of recorded system. This is a platform-wide figure across all customer traffic and dialing hours; a single campaign with a different list, time-of-day pattern or geography can sit well outside it.

How many calls end up undecided?

In the same window, AMDY emitted 44 distinct classification labels and none of them is an undecided class — every detection returned a class. This is a property of how the classifier is built, not evidence that it was right; Asterisk app_amd by contrast has an explicit undecided value, NOTSURE, which it returns whenever its analysis window closes without a threshold being crossed.

How do I measure AMD accuracy on my own traffic?

Pull a random sample of at least 50 recorded answers from the last full dialing day, spread across the hours you actually dial. Listen to each one and write down what it really was before looking at what the engine said. Then compare. Report the two error directions separately: humans classified as machines, which you lose silently, and machines classified as humans, which burn agent time visibly.