The caller pressed "1" for emergency plumbing 11 seconds ago. Your IVR captured the Phoenix zip code and confirmed homeowner status. Now — right now, while they're hearing a generic ring tone — four buyers are staring at the same JSON payload: 85028, emergency, homeowner, Google Ads source. Buyer A responds in 87ms with a $67 bid. Buyer B takes 142ms, bids $72. Buyer C declines — at capacity. Buyer D still hasn't answered when the 300ms window closes; their API was too slow.
Buyer B wins. Call routes. The caller hears "Valley Plumbing, this is Mike" and has no idea they were just auctioned off while listening to a ring tone.
That's real-time call bidding. The whole auction took 300 milliseconds.
Most pay-per-call operators have a rough idea that "ping trees" involve auctions. Fewer understand the actual mechanics — the sequence of events, the millisecond constraints, what happens when things break. This guide is the technical walkthrough. Not platform-specific setup instructions — those vary — but the underlying process that every real-time bidding system runs.
This piece assumes you already know what a ping tree is, have picked real-time bidding over direct routing, and want to understand how the auction actually runs.
What Real-Time Call Bidding Actually Does
Real-time bidding (RTB) for calls is a price-discovery mechanism. Instead of routing every call to a predetermined buyer at a fixed payout, the platform broadcasts call data to multiple buyers and lets them compete.
The output: the highest-bidding buyer receives the call. You (the operator or publisher) capture the winning bid as revenue, minus platform fees. Simple concept. The execution is where it gets interesting.
Three things make call RTB different from web ad RTB:
Time pressure is extreme. Display ad auctions run while a page loads — you've got 100-200ms and the user won't notice. Call auctions run while a human is waiting on the phone. Every 100ms of delay feels like an eternity. Callers abandon. This compresses everything.
The data payload is thinner. Web RTB sends device fingerprints, cookies, browsing history, retargeting segments. Call RTB sends phone number, geo (from caller ID or IVR capture), IVR responses, and traffic source. That's it. Buyers make decisions fast on limited signals. That's underrated. Less data means less to screw up. (If you're running Google Ads traffic to pay-per-call, make sure you're filtering click fraud before those clicks become calls — garbage in, garbage out.)
There's only one winner. In display, multiple ads can show on a page. In calls, one buyer gets the call. Losing bidders still see the lead data (this matters for compliance — more on that later) but only the winner gets the conversation.
The Auction Sequence: Millisecond by Millisecond
Let's trace a call through the full RTB cycle. The timings below are illustrative; your platform's settings and your buyers' APIs decide the real numbers, so check your own logs.
Phase 1: Call Arrival and IVR Qualification (0-15,000ms)
Caller dials your tracking number. Your carrier hands the call to your tracking platform. This takes 50-150ms depending on carrier routing.
Your IVR plays. For a home services campaign, this might be:
- Prompt: press 1 for emergency repair, 2 for scheduled service, 3 for an installation quote
- Caller presses 1
- Prompt: are you the homeowner? Press 1 for yes, 2 for no
- Caller presses 1
IVR time varies wildly — 5 seconds for a simple geo-capture, 20+ seconds for multi-step qualification trees. This is where most caller time goes, not the auction. (If you're worried about IVR length hurting conversion, see how to A/B test IVR scripts.)
When IVR completes, the platform has a qualified lead record:
{
"call_id": "vc_8f2a9d4c7b",
"caller_number": "+16025551234",
"caller_geo": "Phoenix, AZ 85028",
"intent": "emergency_plumbing",
"homeowner": true,
"traffic_source": "google_ads",
"campaign": "plumbing-phoenix-emergency",
"ivr_duration_ms": 9420,
"timestamp": "2026-07-16T10:14:33-07:00"
}
That payload is what buyers will bid on.
Phase 2: Ping Fan-Out (0-5ms from IVR completion)
The platform fires simultaneous HTTP POST requests to every buyer endpoint configured in the ping tree. "Simultaneous" means within the same tick — most implementations use async I/O to fan out in under 5ms.
Each buyer receives the lead payload. Some platforms include a bid_floor field telling buyers the minimum acceptable bid; others leave this opaque.
This is the "ping" in ping tree. You're pinging multiple buyers with the same lead data at the same time.
Buyer count matters. More buyers means more competition, which generally lifts winning bids. But more buyers also means more endpoints to manage, more API integrations, and more chances for slowpokes to clog the system. A reasonable range is 5-12 active buyers per vertical. Under 5? Not real price discovery. Over 15? Probably deadweight.
Phase 3: Buyer Response Window (0-400ms from ping)
Buyers have a fixed window to respond — typically 200-400ms. This is non-negotiable. Callers won't wait.
A buyer's response is simple:
{
"accept": true,
"bid": 67.00
}
Or:
{
"accept": false,
"reason": "at_capacity"
}
Or — most painfully — nothing. A timeout.
What happens inside those 200ms on the buyer side:
- Buyer's API receives the POST (5-20ms network)
- Internal logic evaluates: Do we want Phoenix plumbing right now? (5-50ms)
- Capacity check: Are agents available? (1-10ms)
- Bid calculation: What's this call worth to us? (10-50ms)
- Response sent (5-20ms network)
A well-tuned buyer API responds in 80-150ms. A slow one takes 300-500ms. A broken one times out entirely.
The timeout is lethal. If your bid timeout is 300ms and a buyer's P95 latency is 320ms, they'll miss 5%+ of auctions even when their system is "working." Monitor buyer response times obsessively. A $75 bidder who times out 30% of the time is worth less than a $55 bidder who responds in 100ms every time.
Phase 4: Winner Selection (1-5ms)
Once the bid window closes, the platform ranks responses:
- Filter out declines and timeouts
- Filter out bids below floor price
- Sort remaining bids by price (descending)
- Winner = highest bid
Ties are rare (bids include cents), but platforms typically break ties by response time — faster bidder wins.
The selection logic itself is trivial. The complexity is in the timeout handling. What if Buyer B's response arrived at 310ms and your timeout is 300ms? Most platforms treat this as a timeout — they can't wait to see if something arrives late, or the whole system slows down. Some platforms have "late bid" grace periods of 50-100ms. Know your platform's behavior here; it affects which buyers to keep.
Phase 5: Call Transfer (5-200ms)
The platform bridges the caller to the winning buyer's phone system. This involves:
- Platform signals the winner: "You won, incoming call"
- Platform initiates the transfer to winner's phone number or SIP endpoint
- Caller hears ringing
- Buyer's agent picks up
Transfer time depends on whether the buyer is receiving via PSTN (regular phone number) or SIP. PSTN adds carrier latency — 100-200ms. SIP can be under 50ms.
Total elapsed time from IVR completion to the buyer's phone ringing: roughly 300-600ms. The caller heard hold music or a ring tone. They have no idea.
Floor Prices and Fill Rate: The Core Tradeoff
The floor price is the minimum bid you'll accept. Set it at $50, and a $48 bid fails — even if it's the highest bid received.
Floor setting is where operators make or lose money.
Too high: Fill rate tanks. If your floor is $60 and buyers are bidding $52-58, every call fails to fill. You're routing to fallback (lower payout) or losing calls entirely.
Too low: You fill everything but leave money on the table. If buyers would bid $65 but your floor is $40, you're accepting $42 bids that should have been $65.
The math is tricky because buyers adjust to floors. If they know your floor is $50, they'll bid $51 instead of $65 when they can. But if floors are too high, they stop integrating entirely. Game theory, basically.
Most operators start with their best direct-routing payout minus 10-15% as a floor, then adjust weekly based on bid distribution. Your platform's bid reporting should show you the spread — what bids are coming in, how many clear floor, what the unfilled calls look like. Use the data.
Fill rates vary by vertical. Home services tends to fill more easily than legal intake, where floors are higher and buyers pickier. Medicare during AEP can swing wildly by week.
What Happens When Things Break
Real-time systems fail in interesting ways. Here's what to watch for.
Buyer API outage. One buyer's endpoint returns 500 errors for an hour. They miss every auction. Your fill rate drops by whatever percentage of bids they represented. Solution: monitor buyer health automatically, pause endpoints that error repeatedly, alert on anomalies.
Network partition. Your platform can't reach Buyer B's API due to routing issues. Looks like timeout from your side; Buyer B has no idea. Rare but happens. Distributed systems are hard.
Bid floor misconfiguration. Someone fat-fingers the floor from $50 to $500. Nothing fills. Fallback routing handles the calls — at much worse economics — while you figure out why metrics cratered.
IVR failure. The IVR crashes mid-call. Caller data is incomplete. Platform pings buyers with partial payload. Some buyers decline because required fields are missing. Fill rate drops. Root cause: a bad deploy to the IVR system, not the ping tree itself.
Timeout cascade. One buyer's API suddenly takes 800ms instead of 150ms. They time out. But their slow responses are still hitting your system, consuming connections, adding latency. Other buyers start timing out too because the overall system is degraded. Solution: aggressive timeouts with circuit breakers — if a buyer times out 5x in a row, temporarily stop pinging them.
The common thread: most RTB failures look like "fill rate dropped" on the dashboard. You have to dig into per-buyer metrics to find root cause. Annoying. But that's distributed systems for you.
Advanced: Multi-Tier Auctions and Fallback Chains
Simple ping trees have one tier: all buyers pinged simultaneously, highest bid wins.
Real deployments usually have multiple tiers:
Tier 1: Premium buyers. High bids, but picky. Might only accept 40% of pings. Tier 2: Mid-tier buyers. Solid payouts, higher acceptance rate. Tier 3: Backup. Lower fixed payout, takes everything.
If Tier 1 returns no bids above floor, the call cascades to Tier 2. If Tier 2 fails, Tier 3.
This is still "real-time" — each tier runs its own 200-400ms auction — but it adds latency. A 3-tier system with 300ms timeouts per tier could theoretically take 900ms before reaching fallback. In practice, most calls fill in Tier 1 or 2.
Why tier instead of pinging everyone simultaneously? Some premium buyers won't participate in pools with low-quality bidders. They want right-of-first-refusal. The tiered model accommodates this while preserving RTB economics.
For simpler setups, a single-tier ping with a fixed-payout fallback buyer is enough.
Compliance Note: Who Sees the Data
Here's something most RTB explainers skip.
When you ping 6 buyers with caller data, all 6 receive that data — phone number, geo, intent. Only one wins the call. But the other 5 now have the lead.
That creates consent exposure. If your consent language only names one business and not a network of partners, a losing bidder who later calls that number may not have valid TCPA consent.
Solutions:
- Update consent language to explicitly cover data sharing with multiple potential providers
- Use anonymized pings (hash the phone number) for bid requests, reveal only to winner
- Work with buyers who contractually agree not to contact non-won leads
The legal nuance is beyond this guide, but if you're running RTB in regulated verticals (Medicare, legal), get compliance review.
Common Mistakes in RTB Setup
Not configuring fallback. Floor too high, no bids qualify, call goes nowhere. Caller hears silence. You just burned a lead you paid to acquire. Always set fallback — even if it's just "route to voicemail and callback queue."
Ignoring buyer latency. A buyer bidding $70 but timing out 25% of the time is worse than a buyer bidding $60 with 100ms P50 latency. Monitor and cull slow endpoints.
One-size-fits-all floors. Phoenix HVAC at 2pm is a different market than Detroit HVAC at midnight. Segment floors by geo, time-of-day, traffic source. The same $55 floor might be too low for Phoenix daytime and too high for Detroit overnight.
Running RTB where buyers want exclusivity. Legal intake is the classic mistake. PI firms paying $150+ per signed retainer want exclusive leads. If they know the same data went to three competitors, they'll either bid lower or walk entirely. Know your vertical's dynamics.
Not A/B testing. Flip to RTB, celebrate the higher average payout, ignore the fill rate drop. Net-net you might be losing money. Run controlled tests: 50% RTB, 50% direct. Measure everything.
Overthinking the platform choice. Look, VeloCalls, Ringba and similar platforms all run ping trees. The RTB mechanics are nearly identical. Pick one that fits your budget and move on. Plenty of people spend months evaluating platforms and zero months actually optimizing their buyer pool. That's backwards.
For broader call routing patterns, see call routing best practices.
Frequently Asked Questions
How fast does the real-time call bidding process actually run?
The entire auction — from ping broadcast to winner selection — typically completes in 200-400 milliseconds. Add IVR qualification time (usually 5-15 seconds depending on prompts) and carrier handoff (50-150ms), and the total pre-connect time runs 6-16 seconds. The caller hears ringing or hold music during the auction phase; they don't know bids are flying.
What happens if no buyer bids above the floor price?
The call fails to fill and routes to your fallback logic. Options include a lower-tier backup buyer at a fixed payout, a voicemail-to-callback queue, or a polite disconnect message. Never leave calls hanging with silence or error tones — configure fallback routing before you go live.
Can a buyer win the auction but reject the call after seeing more data?
Depends on the platform and buyer agreement. Some setups allow post-bid rejection within a short window after transfer, but this hurts fill rate and caller experience. Most operators negotiate contracts that penalize high reject rates. If a buyer consistently accepts bids then rejects calls, remove them from the pool.
How do I know if real-time bidding is working better than my old direct routing?
Run a 30-day A/B test. Split traffic 50/50 between ping tree and direct. Measure three things: average payout per billable call, fill rate, and caller abandonment rate. In commoditized verticals, a working ping tree should lift average payout. If fill rate drops more than 5 points or abandonment spikes, your buyer pool needs tuning.
Try VeloCalls for Your Vertical
Call tracking and pay-per-call routing platform built for HVAC, plumbing, roofing, PI lawyers, Medicare brokers, and insurance. Smart routing, real-time bidding, visual IVR builder, AI conversation intelligence. Per-minute pricing — Managed starts at 4¢/min, BYOC at 2¢/min, both drop as you scale.