A buyer can be active, funded, and interested in more calls while still being unavailable for the next call.

That is the operating problem caps, schedules, and concurrency are meant to solve.

These controls are often grouped together because all three can stop a call from routing. But they answer different questions:

A schedule asks: Is this target open right now?
A cap asks: Has this target already received enough volume for the period?
A concurrency limit asks: Is this target handling too many calls at this exact moment?

Those are not interchangeable questions.

A buyer may be open and under its daily cap but already have every agent occupied. Another buyer may have plenty of agents available but be closed for the day. A third may be open with available agents but have reached a test cap or monthly budget limit.

If the routing system treats all of those situations as simply “buyer unavailable,” the operation loses useful information. If it ignores any of them, good calls can be sent into a buyer path that cannot handle them.

Serious pay-per-call routing needs to evaluate time, accumulated volume, and simultaneous load separately.

Call volume is not the same as call capacity

Buyers often describe demand with a total-volume number:

“We can take 100 calls per day.”

That sounds clear. It is not enough to route a live call.

The statement does not explain:

Which hours the buyer is open.
Whether the 100 calls can arrive evenly or in a morning burst.
How many agents are available at one time.
Whether ringing calls occupy capacity.
Whether the cap counts routed, connected, qualified, or billable calls.
Whether all sources share the same cap.
Whether weekends follow the same rules.
Whether the buyer can accept calls after a campaign, team, or target reaches its own limit.
What happens when the buyer is temporarily understaffed.
Whether the buyer wants overflow routed elsewhere.

A daily appetite is a commercial estimate.

Live capacity is an operating condition.

That difference is one reason more calls are not always better calls. Extra volume helps only when the buyer can answer, handle, qualify, and economically support it.

Routing controls turn a broad volume promise into narrower decisions that can be evaluated one call at a time.

What a call cap controls

A call cap limits accumulated activity over a defined period or scope.

Common examples include:

Ten calls during a new-source test.
Twenty calls per hour.
One hundred calls per day.
Two thousand calls per month.
Fifty calls from a specific publisher source.
A separate cap for a state, vertical, campaign, or buyer target.
A budget-based limit that stops routing when the buyer no longer has enough available spend.

A cap is useful because buyers do not have unlimited staffing, budget, or tolerance for operational uncertainty. It provides a boundary.

But the number alone is not the whole rule.

A cap needs a period

“Cap: 100” is incomplete.

Is that 100 calls per hour, per day, per month, or over the entire test? When does the period reset? Which timezone controls the reset? Does a daily cap reset at midnight in the buyer’s timezone or the platform’s timezone?

These details matter because a routing system must make a deterministic decision at the moment a call arrives.

A cap needs a scope

A buyer-level cap can protect the buyer’s total volume, but it may be too broad for routing decisions.

Consider a buyer with three targets:

A senior sales team.
A new-agent training team.
An overflow partner.

The buyer may want 100 calls per day overall but only 20 calls to the training team. A single buyer-level cap does not preserve that distinction.

Useful scopes can include:

Buyer.
Campaign.
Target.
Source.
Source-to-target relationship.
Geography.
Traffic type.
Test cohort.

The narrower the scope, the more precisely the operation can control volume. The tradeoff is configuration complexity. A professional system should use the narrowest level that reflects a real commercial or operational difference without creating rules nobody can maintain.

A cap needs a counting basis

One of the most important questions is: what event consumes the cap?

Possible answers include:

Attempted: The call counts when it is routed or dialed.
Connected: The call counts when the buyer answers.
Qualified: The call counts when it meets a defined qualification rule.
Billable: The call counts when the buyer charge is earned.
Converted: The call counts when a later CPA outcome occurs.

Those bases produce different results.

Suppose a buyer has a daily cap of 50. The system routes 50 calls, but only 40 connect and 30 reach the required duration.

An attempted-call cap is full at 50 routes.
A connected-call cap has consumed 40.
A qualified-call cap has consumed 30.

None of those definitions is automatically correct for every campaign.

