Running outbound calls at scale is not a dialling problem — it is a reputation problem. The moment a team moves from tens to thousands of calls per day, the question shifts from 'can we dial this number?' to 'will anyone actually answer?'

An outbound campaign manager is software that takes a list of phone numbers, dials each one systematically, records what happened, and surfaces the results — all while keeping your numbers from being flagged as spam. The hard parts are not the dialling itself; a SIP trunk and an API call can place a call in milliseconds. The hard parts are which number to dial from, when to dial, how fast, what to do when nobody picks up, and how to prevent your entire number pool from getting labelled Spam Likely by Tuesday afternoon.

This guide is a vendor-neutral walkthrough of how each of those five decisions works, what the trade-offs are, and how to configure them for a production campaign.

To understand which configuration knobs matter, it helps to see what actually happens between "I have a CSV of 10,000 phone numbers" and "the phone in someone's pocket rings."

1. Upload — a contact list (typically a CSV) is parsed and stored. Each row becomes one record with a destination phone number and per-contact metadata.
2. Schedule — the user sets when the campaign should start: immediately, or at a specified future time.
3. Promote — when the campaign becomes active, every contact is enqueued into a job queue.
4. Pace — a worker pulls one contact at a time and decides whether to dial it right now or wait. This is where the rotation, cap, and cooldown rules apply.
5. Dial — the worker selects a 'from' number from the pool, asks the SIP layer to place the call, and records the call UUID.
6. Hangup — when the call ends (answered, unanswered, busy, or failed), a webhook fires back to the campaign manager with the outcome.
7. Decide what's next — based on the outcome and the campaign's retry policy, the contact is either marked terminal or scheduled for a retry.
8. Complete — when no contacts remain in pending or retry-pending states, the campaign is marked complete.

Three companies — Hiya, First Orion, and TNS — operate the analytics platforms that mobile carriers use to decide how your call appears on a recipient's screen. Hiya powers AT&T's call labelling. First Orion powers T-Mobile's Scam Shield. TNS powers Verizon's analytics.

• Calls per number per day. A single phone number making 500+ outbound calls in 24 hours matches the statistical signature of a robocaller almost exactly.
• Burst patterns within a day. Fifty calls in sixty seconds from one number is dramatically more suspicious than fifty calls spread over an hour.
• Answer-and-hang-up rate. When recipients reject calls, analytics systems infer the calls were unwanted.
• Geographic mismatch. A number in one area code calling many recipients in a distant area code signals a spoofed-feeling call.
• Number age. Brand-new numbers with no history of normal use appear more suspicious.

Once a number earns a Spam Likely label, answer rates typically drop 40–70% overnight. The labelling is sticky and disputes require convincing three independent, proprietary AI systems — separately — that your traffic is legitimate.

Instead of dialling all calls from one number, a campaign manager maintains a pool of phone numbers — called DIDs — and rotates across them systematically. Three standard rotation policies exist:

• Round-robin — cycles through numbers in order. Produces perfectly even distribution. Right default for almost every campaign.
• Least-used — always selects the number used fewest times. Recovers gracefully when the pool changes mid-campaign.
• Random — picks uniformly at random. Same average distribution but can create uneven bursts. Right only for specific adversarial contexts.

Carrier analytics systems specifically watch 24-hour windows. A number placing 800 calls today and zero yesterday is far more suspicious than one placing 50 calls per day every day for a month.

A cooldown period means: after a number is used for one dial, it cannot be used again for at least N seconds. A 10-second cooldown across a 20-number pool gives 2 calls per second aggregate throughput — well under any reasonable daily cap, and the timing pattern appears naturally spaced to carrier analytics systems.

• Draft — created, no contacts uploaded yet.
• Ready — contacts uploaded, waiting for start.
• Running — actively dialling. Sub-states: active, idle, stalled.
• Paused — temporarily stopped — reason must be exposed: manual, window closed, pool exhausted, failures.
• Cancelled — terminal stop. Data preserved permanently.
• Completed — every contact reached a terminal state.
• Archived — hidden from default list views. Data fully preserved.

Campaigns are never hard-deleted. Every call placed carries the campaign ID. Hard-deleting orphans historical reports, audit trails, and billing reconciliation.

A 5,000-contact retention campaign for a SaaS business. Goal: complete within a standard work week without burning numbers.

This delivers 2,500 calls per day — the 5,000-contact list completes in 2 working days. Each number averages 100 calls per day, well under spam thresholds. Nothing rings outside business hours.

Building this from scratch is a multi-month engineering project with a long tail of edge cases that only surface in production. Vobiz ships with all of it built in — three rotation strategies, per-number caps, timezone-aware windows, configurable retry policies, account-wide concurrency gating, full state machine with explicit pause reasons, and permanent CDR preservation.

With ~80ms media latency, outbound reach across 190+ countries, and native integrations with Vapi, Retell AI, ElevenLabs, Pipecat, and more.