Payback Period Math, in Plain English
A plain-English payback formula for answering machine detection: plan cost vs recovered conversations, worked at every tier with your own numbers.
Payback Period Math, in Plain English
When the fix pays for itself inside the first campaign.
That is the standard a tool should meet in a call center. Not "eventually," not "strategically." Inside the first campaign. Answering machine detection is one of the rare line items where you can check that standard with arithmetic on four numbers you already have: call volume, answer rate, close rate, and average deal value. This article gives you the formula, a worked table at every plan tier using substitute-your-own inputs, a sensitivity check for the skeptics, and a decision rule at the end. No invented case studies, no vendor-massaged benchmarks. Your numbers, our prices, arithmetic.
The one problem payback math has to price
Default answering machine detection on Vicidial-class dialers uses fixed timers. Listen for silence, count words, guess. Our measured data says it drops an estimated 10 to 20 percent of live humans: a real person says hello, the dialer files them under voicemail, and the call ends before an agent ever knows. Every one of those is a conversation you already paid to generate. The list was bought, the dialer ran, the carrier connected the call, and then the classifier threw it away at the last step.
So the payback question is not "is AI detection good." It is: what is a recovered conversation worth to you, how many can you recover, and what does the tool cost per month. If the first two multiplied together beat the third, you buy. If not, you do not. Everything below is just that sentence with the variables named.
The formula, in words first
Four inputs, all yours:
- C = calls dialed per month
- H = human answer rate (the share of calls a live person picks up)
- D = the drop rate on those humans, meaning live people your current detection misfiles as voicemail. This is the number you should measure, not guess; the free trial exists for exactly that.
- V = value of one closed deal, and R = your close rate on live conversations
Then:
- Humans answered per month = C × H
- Humans currently dropped per month = C × H × D
- Recovered deals per month = C × H × D × R
- Value recovered per month = C × H × D × R × V
- Payback check: value recovered per month vs monthly plan cost
If value recovered exceeds the plan cost, the tool is cash-positive in month one and the "payback period" is under 30 days. If it is close, use the sensitivity section below before deciding.
One honest caveat: a recovered conversation is a routed call with an agent on it, and some of those people hang up in the first seconds anyway. The sensitivity section handles this without pretending the recovery rate is perfect. I would rather show you the discounted version than quote the flattering one.
The plans, so the cost side is exact
Unlimited servers on every plan, monthly cancel anytime, per-call logging included. Full details on the pricing page.
| Plan | Monthly price | Detections included | Overage per detection |
|---|---|---|---|
| Sandbox | $0 | 50,000 (hard cap) | None, ever |
| Starter | $79 | 500,000 | $0.00025 |
| Growth | $299 | 5,000,000 | $0.00015 |
| Scale | $999 | 25,000,000 | $0.00010 |
Note what the cost side looks like at scale. At Growth's included volume, $299 for 5,000,000 detections is effectively $0.00006 per detection inside the plan. Your per-detection cost falls as you grow, which is the opposite of most per-seat software you buy. And if you want to test all of this before spending anything, the Sandbox tier is 50,000 detections a month, no card, hard cap, on your production traffic. Measure D with it. That is the single most valuable input in the formula and the only one you cannot get from your CRM.
The worked table, with substitute-your-own inputs
I am not going to invent "typical" close rates or deal values and pass them off as your economics. Instead, here is the table with the structure fixed and the inputs yours to swap. The example column uses round placeholder numbers so you can see the mechanics; replace every one with your own before quoting the result in a meeting.
| Input | Symbol | Example (yours to replace) |
|---|---|---|
| Calls dialed / month | C | 300,000 |
| Human answer rate | H | 15% |
| Humans dropped by current AMD | D | 15% (midpoint of the 10-20% we measure; measure yours) |
| Close rate on live conversations | R | 10% |
| Average value per closed deal | V | $500 |
Run it:
- Humans answered: 300,000 × 0.15 = 45,000
- Humans currently dropped: 45,000 × 0.15 = 6,750 per month
- Recovered deals: 6,750 × 0.10 = 675
- Value recovered: 675 × $500 = $337,500 per month
Against a Growth plan at $299, that is not a close call; it is three orders of magnitude. Even against Scale at $999 it is trivially positive. And this is the example column, not your business. If your V is $50 instead of $500, value recovered is $33,750 and the conclusion does not move. The structure of the math matters more than any single input, because D multiplies everything and D is the number default detection hides from you.
Why D dominates the formula
Every other input you already track and optimize. You buy better lists to move H. You train agents to move R. You price to move V. D is the one variable where money leaks with no dashboard, because a dropped human is invisible: it reports as a machine, which reports as normal. That is why I keep saying measure it rather than estimate it. The free trial's entire economic purpose is putting a real number in that row, from your traffic, before you commit to a plan.
Payback at each tier, structured
Rather than fake a scenario per tier, here is the break-even each plan must clear. This is the same formula inverted, which is the honest way to present it: what does D need to be for the plan to pay for itself in month one?
Assume the example inputs above except D, and solve for the value recovered needed to cover each plan:
| Plan | Monthly cost | Recovered value needed / month | Implied D at R=10%, V=$500 | Implied D at R=5%, V=$250 |
|---|---|---|---|---|
| Starter | $79 | > $79 | > 0.004% | > 0.014% |
| Growth | $299 | > $299 | > 0.013% | > 0.053% |
| Scale | $999 | > $999 | > 0.044% | > 0.18% |
Compare those thresholds against the 10 to 20 percent we measure on default detection. The gap between "break-even drop rate" and "actual drop rate" is roughly two orders of magnitude. That is the whole argument, and you should distrust any vendor version of this chart whose thresholds are conveniently near your measured value. If your measured D lands anywhere near these break-evens, do not buy; at those levels AMD is a rounding error on your floor and the honest answer is the free tier or nothing.
Sensitivity: what if you only recover half
The skeptic's question, and it is the right one: what if the estimate does not transfer to your floor? Run the formula at half the measured D.
Using the example inputs with D = 7.5 percent instead of 15:
- Humans dropped: 45,000 × 0.075 = 3,375
- Recovered deals: 3,375 × 0.10 = 337.5, call it 337
- Value recovered: 337 × $500 = $168,750 per month
Still three orders of magnitude above the plan cost. Quarter the drop rate, 3.75 percent, and you get roughly $84,000. The decision is insensitive to the recovery assumption across any plausible range, which is the point of doing the math this way. A decision that flips based on whether D is 15 percent or 10 percent was never a real decision; it was a coin toss dressed up.
Two more sensitivity cases worth running before your meeting:
Your close rate is worse than you think
Run R at half your reported number. Floor-reported close rates often include cherry-picked call dispositions. Halving R halves recovered value and, per the table above, changes nothing about the conclusion.
Your average deal value is small
If V is $50 and R is 5 percent and D is the low-end 10 percent: 45,000 × 0.10 = 4,500 dropped humans, × 0.05 = 225 recovered deals, × $50 = $11,250 per month. Growth still clears by a factor of 37. For the tool to fail payback at these volumes you would need D measured near zero, in which case your default detection is unusually good and you should keep it. The trial will tell you.
The decision rule
Written down so you can lift it into a memo:
- Run the free trial, 50,000 detections, no card, alongside your current setup. Install is one command by your dialer admin, about five minutes.
- Measure D on your own traffic from the per-call logs. Sample disagreements and listen to a few hundred; do not take the classifier's word for its own accuracy either.
- Compute C × H × D × R × V. Compare to the plan your volume lands in.
- If recovered value exceeds plan cost by 10x or more, and the sensitivity run at half-D still clears, buy the plan. Monthly cancel-anytime means the decision is reversible, so treat it as such: decide, measure again in 60 days, leave if the number regresses.
- If D measures under 1 percent, do not buy. Come back if your traffic mix changes.
The 10x cushion is deliberate. It is the margin that absorbs every modeling objection above: partial recovery, short calls, worse close rates, all at once. If a purchase clears 10x on measured inputs and survives the halving test, the remaining risk is not financial.
Where the numbers come from, and their limits
Everything on the cost side is our published pricing, unchanged. The 10 to 20 percent drop estimate is from detection data we measured, described on the features page; your floor may differ, which is why this entire article keeps returning to measuring D yourself. I wrote about how detection errors split by type and why direction matters in AMD error directions, and about the per-number lifetime framing that makes this same math a standing KPI rather than a one-time purchase decision in cost per number, the life metric.
One compliance note that belongs in any honest payback discussion: slow detection is not free even when it is accurate. The FTC caps abandonment at 3 percent of live answers per campaign over 30 days under the Telemarketing Sales Rule, 16 CFR 310.4(b)(4), current text at ecfr.gov. AMDY's verdict starts at 125 milliseconds, which keeps classification well clear of the window where the decision itself abandons the caller. The trade-off between deciding fast and deciding right is covered in AMD latency vs accuracy. There is also a compliance-side payback that does not show up in the revenue formula: per-call detection logs are the paper trail you want if a campaign's numbers are ever questioned, which I discuss in AMD logs as compliance defense.
Common ways this math gets done wrong
I have watched this calculation go wrong in the same three ways for years, usually in the vendor's favor, sometimes accidentally.
Inflating D with a vendor's number
The 10 to 20 percent figure is what we measured across our detection data. It is an honest range, but it is not your number. If your lists are clean, your carriers honest, and your call windows well chosen, your D may sit at the low end. If you buy aged debt leads and dial evening windows, it may sit at the top. The formula multiplies D by everything else, so D is the one input worth measuring rather than borrowing. That is the entire reason the free tier exists: 50,000 detections, no card, hard cap, your traffic.
Counting recovered conversations as recovered deals
The formula converts dropped humans into deals through your close rate, and your close rate is measured on the calls your agents actually get today. A recovered call is a colder, more surprised prospect than the average live answer: they said hello to silence and then got routed. Some fraction answers and immediately hangs up. The sensitivity section's halving test covers most of this, but if you want to be strict, run R at 40 percent of your floor-reported close rate as the pessimistic case. If the purchase still clears, it clears.
Forgetting the overage tier exists
The worked tables above use included volume. If your dialing volume grows mid-contract, you do not jump plans automatically; you pay the per-detection overage rate for your tier, which at Scale is $0.00010, or $100 per million extra detections. Price the realistic month, not the average month, when you pick a tier. The monthly cancel-anytime terms also mean you can move tiers on a month's notice rather than forecasting a year of volume in advance.
Treating payback as the only criterion
A tool can clear payback and still be wrong for you if it adds operational risk: a new failure domain on the dialer server, a dependency with no logs, a vendor with no export. This is why the per-call logging matters beyond the audit story. Logs are how you verify, month over month, that the D you measured at trial is the D you are getting. I wrote about what happens when traffic mix shifts and detection quietly degrades in AMD model drift; the standing defense is watching your own numbers, which requires the numbers to be exported.
The keepable version
If you remember one thing: cost per month over recovered conversations times close rate times deal value. Plan cost is the only number in that fraction the vendor controls. Everything else you can measure on your own floor, and with the free tier you can measure the drop rate before paying anything at all.
Start at the signup page, 50,000 detections a month, no card. Run your traffic through it, plug your D into the formula above, and the payback period question answers itself with your own arithmetic.
What is your current drop rate on live humans? If you can quote a number, you are the exception. If you cannot, that is the finding.