An attempted cap may protect agent attention and telephony load. A qualified cap may better reflect a buyer’s commercial demand. A billable or converted cap may fit a settlement model but may update too late to control a fast burst unless the system also reserves expected capacity earlier.

This is why routed, connected, qualified, and billable must remain separate statuses. The distinctions are explained in more detail in the difference between a routed call, a qualified call, and a billable call.

Hard caps and soft caps serve different purposes

A hard cap stops new routing when the limit is reached.

A soft cap warns operators or reduces priority without necessarily blocking the next call.

Hard caps are appropriate when exceeding the number creates a serious problem: budget exposure, contractual limits, staffing failure, or an intentionally narrow test.

Soft caps can be useful when the number is a planning threshold rather than an absolute boundary. For example, a buyer may prefer 80 calls per day but still accept a few more when the team is available.

The system should not silently treat a soft preference as a hard rejection—or a hard commercial limit as an optional warning.

What a schedule controls

A schedule determines when a buyer target is eligible to receive calls.

At minimum, a schedule should define:

Timezone.
Open and close times.
Days of the week.
Closed days.
Breaks or split shifts.
Holiday or temporary overrides.
After-hours behavior.

Contact-center systems commonly make operating hours and timezone part of the routing decision. Amazon Connect documents queue hours that can be checked before routing and adjusted for the configured timezone and daylight saving time. That is the same underlying principle a pay-per-call exchange needs: the destination’s local operating reality must be evaluated before the call is sent.

Timezone is part of the rule

“Open 9:00 a.m. to 5:00 p.m.” is incomplete without a timezone.

A publisher may operate in Pacific time, the exchange may store timestamps in UTC, and the buyer may staff agents in Eastern time. The routing decision still needs one authoritative timezone for the target.

Timezone mistakes can create calls that are:

Sent before agents arrive.
Blocked while the buyer is actually open.
Mishandled around daylight saving changes.
Routed according to the publisher’s clock instead of the buyer’s.
Counted in the wrong daily cap period.

A clean implementation can store timestamps consistently while evaluating schedule windows in the target’s configured local timezone.

Weekly hours are only the baseline

A normal schedule might say:

Monday through Friday: 9:00 a.m. to 6:00 p.m.
Saturday: 10:00 a.m. to 2:00 p.m.
Sunday: closed.

Real operations add exceptions:

The buyer closes early before a holiday.
A team meeting removes capacity for one hour.
The call center opens extended hours during annual enrollment.
A storm creates after-hours demand for restoration calls.
A licensed team is unavailable in one state even though another team remains open.
A target is paused for training, maintenance, or quality review.

If the only schedule is a static weekly grid, operators may need an emergency pause or dated override to handle those conditions safely.

Open hours do not prove agent availability

A schedule says when the target may operate.

It does not prove that agents are currently free.

A call center can be open at 2:00 p.m. while every eligible agent is already on a call. That is where concurrency becomes necessary.

What a concurrency limit controls

Concurrency is the number of calls simultaneously occupying a target’s live capacity.

For voice calls, concurrency is usually not about how many calls arrived during the hour. It is about how many calls are in flight now.

A target with a concurrency limit of four should not receive a fifth call while four capacity-consuming calls are active.

This sounds simple, but the operation must define when a call begins and stops consuming capacity.

Ringing calls may consume real capacity

A common mistake is to count only connected calls.

Imagine a target with two agents and a concurrency limit of two. Two calls are already ringing. Neither has connected yet. If the routing system sees zero connected calls and sends two more, four callers are now competing for two agents.

Even before connection, ringing calls may occupy:

An agent offer.
A queue position.
An IVR channel.
A destination line.
A reserved route.
The buyer’s attention window.

For that reason, a conservative call-routing model may count ringing and connected calls until the attempt reaches a terminal state. The exact policy should be explicit and tested.

Concurrency is not the same as hourly volume

A target can have low hourly volume and still hit concurrency.

Suppose three long calls arrive within five minutes and each lasts 25 minutes. A target with a concurrency limit of three is full, even though only three calls have arrived during the hour.

