A Free Trial That Does Not Touch Your Production Floor

Test quietly alongside what you run today. Compare the two on your own calls. Then decide. That is how a software trial should work at a call center, and it is almost never how it works in practice.

I have run outbound floors. When a vendor tells me their trial "only takes a weekend of migration," what I hear is: my campaigns are hostage while we debug someone else's software. So I want to explain, in plain terms, how we structured our trial so it cannot hurt you. If you take nothing else from this piece, take this: the AMDY detector can run alongside your current setup, and nothing gets rerouted until you say so.

Why owners fear trials

The fear is legitimate. It is not technophobia. It is memory.

A dialer change touches the one system that produces revenue every single hour it runs. Every dialer admin has a story about a "small upgrade" that ate a day of calling, or a new module that conflicted with something old and undocumented, or a vendor who needed remote access during peak hours. After two or three of those, owners stop trialing anything. The status quo has a cost, but it is a known cost, and known costs sleep well.

The problem is that the status quo here is not cheap. Default dialer answering machine detection drops an estimated 10 to 20 percent of live humans. That is not a number I looked up. It is what we measured on real traffic when we built the replacement. One in ten people who said "hello" never reached an agent. Some of them were ready to buy that day. All of them got silence or a dead line.

So the honest framing is: you are already paying for the thing you are afraid to test. Every day without a trial, the error rate you inherited keeps working on your contact rate. The only question is whether you can measure it without betting the floor to find out.

You can. Here is how.

What "parallel" actually means

Let me strip the jargon out.

Your dialer already makes a decision on every answered call: is this a person or is this a machine? Something in your stack listens to the first moments of audio and routes the call one way or the other. That decision is where the 10 to 20 percent leak lives.

A parallel trial means the AMDY classifier listens to the same calls and makes its own call, recorded separately. Your existing detector keeps routing exactly as it does today. Agents see nothing different. Callers hear nothing different. Campaign settings, pacing, lists, hours: all untouched. The trial output is a second set of judgments you can line up against the first.

Think of it as a shadow scoreboard at a basketball game. The official scoreboard keeps running the game. The shadow scoreboard counts the same shots with a different scorer. If the shadow scorer consistently counts baskets the official one missed, you have learned something important without affecting a single possession.

The install itself is one command, run by your dialer admin, on your existing server. It takes about five minutes. There is no carrier change, no new hardware, no maintenance window. Your admin does not need to touch dial scripts during the trial. When and if you decide to switch routing over, that is a separate, deliberate step that you control. Until then, the trial is a measurement, not a commitment.

If you want the technical side of what changes at cutover, and what does not, our features page walks through it. But you do not need that page to run the trial. You need it to graduate from the trial.

What the trial measures

A trial that just says "looks better" is worthless. Here is what a parallel run actually gives you, in the order I care about as an operator.

Disagreement rate

On what fraction of calls did the two detectors disagree? This is your first number, usually visible within days. If your current detector and AMDY agree on 96 percent of calls, the trial will be quiet. If they disagree on 12 percent, you have found the leak, and now you know exactly where it was.

Error direction on disagreements

Agreement rates flatter both systems. What matters is who was right when they disagreed. For every disagreement, someone eventually hears the audio or sees the outcome: was it a person or a machine? Direction is everything in this business. A detector that errs toward "machine" silently deletes live conversations, which is lost revenue. A detector that errs toward "human" wastes agent seconds, which is a much cheaper problem. We wrote a whole piece about why error direction matters more than accuracy because most buyers never ask the question. Ask it of any vendor, including us.

Contact rate at the campaign level

This is the CEO's number. Over a full trial cycle, what happened to contacts per hour and conversions per hour on the same lists? During a parallel trial your routing does not change, so this is a baseline measurement. After cutover, it becomes the before and after. Either way, you own the data instead of borrowing the vendor's.

Voicemail behavior

Machines are not all the same either. Voicemails that agents sit through burn payroll. The trial logs show how each system handled machine detections, so you can compare who let agents go faster without hanging up on humans.

Stability across days and lists

