- Ringba’s default routing sorts by Priority + Weight first, then checks target filters. Your top-paying buyer absorbs rejections it should never have seen.
- Most final expense buyers score each publisher account on acceptance rate. When that score drops, the pricing conversation follows, often within the next billing cycle.
- The fix is rule order: Compliance → Tag → Schedule → Capacity → Priority → Weight. Filters must disqualify a target before the priority sort runs.
- Set Concurrency Cap below the buyer’s stated capacity. Wrap-up agents look available to Ringba and unavailable to the buyer.
- Match Duplicate Payout windows per target to each buyer’s actual dedup window from their SOW, not Ringba’s platform default.
Questions this article answers:
- In what order does Ringba evaluate routing rules by default?
- Why does my $58 final expense buyer keep getting outbid by a $42 buyer with looser targeting?
- How do buyer-side rejections affect future payouts?
- What duplicate payout window should I use for final expense buyers?
- Should I use RTB or static routing for final expense?
- How do I audit my Ringba routing tree against buyer payout reports?
Your Bid Sheet Isn’t the Problem. Your Rule Evaluation Order Is
If your ringba call routing rules for final expense buyers sort on Priority + Weight before tag filters fully gate the call, your highest-paying buyer is absorbing rejections it should never have seen. The bid sheet looks right. The payout report looks wrong. The explanation isn’t in either document.
Here’s the scenario most operators recognize.
Your top buyer underperforms versus their headline payout. A lower-tier buyer with “any state, any duration” capacity overperforms. You double-check the bid sheet. It’s fine. You re-export the calls. Routing “worked.”
It didn’t.
Ringba’s default logic handed your premium buyer calls outside their licensed states and outside the 50–85 age band. They rejected those calls. The rejection got logged against your account. The call still routed downstream to a cheaper buyer.
The yield problem is real. The bigger problem is what those rejections do to your payout next quarter.
In What Order Does Ringba Evaluate Routing Rules by Default?
Ringba evaluates routing in this order by default: campaign hit, then Priority + Weight sort selects a candidate target, then target-level filters (tag, geo, schedule, capacity) check whether that target can actually take the call. If filters fail, Ringba drops to the next candidate.
That sounds harmless. On final expense, it’s not.
What Priority + Weight Actually Does Under the Hood
Priority is the rank Ringba uses to decide which target gets first look at a call. Weight splits calls between targets at the same priority tier (per Ringba’s concurrency and routing docs).
Together, they pick a winner from your buyer list. They pick before checking whether the winner can legally or contractually accept the call.
So your top-tier buyer at Priority 1 gets handed every call. Then Ringba checks if the caller’s state matches the buyer’s license footprint. If it doesn’t, Ringba routes down the tree.
But the call already “hit” Priority 1.
Target-Level Filters Are Gates, Not Pre-Sorters
Tag filters at the target level act as a yes/no gate after selection, not a pre-screen before selection.
A buyer licensed in 12 states with a 50–85 age tag still sits in the priority sort for every call. They reject the ones they can’t take. From their dashboard, you look like a publisher with a poor acceptance rate.
The Reporting Blind Spot That Hides This
Ringba’s standard reports show the call as “routed” once it lands somewhere downstream. They don’t natively flag “premium target was offered, premium target couldn’t take it, lower-payout target won.”
To see that, you reconcile against each buyer’s own payout report. Most operators only do that at month-end, after the damage is locked in.
How Do Buyer-Side Rejections Affect Future Payouts?
In our experience, most major final expense buyers track some form of acceptance-rate score per publisher account, and that score influences how aggressively they bid you on future calls. When your premium buyer’s acceptance rate looks artificially low because misrouted calls keep getting offered to them, the pricing conversation usually follows within a billing cycle or two.
This is the load-bearing claim in this article. It’s why filter order matters more than the bid sheet.
The Feedback Loop You Can’t See in Ringba
When tag filters sit after the priority sort, your top buyer absorbs rejection volume on calls they were never going to accept: out-of-age, out-of-state, sub-duration. Their internal scoring system doesn’t know your filter order is wrong. It just sees a publisher whose call quality looks worse than it actually is.
A month or two later, you’ll get the email. “We’re adjusting your pricing to reflect recent quality trends.” Or worse, no email. Just a quiet drop in how often that buyer’s number connects on the inbound side.
The broader call-tracking category treats call quality as a buyer-side input as well; Invoca, for example, markets automated call scoring and quality management as a core platform capability (see Invoca’s quality management platform).
Why “We’ll Just Take the Rejection” Is the Wrong Mental Model
A lot of operators think: who cares if a buyer rejects a call, the call still routes downstream, I still get paid by someone.
That’s true for this call. It’s not true for the next 90 days of calls from that same buyer.
What a Healthy Acceptance Rate Looks Like
As a directional rule of thumb from our own book of business, Tier 1 final expense buyers running strict filters tend to expect publisher acceptance rates in the 80–90% range, while broader-targeting Tier 2 buyers tolerate something looser. When a premium buyer’s acceptance rate drifts well below their stated expectation, that’s typically where pricing conversations start.
Treat those as directional ranges. Confirm the threshold with each buyer’s ops contact when you onboard.
The Correct Filter Order for Final Expense: Compliance → Tag → Schedule → Capacity → Priority → Weight
The correct ringba routing for final expense evaluates compliance and tag filters before Priority + Weight ever runs, so disqualified targets get removed from the candidate pool entirely. The priority sort then chooses among targets that can actually take the call.
This is the single highest-leverage change you can make to a final expense routing tree.
Here’s how each layer should be configured.
Compliance Filters Fire at the Campaign Level
TCPA and CMS compliance rules belong at the campaign level. The call should never enter the routing tree if it doesn’t have valid consent (see ActiveProspect’s TrustedForm documentation for how consent certificates flow into Ringba).
Compliance is not a tiebreaker between buyers. It’s a pre-condition for the call existing at all.
For more on how consent flows into your buying stack, see our breakdown of TrustedForm and Jornaya as quality signals.
Age-Band Tag Filters at the Target Level
The 50–85 age band is a buyer-specific contract term, not a universal rule. Different final expense buyers accept different ranges.
Put the age tag filter on each buyer target. Configure it so a non-match removes the target from the candidate pool. Not so a non-match triggers a rejection after selection.
In Ringba, this means using the tag filter as a routing rule that returns the target as ineligible, not as a post-selection check.
State License Filters When Buyers Have Different Footprints
State license filters are the most common source of rejection drift. One buyer is licensed in 38 states, another in 12, a third in 47.
Each gets its own state tag filter. Applied at the target level. Evaluated before the priority sort.
Concurrency Cap Below Stated Capacity
In our experience, it’s worth setting each buyer’s concurrency cap a step below their stated agent capacity. The two sides of the integration don’t always agree on whether an agent on wrap-up is “available,” and the safer default is to leave yourself a small buffer.
Without the buffer, you can route one or two calls per peak hour into a buyer who can’t actually pick up. That posts as a rejection on their side.
It’s a small tweak that costs nothing and protects acceptance rate during high-volume windows.
Schedule Rules Tied to Buyer Hours
If your publisher dialer runs 8am–9pm EST and your buyer’s call center runs 9am–7pm CST, the overlap matters more than your hours do.
Build the schedule rule on the buyer’s operating hours, not yours. Calls outside that window should drop to a fallback tier, not into a premium buyer’s voicemail.
AEP makes this worse. During AEP, some buyers extend hours. Many don’t. Verify with each buyer’s ops contact before the season starts, not after.
What Duplicate Payout Window Should I Use for Final Expense Buyers?
Match Ringba’s Duplicate Payout window per target to each buyer’s actual dedup window from their SOW. In our experience, final expense buyers commonly run windows in the 7–30 day range, and some tighten further during AEP. Leaving a longer window in place than the buyer actually uses suppresses callable repeat callers the buyer would happily pay for again (per Ringba’s duplicate call routing docs).
How to Find Each Buyer’s Actual Dedup Window
It’s in the buyer SOW. If it isn’t, ask the buyer’s ops contact directly. They’ll tell you, because they want the volume.
Common windows we see: 7 days, 14 days, 30 days. Some Tier 1 buyers tighten further during AEP.
Per-Target Duplicate Payout, Not Campaign-Level
Set Duplicate Payout on each buyer target individually.
A campaign-level setting forces every buyer to share the same dedup logic. That means you either suppress calls some buyers would pay for, or you send duplicates to buyers who will reject them and ding your acceptance rate.
The Volume Math
On a 10,000-call month with a genuine repeat-caller rate in the low double digits, a dedup window misaligned by several weeks against a much shorter buyer window can suppress several hundred billable calls per buyer. At final expense per-call payouts, that’s real money per buyer, per month. Compounded across 5 buyers, the dedup mismatch alone can dwarf the rest of your optimization work.
Should I Use RTB or Static Routing for Final Expense?
For most final expense Ringba accounts, static routing with strict filter ordering beats real-time bidding (RTB). RTB amplifies the same acceptance-rate problem if your filters fire late.
RTB starts to make sense once you have 8+ active buyers with overlapping coverage and reliable ping-post infrastructure. If you’re running 3–5 buyers with clean tier separation, static routing plans with the filter order above will outperform RTB on net revenue per call.
Building the Fallback Tier So Premium Calls Don’t Land on a Backstop
Design your fallback tier with the same filter discipline as your premium tier. Never as a catch-all that swallows whatever Tier 1 rejects.
The mistake we see most often: a single fallback target with no filters, catching every call Tier 1 couldn’t take and dumping them on a low-payout backstop buyer who accepts a fraction of routed calls.
The fix is a real tier structure:
| Tier | Payout Range | Filters | When It Wins |
|---|---|---|---|
| Tier 1 | Premium | Strict age (50–85), licensed states only, 60s+ duration | Call matches all premium gates |
| Tier 2 | Mid | Relaxed age band or broader states | Tier 1 disqualified, call still strong |
| Tier 3 | Backstop | Minimal filters | Last-resort, prevents zero-revenue calls |
Each tier still uses the Compliance → Tag → Schedule → Capacity → Priority → Weight order within the tier. Bid modifiers can adjust payout at the target level without breaking the evaluation sequence. They apply after a target wins, not during selection.
For a deeper look at how to rank buyer payout tiers by expected value per call, see ranking Ringba buyers by EV/call.
How Do I Audit My Ringba Routing Tree Against Buyer Payout Reports?
Reconcile Ringba’s payout export against each buyer’s payout export at month-end, matching on call ID, then flag two patterns: (1) calls where a lower-payout target won despite a higher-payout target being eligible, and (2) calls a buyer rejected for a reason your filter should have caught. Both indicate filter-order errors.
Here’s the 9-point audit we run on every final expense Ringba account.
The 9-Point Routing Audit
- Pull Ringba’s call detail report for the period, including chosen target, payout, and disposition.
- Pull each buyer’s payout report for the same period, including accepted/rejected status and rejection reason.
- Match on call ID or phone+timestamp across both exports.
- Flag any call where Ringba’s chosen target wasn’t the highest-payout eligible target that would have passed all filters.
- Flag any rejection with reason “age,” “state,” or “license.” These should have been caught by tag filters.
- Flag any rejection with reason “duplicate.” These indicate a dedup window mismatch.
- Calculate acceptance rate per buyer. Accepted calls divided by total calls routed to that target. A meaningful drop on a premium buyer is a problem.
- Calculate effective payout per routed call. (Accepted payout minus reversed/disputed) divided by total calls routed to that target.
- Compare effective payout to headline payout. The gap is your real cost of misrouting.
Effective Payout per Routed Call vs. Headline RPC
Headline payout is what the buyer quotes you. Effective payout per routed call is what you actually earn after rejections, reversals, and disputes.
The gap between them is where filter order lives.
A buyer quoting a premium rate with a mediocre acceptance rate yields meaningfully less per routed call than the same buyer at a healthy acceptance rate. That gap, on the same bid sheet, is purely a function of filter order.
Catching Acceptance-Rate Drift Before the Buyer Emails You
Run the audit weekly during AEP and monthly the rest of the year. Watch the trend line on acceptance rate per buyer, not just the absolute number.
A buyer drifting steadily downward over four weeks is heading toward a pricing conversation, even if neither of you has noticed yet.
For an automated version of this audit, our breakdown of the four-resource Ringba MCP server schema covers how to surface publisher drift programmatically.
Frequently Asked Questions
In what order does Ringba evaluate routing rules by default?
Ringba evaluates Priority + Weight first to select a candidate target, then checks target-level filters (tag, geo, schedule, capacity) to confirm that target can take the call. If filters fail post-selection, Ringba drops to the next candidate. The problem on final expense is that the premium target absorbs a rejection on every call it couldn’t legally take. That drags its buyer-side acceptance rate even though the call ultimately routed downstream.
Why does my top-paying final expense buyer keep getting outbid by a cheaper buyer with looser targeting?
Your premium buyer isn’t being outbid. They’re being offered calls they can’t accept, rejecting them, and then the cheaper buyer wins by default. Because Ringba’s default order runs Priority + Weight before tag filters fully disqualify a target, the premium buyer enters the candidate pool on every call. Moving age-band and state-license filters above the priority sort fixes this and protects the premium buyer’s acceptance score.
How do buyer-side rejections affect future payouts?
In our experience, most major final expense buyers score publisher accounts on acceptance rate, and that score influences future payouts. When your premium buyer’s acceptance rate slides because they keep getting offered calls they can’t take, the typical outcome is a pricing cut or quiet de-prioritization within a billing cycle or two. The routing-order fix isn’t about this month’s RPC. It’s about whether the buyer still pays you the same rate next quarter.
What duplicate payout window should I use for final expense buyers?
Match Ringba’s Duplicate Payout setting on each target to the buyer’s stated dedup window from the SOW. In our experience, final expense buyers commonly run windows somewhere in the 7–30 day range. A window set longer than the buyer’s actual window suppresses callable repeat callers the buyer would have purchased again. A window set shorter causes the buyer to reject the call as a duplicate, which dings your acceptance rate.
Should I use RTB or static routing for final expense?
Static routing with strict filter ordering beats RTB for most final expense accounts running 3–5 buyers, because RTB amplifies acceptance-rate damage if filters fire late. RTB starts to make sense once you have 8+ active buyers with overlapping coverage and reliable ping-post infrastructure. Until then, the Compliance → Tag → Schedule → Capacity → Priority → Weight order on a static plan will outperform RTB on net revenue per call.
How do I audit my Ringba routing tree against buyer payout reports?
Export Ringba’s call detail report and each buyer’s payout report for the same period, match on call ID, and flag calls where a lower-payout target won despite a higher-payout target being eligible, or where a buyer rejected for a reason your filter should have caught. Calculate acceptance rate and effective payout per routed call for each buyer. The gap between headline payout and effective payout is your real cost of misrouting.
We’re media buyers and lead-gen operators sharing what we see in the field. This isn’t legal advice. TCPA and consent rules in pay-per-call vary by state and vertical. Talk to an attorney before changing your consent flows or vendor contracts.
If you’re running serious volume through a Ringba account on final expense and your month-end reconciliation is surfacing payout gaps you can’t explain, the routing tree is usually where the answer lives. Our pay-per-call team audits final expense routing setups against the exact framework above: filter order, dedup windows, concurrency caps, tier design, and the buyer-side acceptance-rate feedback loop most operators never connect to pricing drift. Book a free strategy call with Elevarus to walk through your routing tree.
