Right Party Contact Rate Is the Metric Everyone Tracks and Almost Nobody Diagnoses Correctly
Right party contact rate (RPC) — the percentage of dialed numbers that reach the actual intended person, not just any live voice — is the KPI that collections agencies, insurance shops, and BPO floors live and die by. It's more useful than raw connect rate because it filters out the noise: a wrong number, a spouse who isn't the debtor, a gatekeeper who isn't the decision-maker. RPC is supposed to tell you how many of your dials produced a conversation with the person you were actually trying to reach.
Most RPC improvement plans focus on the list: better skip tracing, fresher data, TCPA-safe number scrubbing, dialing windows tuned to when a specific demographic answers. All of that matters. But there's a ceiling on RPC that list quality alone can't push past, and it's set by something almost no one audits directly: how accurately your dialer's answering machine detection tells a live person from a voicemail before the call ever reaches an agent.
The Two Ways AMD Quietly Caps Your RPC
Answering machine detection sits between "call connects" and "agent talks to someone." Every RPC calculation implicitly trusts that AMD got that gate right. It usually hasn't — Asterisk's default AMD logic, the one running under most VICIdial deployments, misclassifies calls at a 15–25% false positive rate in real production traffic. That error shows up in RPC in two distinct, compounding ways.
False positive (machine mislabeled as human, or human mislabeled as machine) — the direction that kills RPC directly. When AMD flags a live answer as a machine, the call gets dropped, routed to a voicemail-drop message, or disconnected before an agent ever picks up. If that live answer happened to be the right party — the actual debtor, the actual policyholder, the actual lead — your dialer just burned your best possible outcome and logged it as AM in the disposition report. Nobody flags it as a missed RPC, because as far as the system is concerned, it wasn't a contact at all. It's invisible attrition sitting inside a bucket that looks completely normal on a call log.
False negative (machine mislabeled as human) — the direction that pollutes your RPC numerator. When AMD lets a voicemail through as if it were a live pickup, the agent gets connected to dead air or a recorded greeting, wastes 10–20 seconds figuring out it's not a person, and dispositions it. Depending on how your CRM or dialer disposition mapping handles that edge case — a topic we cover in more depth in our VICIdial CRM integration guide — that call can get miscounted as an attempted contact, diluting your RPC denominator with calls that were never going to reach anyone.
Both directions push your reported RPC away from the truth. The first hides real right-party contacts inside the "no contact" pile. The second inflates the pile of "attempts" with calls that were dead on arrival. Fix list quality all you want — if AMD is misjudging one in five or one in four calls, your RPC ceiling is set by that error rate, not by your data.
Running the Numbers
Take a mid-sized collections or insurance operation dialing 10,000 numbers a day at a 35% raw connect rate (live pickup of any kind, machine or human) and a genuine 60% right-party rate among those live pickups — meaning of every connect, 60% would be the actual target if AMD correctly separated human from machine.
| Scenario | AMD false positive rate | Live answers correctly routed to agent | Right-party contacts actually realized |
|---|---|---|---|
| Asterisk default AMD | 20% | 2,800 of 3,500 live answers | ~1,680 |
| Purpose-built AI AMD | 2% | 3,430 of 3,500 live answers | ~2,058 |
That's a swing of roughly 378 right-party contacts a day lost purely to AMD misclassification — not list quality, not dial timing, not agent performance. At a collections shop where a right-party contact converts to a payment arrangement at even a modest 8–12% rate, that gap is the difference between dozens of recovered accounts a day and dozens quietly evaporating into a false-positive voicemail bucket. The same math holds in insurance renewal campaigns, debt settlement, and lead qualification — anywhere RPC is the metric that actually predicts revenue, not just activity.
Why RPC Audits Rarely Catch This
Most call centers audit RPC by pulling disposition reports and asking "how many of our connects were the right person." That's a reasonable question, but it assumes the connect count itself is trustworthy — and it isn't, for the reasons above. A disposition-level audit will faithfully tell you that 60% of your logged connects were right-party, without ever surfacing the calls that never made it into the connect count because AMD silently dropped them as false-positive machines.
To actually find the gap, you need to sample the calls your AMD classified as AM (answering machine) and manually verify a sample of the underlying recordings — the same method we walk through in our AMD accuracy audit and measurement framework. If more than roughly 10% of that AM bucket turns out to be live pickups on manual review, you have a hard floor on your RPC that no amount of list scrubbing will fix, because the calls are being filtered out before your RPC metric ever sees them.
RPC and Pacing Ratio Are More Connected Than Most Teams Realize
There's a second-order effect worth flagging: predictive dialer pacing engines use AMD's answer/machine classification as one of their core inputs for deciding how aggressively to dial ahead. As we cover in our pacing ratio and AMD detection speed guide, a pacing algorithm running on distorted AMD signal doesn't just misclassify individual calls — it mis-tunes the whole campaign's dial-ahead ratio, which changes how many calls are in flight at the moment a right party actually answers. A campaign that's over-dialing because AMD is feeding it bad signal produces more agent-busy moments exactly when a right party connects, meaning some right-party answers get abandoned outright rather than misclassified — a second, separate way the same root cause suppresses RPC.
This compounds further on multi-line and parallel-dial setups, where AMD false positive rates climb even higher as line count increases — see our breakdown of multi-line dialers and AMD false positives if your team runs Mojo, PhoneBurner, or a similar parallel-dial platform. Teams that adopted multi-line dialing specifically to boost RPC often see the opposite happen once AMD accuracy is accounted for, because more simultaneous lines means less audio and less processing time per call for AMD to get the classification right.
What Actually Moves RPC, Ranked by Leverage
For teams trying to improve RPC without a full platform overhaul, here's the realistic order of operations:
- Audit your AMD false positive rate directly, using recording samples rather than trusting the disposition report. This is the step almost everyone skips, and it's the one that tells you whether you have a detection problem or a list problem.
- Fix AMD accuracy before tuning pacing ratio or drop percentage. Adjusting pacing settings on top of bad AMD signal just moves the compliance-vs-contact-rate tradeoff around without addressing the root cause — detailed further in our pacing ratio guide.
- Then invest in list quality — skip tracing, number verification, right-party phone append services. These matter, but they're optimizing a ceiling that AMD accuracy sets first.
- Then tune calling windows and channel-specific strategy (voice vs. SMS vs. email sequencing) for your specific demographic.
Teams frequently run this in reverse — spending months and real budget on list vendors and calling-window experiments before ever checking whether their AMD engine is quietly discarding a fifth of their right-party answers. The audit in step 1 takes a few hours. The list-quality investment in step 3 takes months and recurring spend. Get the order right.
The Bottom Line
Right party contact rate looks like a list-and-targeting problem because that's where most of the visible levers live. But the ceiling on RPC is set upstream, at the moment AMD decides whether a pickup was a person or a machine — and stock Asterisk and VICIdial AMD gets that decision wrong 15–25% of the time in normal production traffic. No amount of skip tracing recovers a right-party contact that got hung up on before an agent ever knew it happened.
amdify.io replaces that default detection layer with a purpose-built AI AMD engine tuned for VICIdial and Asterisk environments, cutting false positive rates from the 15–25% range down to 1–3%. For teams where RPC is the metric that actually drives revenue — collections, insurance, BPO — that accuracy gap is usually the single largest lever available, bigger than the next list-quality vendor or calling-window tweak. If your RPC has plateaued despite investing in better lists, it's worth checking whether AMD is the actual ceiling before spending on anything else. See how amdify.io works.