One day of data is an anecdote. A trial earns its keep over at least a full week, ideally two, across different days of the week and at least two list types. Watch for two specific patterns. A detector that performs differently on Mondays than Thursdays is reacting to something in your traffic mix, and you want to know that before cutover, not after. A detector that degrades week over week is drifting, and drift is the quiet killer of detection quality. We treat drift as an operational problem with an operational answer, and if the concept is new to you, our piece on AMD model drift explains what to watch for in your own trial data. The short version: any detector whose numbers move without an explanation is a detector you are guessing about.

How to structure the two weeks

A parallel trial with no plan produces data and no conclusions. Here is the structure I would impose on my own floor.

Days 1 and 2: plumbing only

Install, confirm the log is filling, confirm campaigns are behaving exactly as before. Do not look at results yet. Two days of "nothing happened" is the trial's first success criterion. Check contact rate and agent stats against the prior week. If they are indistinguishable, the parallel claim is holding. If anything moved, stop and find out why before proceeding. You have lost nothing.

Days 3 through 7: first read

Pull the disagreement rate and spot-check a sample of disagreements by listening to recordings with your best supervisor. Twenty calls is enough for a first read. You are not adjudicating every call. You are checking whether the disagreements have a direction and whether that direction matches what the measured 10 to 20 percent human-drop rate would predict. In most trials, the pattern is visible inside the first week, and it is usually uncomfortable to see.

Days 8 through 14: the boring confirmation week

The second week exists to confirm the first week was not a fluke of list quality or weather or a carrier hiccup. Rerun the same numbers. A good trial gets slightly boring here, and boring is what you want. If week two matches week one, you have your answer. If it does not, you have found something about your own traffic that you did not know, which is also worth having.

Go or no-go

A trial should end in a decision, not a feeling. When I ran parallel tests, my criteria looked like this. On a representative week of calls: the disagreement rate is stable (not spiking day to day), the disagreements resolve in AMDY's favor on live-human calls, and nothing in the install disturbed normal operations. If all three hold, cut routing over, campaign by campaign, watching contact rate. If any fail, you have spent zero dollars and zero downtime, and you learned the true error profile of your current setup. That knowledge has value on its own. It will also make you a harder target for the next vendor who shows up with a slide deck and no logs.

One more thing worth measuring during the trial: speed. Every classifier takes some time to decide, and a slow verdict on a live human sounds like a dead line to the caller. Our verdict work starts at 125 milliseconds. Latency and accuracy trade off against each other, and we treat that tradeoff as a first-class topic rather than a footnote. If you want the operator's view of it, read AMD latency versus accuracy. Trial both dimensions or you have trialed half the product.

What the trial costs

The Sandbox plan is free: 50,000 detections per month, no credit card, and it is a hard cap. Not "free until we bill you." Hard cap. If you hit 50,000, the service stops counting until next month and you owe nothing. We did that on purpose. The trial's entire job is to be risk-free in every direction: operationally, financially, contractually.

Fifty thousand detections is enough for a serious parallel test at a mid-size floor, and enough for a smaller shop to run for a full month. If your volume is larger, the paid tiers exist and they are boring by design: Starter at $79 a month with 500,000 detections included, Growth at $299 with 5 million, Scale at $999 with 25 million, overage at a flat per-detection rate, unlimited servers, cancel monthly. Full details on the pricing page. No annual lock to trial, no annual lock to keep using it.

A checklist with no fine print

Owners do not evaluate trials by features. They evaluate them by what can go wrong. So here is the honest table: the risk you might worry about, and what actually happens in this trial.

Risk you might worry about	What actually happens during the trial
Live campaigns get disrupted	Nothing is rerouted. Your current detector keeps routing every call until you explicitly switch.
Agents notice something different	Agents see nothing new. The classifier listens and logs; it does not change screens or scripts.
Callers hear clicks, delays, or silence	Caller audio path is untouched during the trial. Verdict work on live calls starts at 125 ms after cutover.
A weekend of migration work	One install command, run by your dialer admin on the existing server. About 5 minutes.
Surprise charges after the trial	Sandbox is 50,000 detections/month, no card on file, hard cap. No overage is possible.
Getting stuck with a new vendor	Monthly plans, unlimited servers. Roll back by routing calls the way you did before.
Wasted effort if it does not win	You finish with a measured error profile of your current detector. That is worth having regardless.

