adsoraChoose the event each cap counts
A ping count, accepted-lead count and dollar budget limit control different things. Label the event explicitly. If the business wants to buy no more than a certain number of leads, a limit on incoming pings will not describe that purchase ceiling. Keep the platform’s terminology beside your internal definition.
Confirm how rejected posts, approved credits and repeated requests affect the count. A credited lead may or may not reopen capacity, depending on the system and agreement. Decide the intended behavior before launch and test the actual configuration rather than inferring it from the number shown on a dashboard.
Place limits at the levels that own capacity
| Level | Question to answer |
|---|---|
| Company | What is the total purchase or budget ceiling? |
| Branch | How many new inquiries can this team handle? |
| Trade | Does this crew have capacity for the requested work? |
| Source | How much of the pilot may come from this supplier? |
| Time period | When does the counter reset, and in which timezone? |
Document which rule wins when several apply. For example, a branch might remain below its daily limit while the company budget is exhausted. The receiver needs a predictable outcome, and the seller needs a useful reason for the rejection. Avoid separate spreadsheets that disagree with the active platform settings.
A daily limit does not spread delivery across the day
Consider a hypothetical branch that can accept 30 leads in a day but cannot call 30 new homeowners at once. A daily cap alone permits a burst at opening time. If the platform supports finer pacing controls, configure and test them. Otherwise agree a delivery schedule or a smaller initial limit with the source.
Estimate capacity using the receiving team’s actual backlog and staffing. Include work already in the queue. Watch how long newly accepted records wait for assignment and first attempt. If that delay grows, increasing the cap can add more unworked inquiries without helping the pilot answer whether the source fits.
Check what happens between ping and post
In a two-step purchase, capacity can change after the ping. LeadConduit’s documented real-time bidding evaluates volume-cap status at the ping stage, but your connection still needs agreed final acceptance behavior. Ask whether capacity is reserved, when it is consumed and what happens when simultaneous posts reach the last available slot.
Test the edge of a cap with synthetic requests in the approved environment. Inspect both response bodies and the final count. A dashboard that refreshes later is insufficient evidence for how concurrent requests are controlled. Get the platform owner involved if you cannot establish the behavior from the current specification.
Give someone the authority to pause and resume
Name a buyer who can reduce intake when a branch closes, a queue fails or staff are unavailable. Define whether a pause stops all delivery or one market, trade or source. Tell the seller how long a confirmed pause takes to apply and how records already in flight will be handled.
Test pause and resume before launch, including the timezone used for scheduled changes. On resumption, inspect the first accepted records and the queue backlog. Record the effective time in the operating log so later volume changes can be explained.