System-wide vs campaign-lists scope for 24-hour limits

The 24-Hour Called Count Limit Scope has two values: SYSTEM_WIDE and CAMPAIGN_LISTS. SYSTEM_WIDE counts every attempt across the whole system. CAMPAIGN_LISTS counts only the attempts made inside the lists assigned to the current Campaign.

Why scope matters when Leads are shared

Many operations run more than one campaign against overlapping data. The same person might be in a sales campaign and a follow-up campaign at the same time. Scope decides whether those two campaigns share a single 24-hour tally or keep separate ones.

With SYSTEM_WIDE, every attempt anywhere on the box adds to the count. A number called twice by campaign A and once by campaign B has used three attempts toward the limit. This is the total a real person experiences, which is usually what a per-number rule is really asking about.

With CAMPAIGN_LISTS, the count is walled off to the lists tied to this campaign. Campaign A and campaign B each keep their own running totals. That can be useful for reporting per project, but it means a contact could be reached more times overall than any single campaign's limit suggests.

When CAMPAIGN_LISTS makes sense

CAMPAIGN_LISTS fits when campaigns truly do not overlap. If each campaign owns its own data with no shared numbers, walling the count to this campaign's lists is cleaner and avoids one busy campaign starving another's dialing. It is also reasonable when different campaigns legitimately have different limits and you do not want them bleeding into each other.

Just confirm the no-overlap assumption is real. Re-uploaded data and bought lists are how the same number quietly ends up in two places. If you are not sure, treat the overlap as likely. A second case where CAMPAIGN_LISTS helps is a busy box running many unrelated projects at once. Under SYSTEM_WIDE, a heavy campaign that calls a shared number repeatedly could exhaust the cap and quietly hold that number back from a lighter campaign that has barely touched it. If those campaigns are genuinely separate efforts that should not influence each other's pacing, the campaign-scoped count keeps them independent.

How the two scopes count a shared number

Picture one number that sits in both a sales campaign and a follow-up campaign, and a campaign limit of three. Under SYSTEM_WIDE, the third attempt blocks the number no matter which campaign placed the first two. Under CAMPAIGN_LISTS, each campaign tracks its own count, so the number could see up to three attempts from sales and three more from follow-up inside the same window. Same data, same limit number, very different real-world call volume. That gap is the whole reason scope exists, and it is the first thing to check when a number is being reached more often than you expected.

Choosing the scope

flowchart TD
  A[Pick the scope] --> B{Same numbers in multiple campaigns}
  B -->|Yes| C[Use SYSTEM_WIDE]
  B -->|No| D{Rule counts across all campaigns}
  D -->|Yes| C
  D -->|No| E[CAMPAIGN_LISTS is fine]

Scope and method work together. Scope sets how wide the count reaches; method sets whether you count by phone number or by lead. For the method side, read our piece on the PHONE_NUMBER vs LEAD method. The strictest combination, SYSTEM_WIDE with PHONE_NUMBER, caps a real number across the entire box.

Remember this is a pacing setting on top of your dial-method, not a screening list. It interacts with how each campaign assigns its lists and what feeds the hopper, but it never replaces DNC (do not call) work, your state-dnc files, or the national-dnc-registry. A number under the cap can still be off-limits for other reasons.

Because the right scope depends on the rule you must meet, confirm specifics with a telecom lawyer before relying on it. See our phone-based functions guide for the rest of the dialing controls. On VICIfast your dedicated box is live in under 40 seconds, so you can test SYSTEM_WIDE against real multi-campaign data without sharing a server; view pricing.