Read that middle column again and notice what is not there: conditions, asterisks, "contact sales." A trial that needs fine print is not a trial. It is a contract with a demo attached.

The compliance angle nobody prices in

There is one more reason the shadow-scoreboard approach matters, and it has nothing to do with revenue per hour.

Under the FTC's Telemarketing Sales Rule, abandoned live answers are capped at 3 percent per campaign, measured over a 30-day period (16 CFR 310.4(b)(4)). You can read the rule itself in the Code of Federal Regulations. Detection sits right next to that number: a live human misclassified as a machine and dropped is, from the regulator's chair, hard to distinguish from an abandoned call. If your detector is quietly deleting a tenth of your live answers, you do not know your real exposure. Nobody does, because it is not being measured.

A parallel trial fixes that, even if you never switch. For the first time you have a second opinion on every call, per campaign, in logs you can export. Some owners run the trial purely for that visibility. I think that is a perfectly rational reason, and I wrote separately about detection logs as a compliance defense for teams whose compliance officer is the actual buyer.

Three objections I hear, answered plainly

"My admin will fight it."

Mine would have too, once. The install is one command on the existing server, about five minutes, and during the trial it changes nothing about how the dialer routes. There is no migration to babysit and no dial-plan surgery. Admins tend to go from skeptical to curious around day three, when they open the log and see calls they personally remember routing. It is their data as much as yours.

"We already tuned our AMD settings."

Everyone has. Tuning the built-in detector's thresholds helps at the margins, and plenty of shops have spent real hours on it. But tuning moves the error between directions; it does not change what the detector can fundamentally hear. If your tuned setup were holding the line, a two-week parallel trial will prove it, and you can stop wondering. That outcome costs you nothing. The measurement is the same either way, which is exactly why running it is cheap.

"If it is that good, why is it free?"

Because a trial that requires a purchase decision up front filters out the exact customers who most need to look: shops with healthy skepticism and limited time. The free tier is capped at 50,000 detections per month, hard cap, no card. If your floor is bigger than that, the paid plans are published plainly on the pricing page and you can size the spend yourself before anyone calls you. The economics only work for us if the measured numbers win the decision. They usually do. That is a bet we are comfortable making, and it is a much better filter than a slide deck.

What happens after a win

Say the trial clears your bar. Cutover is still your decision, on your schedule, and the sane way to do it is incremental. Move one campaign to AMDY routing first. Watch it for three or four days against the campaigns still on the old detector. Same lists logic, same hours, same agents, so the comparison stays honest. Then move the rest in a batch, or one a day if you like watching each step.

Rollback is the mirror of cutover. Because the old path was never removed, only rerouted, going back is a routing change, not a rebuild. Unlimited servers on every plan means multi-floor shops can trial on one floor and roll on another. Nothing about the switch is a one-way door, and any vendor who designs one-way doors into a trial has told you something about their confidence.

It is also worth pricing the win properly. Ten to twenty percent more live conversations on the same dialing spend is not a rounding error; it is the difference between a list being profitable and being filler. We put a full framework around that number, with the formula you can hand to finance, in our piece on cost per number as a life metric. The short version: divide what you spend by live conversations delivered, before the trial and after. That single ratio, tracked monthly, tells you more about your floor than any dashboard screenshot a vendor ever sent you.

The question I would ask

If a vendor pitched me a trial, my first question would be: "What has to change on my floor on day one?" If the answer is anything longer than "nothing," I would keep shopping. Day one of a trial should be observation, never surgery.

Your day one is one command from your admin and a log that starts filling up. Day thirty is a decision you make with your own numbers, on your own calls, against the detector you already run. If the data says switch, you switch knowing exactly what you gained. If the data says stay, you stay knowing exactly what that costs. Either way you stop guessing.

Start the free trial here: amdy.io/auth/signup. Fifty thousand detections a month, no card, and your production floor never notices it is being measured. That is the whole point.