CallTools AMD Alternatives: How to Evaluate Accuracy and What to Use Instead (2026)
CallTools publishes one concrete number about its answering machine detection: around 80% accuracy, in the company glossary, next to the caveat that occasional machine pickups may still reach agents. That number deserves a closer look. Not because 80% is unusual. It is exactly what timing-based AMD usually delivers. The real question is what the other 20% costs you, and whether you can measure it on your own traffic. This guide covers what CallTools publishes about its AMD, how to test any AMD’s accuracy on your own calls, and three alternative paths: an acoustic AI classifier for open dialer stacks, CPaaS detection APIs, and the free default AMD you already have.
What CallTools Is
CallTools is a cloud-hosted outbound dialer platform. It offers predictive, power, preview, progressive, and parallel dialers, plus CRM, SMS, and email integrations and a click-to-call browser extension. Answering machine detection is listed as one of the platform features, bundled into the dialer rather than sold as a separate product.
Pricing is quote-based. The CallTools pricing page is a request calculator that asks for your agent count, weekly call volume, and industry, and site copy mentions “unlimited minutes and zero commitment” for enterprise scaling. There is no published price list, which matters for this comparison: whatever AMD costs you inside CallTools, it is folded into a quote you negotiate, not a line item you can benchmark.
What CallTools Publishes About Its AMD
CallTools is more specific about how its AMD behaves than about what it costs. Everything below comes from calltools.com (the product page, the FAQ on it, and two glossary entries):
- The AMD “employs advanced algorithms” to differentiate live human responses from answering machines within the first few seconds of a call.
- The product FAQ claims “strong accuracy across most outbound campaign types,” but gives no figure on the product page.
- The glossary is where the number lives: detection accuracy of around 80%, with the note that “occasional machine pickups may still reach agents.”
- AMD is enabled by default for most campaigns. When it is on, a short delay means agents will not hear the typical “hello.”
- The detection process takes one to two seconds per call, per the product FAQ.
- CallTools acknowledges AMD performs best on clean, quiet lines, and that loud environments (warehouse floors, busy retail counters, open offices) can affect detection accuracy.
- Per-campaign sensitivity controls let you trade aggressive machine detection against borderline calls reaching agents. AMD Settings let admins change how aggressively the system interprets voice patterns, can reduce false positives (a live answer wrongly classified as a machine, or the reverse), and work alongside Agent Connect Speed.
One more fact, stated as an absence: CallTools publishes no documented way to plug a third-party AMD engine into its hosted dialer. AMD is a bundled platform feature. So the improvement levers inside CallTools are the sensitivity controls above. Anything beyond them means moving your dialing to a stack where you choose the detection layer yourself.
What ~80% Accuracy Means on Live Traffic
Is CallTools AMD bad? Not necessarily. Around 80% is typical of timing-based AMD in general, and the CallTools glossary deserves credit for publishing the number at all. Whether it is a problem depends on two things: your call volume, and what a dropped live answer is worth to you.
The arithmetic is blunt. If roughly one answered call in five is misclassified somewhere, the expensive direction is a live human flagged as a machine: the prospect gets dead air or a disconnect, and you paid for the call, the list slot, and the compliance exposure without getting a conversation. At 10,000 answered calls a month, even a 3% false positive rate on humans is 300 dropped live answers. At 5%, it is 500.
Dashboards record what AMD decided, not whether it was right. No vendor headline number, including ours, tells you your false positive rate on your lists, your carriers, and your calling hours. The only way to know is to audit your own traffic, which is the next section.
How to Test Any AMD’s Accuracy: The 50-Call Audit
This is the same method we recommend for testing any engine, and it works on any platform that exposes per-call results and recordings. If your CallTools account gives you call logs and recordings, run it there. The full walkthrough is in how to test AMD accuracy before going live →
- Filter for machine verdicts. Pull calls flagged MACHINE over the last 3 to 7 days, across campaigns and time buckets rather than one convenient hour.
- Listen to 50 to 100 of them. Tally every recording where a live human actually answered.
- Score the false positive rate. More than 5% of MACHINE-flagged calls turning out to be humans is a serious problem. Under 2% is acceptable for heuristic AMD. Under 0.5% is what acoustic AI AMD should deliver. For reference, 10 to 15% false positives is not unusual on stock Asterisk AMD with fast-answering, mobile-heavy lists.
- Check the unsure rate. A NOTSURE or undecided rate above 8 to 10% of answered calls is a red flag on its own (next section).
One caution for hosted platforms: if you cannot export the machine-flagged recordings at all, that is a finding in itself. You cannot verify what you cannot see, and “trust the vendor number” is not an audit.
NOTSURE and the Gray Zone
Timing-based detection has a third outcome nobody markets: the undecided call. In Asterisk’s app_amd, that bucket is called NOTSURE. It means the detector ran its full analysis window without crossing its thresholds, and handed the call to the dialplan without a verdict. Most default configurations drop NOTSURE calls or treat them as machines. The bucket is not random noise. It is skewed toward real people who answer fast with a short hello, which is exactly the lead profile outbound teams pay to reach. The mechanics: what NOTSURE really means →
CallTools does not publish an equivalent undecided bucket, but the underlying tradeoff is the same one its sensitivity settings expose. Tune the system to miss fewer machines, and more borderline human calls get dropped or reach agents mid-greeting. Tune it to protect humans, and more voicemails get passed to agents. The heuristic can move the problem around. It cannot make it disappear. That is why benchmarking should compare which engine moves more calls out of the gray zone into HUMAN without inflating MACHINE false positives.
Carrier False Answers: The Class No Sensitivity Setting Fixes
There is a misclassification class that no amount of sensitivity tuning touches, because the audio on the line is not what the signal says it is. Carrier false answer supervision (FAS) is when the network signals “connected” on a call that never actually connected: a ring, a busy tone, or a disconnected number billed as an answered call. A two-bucket detector has no category for it and guesses. Background: what FAS costs you, twice →
The scale is not hypothetical. Our State of AMD 2026 analysis of 2.3 billion answered outbound calls over 30 days found that a share of them were carrier false answers, and the carrier false-answer pattern alone accounted for over 200 million of those detections.
A quick diagnostic you can run on any detection log: MACHINE classifications returned in under 400 milliseconds are almost certainly carrier false answers, since no voicemail greeting starts that fast. If you see a spray of sub-400ms machine verdicts, your problem is partly the carrier, and no dialer setting fixes that.
Alternative 1: AMDY.IO (Acoustic AI on Your Own Dialer Stack)
Full disclosure: this is our blog, and AMDY is our product. Treat the claims below as hypotheses and verify them on your own traffic, which the free tier exists for.
AMDY is an acoustic AI classifier. Instead of timing silence and greeting length, it classifies the acoustic signature of the answer audio with an AI model. Detection starts in 1/8 of a second, at 99% accuracy measured across the roughly 2.3 billion answered calls a month on the AMDY network. Because it reads sound rather than words, it also flags the things timing detectors cannot see: carrier false answers and honeypots, with no amd.conf tuning required. Output buckets are human, voicemail, FAS, honeypot, fax, and silence, plus 23 reports and a per-detection log you can audit.
Integration: a one-line bash command installs in under 5 minutes on a ViciDial server, with native Asterisk, FreeSWITCH, and Issabel support, no SIP migration, and no carrier change. Any other platform connects through the API/WebSocket gateway.
Published pricing, from the pricing page:
- Sandbox: $0. 50,000 detections a month, hard cap, no card required.
- Starter: $79/month. 500,000 detections included, then $0.00025 per detection.
- Growth: $299/month. 5 million included, then $0.00015 per detection.
- Scale: $999/month. 25 million included, then $0.00010 per detection.
- Partner: from $2,000/month. Custom volume tier.
The Sandbox allowance is enough to A/B test on one live campaign against your current detection before you commit to anything.
The honest cons:
- AMDY is not a dialer. It classifies the answer; your stack does the dialing. CallTools users cannot bolt it onto the hosted CallTools dialer, so choosing AMDY means moving dialing to a stack you control (ViciDial, Asterisk, FreeSWITCH, Issabel, or an API-driven setup).
- If your volume is small and your current false positive rate audits out under 2%, the migration effort may not pay back. Run the audit first.
- The head-to-head against free default AMD, including where default AMD is good enough: default AMD vs AMDY →
Alternative 2: CPaaS AMD APIs (Twilio, Telnyx, Plivo)
If your team builds on voice APIs rather than runs a dialer, the CPaaS providers sell machine detection as a per-call add-on. Verified published rates: Twilio AMD runs about $0.0075 per answered call, Telnyx Premium AMD about $0.0065 per invocation, and Plivo machine detection about $0.004 per request, all on top of per-minute voice charges. For context, that $0.004 to $0.0075 per call band is ten to seventy times AMDY’s per-detection rate. The broader landscape: best AMD software for call centers →
Two caveats. These are developer APIs, not drop-in features for a hosted dialer: choosing one means rebuilding your dialing on that provider’s platform. And per-call detection fees are linear and uncapped. At a million answered calls a month, detection alone is $4,000 to $7,500 before a single agent minute.
Alternative 3: Keep Default Dialer AMD
The zero-cost baseline deserves a fair hearing. Stock Asterisk AMD (app_amd with amd.conf), which ViciDial ships with, is a timing and silence heuristic. It lands around 70 to 85% accuracy and drops 5 to 15% of live humans, with fast and silent answers hit hardest. What it is: what default AMD actually does → and its limits in detail: stock AMD drawbacks →
That is close enough to CallTools’ published ~80% to make the point: the hosted dialer and the free dialer are in the same technology family. If you run low-volume, low-stakes campaigns and your audit comes back clean, keeping default AMD and tuning it is a defensible choice. Tuning levers: every ViciDial AMD variable, explained → And remember the cost is not zero just because the invoice says so: the real cost of free AMD →
Comparison Table: CallTools AMD vs the Alternatives
Decision Framework: Tune, Test, or Move
Tune CallTools settings when
Your 50-call audit comes back under 2% false positives, your volume is modest, and the hosted dialer otherwise fits your operation. Work the per-campaign sensitivity controls, watch whether borderline calls shift in the direction you want, and re-audit after each change. You are optimizing inside the 80% ceiling, so set expectations accordingly.
A/B test on live traffic when
The audit says your current detection is costing you real leads, but you want evidence before a move. This is what free tiers are for. AMDY’s Sandbox gives you 50,000 detections a month, which covers a split test on one live campaign against your existing detection, same hours, same lists, before you commit to a contract or a migration.
Move when
False positives on humans run above 5%. Your unsure or undecided rate sits above 8 to 10% of answered calls. Your detection log shows a spray of sub-400ms machine verdicts, which points at carrier false answers. Or dropped connects cost real money and the hosted platform gives you no detection layer you can replace. At that point the question is not whether to change detection, but which stack you move dialing to.
Frequently Asked Questions
What is CallTools answering machine detection accuracy?
CallTools’ own glossary states detection accuracy of around 80% and notes that occasional machine pickups may still reach agents. Their product page claims “strong accuracy across most outbound campaign types” but does not publish a figure there. Both statements are on calltools.com.
Is CallTools AMD bad?
Not necessarily. Their published figure of around 80% is typical of timing-based AMD in general. Whether it is a problem depends on your call volume and what a dropped live answer is worth to you. The right move is to audit your own traffic rather than take any vendor’s number at face value, including ours.
How do I test AMD accuracy before switching?
Pull 50 to 100 calls flagged MACHINE over the last 3 to 7 days and listen to the recordings. Count live humans. More than 5% false positives is a serious problem, under 2% is acceptable for heuristic AMD, and under 0.5% is what acoustic AI AMD should deliver. Also track the NOTSURE rate: over 8 to 10% of answered calls is a red flag.
What is NOTSURE and why does it matter for accuracy?
Asterisk timing AMD returns NOTSURE when it cannot commit to human or machine, and most dialplans drop those calls or treat them as machines. That gray zone is skewed toward fast, short human answers, so it quietly costs your best leads. CallTools sensitivity settings make the same tradeoff between missed machines and dropped humans.
Can I improve AMD without leaving CallTools?
Only within what their settings allow. AMD is bundled into the hosted CallTools dialer, and CallTools publishes no way to plug in a third-party detection engine. So the documented options are tuning their per-campaign sensitivity controls, or moving dialing to a stack where you choose the detection layer yourself.
What is the best CallTools AMD alternative for ViciDial or Asterisk shops?
AMDY.IO. It classifies the acoustic signature of the answer audio, starts detection in 1/8 of a second at 99% accuracy measured across roughly 2.3 billion answered calls a month on the AMDY network, installs with one bash line in under 5 minutes, and keeps your existing dialer and carrier. Sandbox is $0 for 50,000 detections a month, no card required.
What do CPaaS AMD APIs cost?
Twilio AMD runs about $0.0075 per answered call, Telnyx Premium AMD about $0.0065 per invocation, and Plivo machine detection about $0.004 per request, all on top of per-minute voice charges. These are developer APIs for teams building on a CPaaS stack, not drop-in features for a hosted dialer.
Is keeping default dialer AMD a valid option?
Yes. Stock Asterisk AMD is free and built in, and it works often enough for low-volume, low-stakes campaigns. Its documented limits: around 70 to 85% accuracy, 5 to 15% of live humans dropped (fast and silent answers especially), and no visibility into carrier false answers. If dropped connects cost you money, test it before you settle on it.
Test AMDY against your own traffic
50,000 free detections a month on the Sandbox plan, hard cap, no card, 5-minute ViciDial install. Run the split test on one live campaign and judge the numbers yourself.