The reverse is also possible.

A target may handle 30 short calls during an hour without ever having more than two simultaneous calls.

Hourly caps measure accumulated volume.

Concurrency measures simultaneous load.

Both can be valid, and neither replaces the other.

A buyer may have ten agents but set target concurrency below ten.

Reasons can include:

Some agents handle other channels or campaigns.
Only part of the team is trained for the vertical.
Supervisors want room for organic or direct calls.
The buyer is testing a new source.
The intake process has a bottleneck after the initial answer.
The buyer wants to avoid queue buildup.
Staffing fluctuates during the day.
A destination or carrier has its own technical limit.

Modern contact-center tools treat available capacity as a routing input. Twilio TaskRouter, for example, lets operators configure task-channel capacity and stops creating new reservations when that capacity is unavailable. The specific implementation differs from pay-per-call routing, but the operating lesson is the same: a reachable destination should not automatically receive unlimited simultaneous work.

How caps, schedules, and concurrency work together

The controls become useful when they are evaluated together.

Consider a hypothetical insurance buyer with these rules:

Schedule: Monday through Friday, 9:00 a.m. to 6:00 p.m. Eastern.
Daily cap: 100 qualified calls.
Hourly cap: 20 attempted calls.
Concurrency limit: four in-flight calls.
New-source test cap: ten qualified calls.
Accepted geography: selected states.
Source A is enabled for the senior-team target.
Source B is not yet enabled.

A call arrives from Source A at 10:15 a.m.

The target is open. It has received 12 attempted calls during the hour, 44 qualified calls during the day, and currently has three calls in flight. The source is enabled and the geography is accepted.

The call may remain eligible.

Two minutes later, four calls are in flight. Another otherwise valid call arrives.

The buyer is still open. The hourly and daily caps are not full. But concurrency is full.

That next call should not route to the target merely because the buyer has “room” under its daily cap.

It may be held briefly, sent to another eligible target, returned as unavailable, or handled according to the campaign’s fallback policy. The correct fallback depends on the operation, but the concurrency decision should be clear.

At 6:05 p.m., the target may have no calls in flight and only 60 qualified calls for the day.

It is under cap and has concurrency available.

It is still closed.

The schedule controls the result.

A useful evaluation sequence

The exact technical order can vary, but a routing system generally needs to answer questions like these before committing the call:

Is the buyer and target active?
Is the source permitted for this buyer path?
Is the target open in its configured timezone?
Has an applicable call or budget cap been reached?
Is simultaneous capacity available?
Does the call match geography, traffic type, and other filters?
Is a valid route or reservation available?
Can the system commit the capacity decision safely?
What reason should be recorded if the target is excluded?

The first eligibility check is not always enough.

Two calls can evaluate the same remaining slot almost simultaneously. A serious implementation needs atomic reservation or admission behavior so both calls do not claim the final capacity. That is not a copywriting detail or dashboard feature. It is a live-routing correctness problem.

Bursts reveal weak routing controls

Average volume can hide burst risk.

A buyer may average eight calls per hour and still receive twelve calls in four minutes after an ad placement, email drop, weather event, or publisher optimization change.

Without concurrency and short-period caps, the routing system may send the entire burst because the buyer is under its daily limit.

The results can include:

More no-answers.
Longer ring or queue times.
More abandoned callers.
Shorter connected calls.
Rushed agents.
Lower conversion.
More disputes.
Publisher traffic judged unfairly.
Buyers asking for credits that routing controls could have prevented.

A daily cap controls the total.

It does not shape the arrival pattern.

Hourly caps, tighter test caps, concurrency limits, pacing, and fallback routing can help distribute or redirect volume more responsibly.

The cap should reflect the buyer’s real operation

A cap should not be copied from a sales conversation without operational review.

A better discussion starts with questions such as:

How many agents can take this exact call type?
How many are normally available by hour?
What is the typical connected call duration?
Does the intake team need wrap-up time?
Are agents handling other campaigns?
How much organic volume must remain protected?
What happens when calls queue?
How quickly does the destination answer?
What volume can finance support?
Which sources are already using the same capacity?
Is this a test or a mature campaign?
Does the buyer measure attempted, connected, qualified, or billable volume?

