Why Your Costs Should Not Grow Because Your Dialing Grew

I ran a call center through a growth spurt once that nearly put us underwater. Not because the business was bad. Because the business was good. We went from four dialer servers to nine in about five months, and every single one of them came with a licensing line item that had nothing to do with how many calls we actually handled. Our dialing volume had grown maybe 60%. Our software bill had grown 125%. I remember staring at the invoice wondering at what point success became the thing bankrupting us.

That is the experience I want to save you from in this article, because answering machine detection, the layer that decides whether a live human or a machine picked up your call, is sold under two very different pricing models in this market. One of them taxes your growth. The other one tracks it. The difference between them, compounded over a year of scaling, is real money. And the choice is entirely in your hands as the owner or CFO, because it is a buying decision, not a technical one.

The Two Ways This Category Is Priced

Strip away the feature checklists and the vendor decks. When you buy answer handling for an outbound center, you run into one of two pricing shapes.

Model One: Pay Per Server, Per Seat, Per Anything Fixed

The vendor charges you a license or subscription per dialer server, per concurrent channel, per agent seat, or per some other unit of infrastructure. The bill is a function of how much hardware and headcount you run, not how much work the product does.

This model made sense when software shipped on CDs. It persists because it is predictable for the vendor and easy to bolt onto how dialers themselves are licensed. If your dialer charges per seat, the detection vendor riding alongside it charges per seat too, and nobody questions whether the seat is the right unit.

Here is the problem. Servers and seats are inputs. Detections are outputs. When you pay per input, every efficiency you gain as an operator gets punished. Better lists, better pacing, smarter campaign design, all of it means fewer inputs per output, and per-input pricing quietly becomes a worse and worse deal the better you run your shop.

Model Two: Pay Per Detection, With Volume Included

The vendor charges by the call, the actual unit of work, and bundles a monthly allowance into the base fee. Your bill is a function of dialing volume and nothing else. Add servers, and the bill does not move. Add agents, and the bill does not move. Grow into your tier's included volume, and the bill does not move at all.

This is the model we chose at AMDY, and I will be upfront that this article argues for it. But arguing for it is not the same as being vague about it. I am going to show you exactly how each model behaves as a center scales, using our real published tier structure, so you can run your own numbers against your own volume. If your vendor's model wins on your math, keep your vendor.

Why Per-Server Pricing Punishes The Growth You Want

Growth in an outbound center has a specific shape. You do not add capacity in smooth increments. You add a server when a campaign lands. You add three when a client doubles their budget in Q4. You swing hard for tax season, open enrollment, whatever your vertical's peak is, then you shed capacity in the trough.

Under per-server pricing, that rhythm is a tax schedule. Consider what actually happens in each scenario.

The Campaign Landing

A new client signs. You spin up two more dialer servers to handle their volume. Detection vendor invoices you for two more licenses on the first of the month, before the client's first invoice has even been paid. Your cash flow front-loads the cost and back-loads the revenue. Multiply by every new client and you have built yourself a working capital treadmill.

The Vertical Peak

Open enrollment, tax season, debt settlement in January. Everyone in your vertical dials harder for six weeks. Under per-server pricing you either buy permanent capacity for a temporary surge, and carry it dead for ten and a half months, or you negotiate temporary licenses every year like it is a farmers market. Either way you pay a coordination cost on top of the dollar cost, and coordination cost means someone on your team spends hours on procurement instead of operations.

The Efficiency Gain

This is the one nobody talks about. Suppose your team gets better. Tighter lists, better scripting, a smarter dialing ratio. You now generate the same revenue from fewer servers. Under per-server pricing, your reward for operational excellence is a smaller bill only if you actually decommission the licenses, which involves contract terms, minimums, and the vendor's retention department. I have sat through that call. The discount they offer you to stay usually costs more than the licenses you were cancelling.

How Your Bill Actually Scales Under Each Model

Let us make this concrete with the real thing. AMDY's published plans, the ones on our pricing page, look like this.

Plan	Monthly base	Included detections	Overage per detection	Servers included
Sandbox	$0	50,000/mo, hard cap	None, cap enforced	Unlimited
Starter	$79	500,000/mo	$0.00025	Unlimited
Growth	$299	5,000,000/mo	$0.00015	Unlimited
Scale	$999	25,000,000/mo	$0.00010	Unlimited
Partner	From $2,000/mo	Custom	Custom	Unlimited

Notice the last column. Every plan, including the free one, includes unlimited servers. That is not a promotional flourish. It is the entire point. Adding dialer servers never adds fees, because servers are inputs and we do not bill for inputs. If you want to see the feature set behind those numbers, it is all on the features page.

Now run your own center through the math. You need two numbers from last month: total detections processed, and dialer servers running. I will use a composite center to illustrate, and you should substitute your own figures.

The Formula, Per Model

Per-server cost is: licenses x price per server per month. That is the whole formula. Notice what is missing: any term for volume. A center dialing 2 million calls on 6 servers and a center dialing 400,000 calls on 6 servers pay the same amount, which means the efficient operator subsidizes the inefficient one, because per-server pricing averages the market's waste into everyone's rate.

Per-detection cost is: base + max(0, detections - included) x overage rate. Below the cap, marginal cost is zero. Above it, you know the rate to four decimal places before you ever make a call.

A Worked Example At Three Sizes

Take a center that starts at 3 servers and 400,000 detections a month, then grows to 6 servers and 1.8 million, then peaks seasonally at 10 servers and 4 million for two months. Assume the per-server vendor charges $150 per server per month, a representative figure for licensed telecom software, so you should replace it with your actual quote.

At stage one, per-server costs $450 and AMDY Starter costs $79 with zero overage. At stage two, per-server costs $900 while AMDY Growth costs $299, still zero overage at 1.8 million against a 5 million allowance. At the seasonal peak, per-server costs $1,500 and AMDY Growth still costs $299, because 4 million sits inside the allowance. When the peak passes and the center drops back to 6 servers, the per-server bill needs license cancellations to come back down, and the AMDY bill comes down on its own because it never went up.

Two things worth flagging in that example. First, the per-server numbers assume clean proportional licensing, which almost no real contract offers once minimum terms enter. Second, I picked the $150 figure as an illustration, not a benchmark. The honest comparison is your quote versus your volume, and the formula above is how you run it.

Seasonal Peaks Without Penalty

The seasonal case deserves its own section because it is where the models diverge hardest, and because it maps to a rule regulators already care about.

Under per-detection pricing with included volume, a seasonal peak costs you overage at worst, and nothing at all if the peak fits inside your tier. The Growth plan's 5 million monthly allowance is specifically sized so a mid-market center can absorb a doubling for a few weeks without a contract conversation. You dial harder, the number goes up or it does not, and in January it comes back down. No renegotiation, no true-up meeting, no procurement cycle in your busiest month.

Under per-server pricing, the same peak is a sequence of decisions. How many licenses, for how long, at what temporary rate, on whose approval. Every one of those decisions lands on a manager's desk during the one time of year when that manager has zero spare attention. I have watched a peak season get under-resourced because the paperwork for temporary licenses was slower than the campaign itself. The revenue lost dwarfed the license cost.

There is also a compliance angle to dialing harder. The FTC's telemarketing rules cap call abandonment at 3% of answered calls over a measurement period, measured per day under the amended rule. A center that lets its detection quality slip during a peak, because the cheap capacity it added handles answers poorly, can push abandonment toward that cap at exactly the moment its call volume is highest and most visible. Capacity decisions and compliance exposure are the same decision. I cover the logging side of that in AMD logs as a compliance defense.

The Question That Decides The Model

If you remember one thing from this piece, make it this question, asked of any vendor in this category: what exactly are you charging me for?

If the answer is servers, seats, channels, or any other input, the vendor is billing your infrastructure. If the answer is detections, the vendor is billing your work. The distinction sounds philosophical until the quarter you grow, at which point it becomes a line item you can point at.

The reason input pricing survives at all is inertia. Detection grew up attached to dialers, and dialers licensed per seat, so detection priced per seat too, and nobody revisited the assumption for a decade. Meanwhile the actual cost of running a detection decision collapsed, verdicts start at 125 milliseconds on modern systems, and the honest unit of value stopped matching the legacy unit of billing. Vendors who price on inputs today are not charging what the work costs. They are charging what the market used to tolerate.

What The Money Not Spent Is Worth

There is a second-order effect of the pricing model that never shows up in a vendor comparison, and it is the one I care about most as an operator.

When detection is cheap and metered, you stop rationing it. Centers on per-server licenses routinely leave detection coverage off for low-priority campaigns, or short campaigns, or test campaigns, because the license math says the small stuff is not worth a seat. Every campaign you leave uncovered drops humans at the default rate, the 10 to 20% we measured, except now it is the campaign you considered too small to protect.

When detection is included volume, the calculus inverts. Covering the small campaign costs the marginal detection rate, which rounds to nothing. So you cover everything, and the drop-rate leak closes everywhere instead of just on the marquee client. The pricing model does not just change what you pay. It changes what you are willing to fix.

That is also why we hard-cap the free Sandbox tier at 50,000 detections rather than metering it. A free tier that can overage into a surprise bill is not a free tier. It is a trap with a welcome mat. The cap makes the free tier safe to point at real traffic on day one, with no card on file and no ceiling you can fall through, which is exactly what you want when you are running the comparison this article is telling you to run.

The Objection I Get From CFOs

When I present this model, the finance people usually raise one fair objection: per-detection pricing means the bill is variable, and variable is harder to budget than fixed.

Fair, and here is the honest answer. The bill is variable but bounded, and the bounds are published. Your monthly cost is at most base + (detections - included) x rate, and your detection count is the most predictable number in your building. You know it from last year's dialer reports within a few percent. A per-server bill feels fixed until the year you grow, at which point it becomes variable with a step function and a contract term attached. Fixed pricing is only fixed while you stand still, and standing still is not your plan.

The second objection is that unlimited servers means the vendor is leaving money on the table. Maybe. But servers cost us approximately nothing to support relative to detections. The unit of our cost is the call. The unit of your value is the call. Pricing anywhere else creates a gap between what we spend and what you pay, and gaps like that always end up arbitrated by someone's sales team at your expense.

What To Do With This On Monday

Three actions, none of which require touching your dialer configuration.

First, pull last month's detection count and server count from your dialer reports. If your current vendor is per-server, divide your annual spend by twelve and put it next to the tier your volume lands in on the pricing page. That is your gap, in dollars, per month.

Second, look at your growth plan for the next four quarters. Every planned server add is a planned license add under per-server pricing. Total them. That number, which currently appears nowhere in your budget, is what the pricing model quietly costs you.

Third, run the actual test. The Sandbox tier is free, 50,000 detections a month, no card required, and it installs in about five minutes with one command by your dialer admin. Details are at the signup page. Measure the drop rate against your current setup using your own numbers, not mine. I have written about how to read a live-answer percentage honestly in cost per number, the life metric, and about which errors matter most in AMD error directions. The default AMD shipped with most dialers drops an estimated 10 to 20% of live humans, a range we measured, so the baseline you are comparing against is probably worse than whoever configured it believes.

A center's costs should grow when its revenue grows. That is fair. Costs that grow when its infrastructure grows, independent of revenue, are a tax on ambition dressed up as an invoice. You would not accept it from your landlord. There is no reason to accept it from your detection vendor.