A rough theoretical calculation can be useful, but it should not be mistaken for a safe routing limit.

For example, four continuously available voice slots and a ten-minute average handling cycle imply a theoretical maximum of 24 completed cycles per hour. Real capacity will normally be lower because calls do not arrive evenly, handling times vary, agents take breaks, wrap-up work exists, and some capacity may need to remain available for other demand.

The safe setting should come from observed operations, not the cleanest spreadsheet result.

Test caps should be narrower than scale caps

A new source should rarely begin with the same limits as an established source.

Testing needs enough volume to learn, but not so much that an unclear caller path, routing mismatch, or capacity problem creates a large loss before anyone notices.

A controlled test can define:

A source-specific cap.
A target-specific cap.
A limited schedule.
A lower concurrency ceiling.
Accepted geographies.
A defined qualification rule.
Required source labels.
Review checkpoints.
Pause criteria.
Scale criteria.

This is part of evaluating a pay-per-call source before scaling it.

The goal is not to keep every source small.

The goal is to earn the right to increase volume with evidence.

Different targets need different controls

A buyer account should not automatically imply one shared operating profile.

One buyer may have:

A national call center.
A regional team.
Individual-agent destinations.
A weekend overflow target.
A Spanish-language target.
A high-intent sales team.
A lower-capacity training queue.
Separate fixed-bid and RTB endpoints.

Each target can have a different:

Schedule.
Timezone.
Cap.
Concurrency limit.
Geography.
Source eligibility.
Qualification rule.
Destination health pattern.
Fallback path.

Routing at the buyer level alone can hide those differences.

Target-level controls let the exchange ask whether this specific destination can receive this specific call now.

Common failure modes

One cap is used for everything

A single daily cap may be easy to configure, but it cannot express hourly bursts, target differences, source tests, or simultaneous load.

Concurrency is left unlimited

An unlimited setting may be acceptable for a destination that truly manages its own queue and has agreed to receive overflow. It should not be the accidental default for a small team.

The schedule uses the wrong timezone

The interface displays one timezone while the routing service evaluates another. Calls then route early, late, or across the wrong cap-reset boundary.

The cap basis is undefined

The buyer thinks the cap counts qualified calls. The exchange counts attempts. The publisher sees traffic stop earlier than expected. The problem surfaces as a volume or payout argument because the original rule was incomplete.

Ringing calls do not count against concurrency

A burst creates several pending calls before any connect. The system sees open capacity and over-routes.

Capacity is checked but not reserved

Two routing decisions read the same remaining slot and both proceed. The dashboard had a concurrency setting, but the live path did not enforce it safely.

Counter release depends on a perfect callback

A terminal call event is missed, and the slot never returns. Good systems need idempotent release behavior, timeout protection, and reconciliation rather than assuming every external callback will arrive exactly once.

Buyers change staffing without changing controls

The buyer says, “We are short-staffed today,” but caps and concurrency remain at normal levels. Operational communication must reach the routing configuration.

One source consumes the entire limit early in the day. Another approved source never gets a test. Source-level reporting and scoped caps may be needed to manage allocation fairly.

The interface and the live route disagree

A control shown in a portal is not valuable unless the routing path actually enforces it. Configuration existence, code existence, test coverage, portal exposure, and live operational use are different maturity states.

Reporting should explain why a call did not route

When a target is excluded, the reason should be recorded clearly.

Useful reason categories include:

schedule_closed
cap_reached
budget_exhausted
concurrency_limit
source_not_enabled
geo_filtered
target_inactive
destination_unhealthy
reservation_expired

These reasons are operationally different.

A publisher told only “no bid” or “buyer unavailable” cannot optimize intelligently. A buyer seeing only total missed volume cannot tell whether the problem is staffing, schedule configuration, budget, or traffic fit.

Clear reasons support better decisions:

Extend the schedule.
Add agents.
Raise or lower concurrency.
Change an hourly cap.
Move traffic to another target.
Pause a source.
Correct a timezone.
Repair a destination.
Adjust the source test.

A failed route with a reliable reason can improve the system.

A failed route without a reason becomes a blame conversation.

What buyers should review before increasing limits

Before raising a cap or concurrency limit, review:

Answer behavior

Answer rate by hour.
Ring time.
Queue time.
Abandonment.
Destination failures.
No-answer and busy outcomes.

Agent handling

Connected duration.
Qualification rate.
Conversion rate where available.
Wrap-up time.
Staffing by interval.
Performance by target or team.

Source behavior

Volume by source and sub-source.
Burst patterns.
Caller alignment.
Dispute rate.
Duplicate patterns.
Performance changes after creative or traffic shifts.

Financial behavior

Buyer price.
Publisher payout.
Qualified and billable counts.
Credits and disputes.
Spend against budget.
Margin effects without exposing confidential economics to the wrong party.

Routing behavior

Schedule exclusions.
Cap exclusions.
Concurrency exclusions.
Overflow performance.
Reservation failures.
Whether the live path matches the configured rules.

Increasing volume before reviewing those signals can turn a routing-control problem into a traffic-quality argument.

What publishers should understand

Publishers benefit when buyer limits are clear and honestly enforced.

A publisher should know, at an appropriate level:

When the buyer path is normally open.
Whether traffic is capped.
Whether a source is under a test limit.
Whether calls may be rejected because live capacity is full.
Which call statuses affect payout.
What happens when no target is available.
Whether the publisher should pace traffic or use an RTB ping before sending the live call.
How exclusion reasons appear in reporting.

Publishers do not need private buyer staffing details or protected destinations.

They do need enough information to avoid sending traffic into a path that cannot receive it.

A well-designed RTB or pre-call decision can help publishers evaluate availability before committing the live call. For a broader explanation, see Pay-Per-Call RTB Explained.

What a controlled call-flow setup looks like

A controlled setup does not simply enter high numbers into three fields.

It establishes:

Defined target hours and timezone.
Dated exceptions or a reliable pause process.
Clear hourly, daily, monthly, and test caps where needed.
An explicit counting basis.
A concurrency policy that defines which call states consume capacity.
Atomic admission or reservation for scarce slots.
Idempotent release when calls end.
Reason-coded exclusions.
Source- and target-level reporting.
Buyer-safe controls.
Publisher-safe feedback.
Monitoring for stale counters and destination failures.
A review process before limits are increased.

Not every campaign needs every control at maximum complexity.

A one-buyer test may start with a simple schedule, daily cap, and conservative concurrency limit. As sources, targets, budgets, and routing modes expand, the controls can become more specific.

The important point is that the operation can explain why the next call did or did not route.

How this fits Dependable Calls

Dependable Calls is being built around controlled, operator-led call flow rather than unrestricted routing.

The current application implementation includes buyer-target configuration for hourly, daily, and monthly caps, weekly schedules with target timezones, and concurrency controls. The routing eligibility layer is designed to distinguish schedule closures, reached caps, exhausted budgets, and concurrency limits as separate exclusion reasons. Buyer portal surfaces also expose target-level configuration for these controls.

That is meaningful implementation evidence.

It is not proof that every control has been validated under every live campaign condition. Dependable Calls remains a beta-stage operation, and code, tests, portal exposure, operational procedures, monitoring, and real partner usage must continue to be validated together.

The platform direction is straightforward:

A call should not route merely because a destination number exists.
A buyer should not receive more volume than the agreed rules allow.
An open schedule should not override full live capacity.
Available concurrency should not override a closed schedule.
A daily cap should not be used as a substitute for burst control.
Every exclusion should be explainable.
Every configuration change should be reviewed against actual buyer operations.

Caps, schedules, and concurrency do not create good call supply by themselves.

They create the boundaries that allow good call supply to reach a buyer under workable conditions.

That is the difference between forwarding calls and controlling call flow.

Need a more controlled call flow? Start a conversation with Dependable Calls.