Why Channel Math Matters More Than It Used To
Every VICIdial or Asterisk admin eventually gets asked some version of the same question by finance or ops: "Why are we paying for 300 SIP channels when we only have 60 agents?" It's a fair question, and most of the time the honest answer is "because that's what worked last time we bumped the dial ratio and stopped getting complaints." That's not capacity planning — that's guessing with an expensive feedback loop.
Channel over-provisioning is one of the quietest cost leaks in outbound operations. Carriers price concurrent channels per-seat or in blocks, and every unused channel is money sitting idle 20 hours a day. Under-provisioning is worse: your dialer throttles pacing, your abandonment rate creeps toward the FCC's 3% ceiling, and agents sit in idle time waiting for connects that never arrive because the trunk choked upstream.
This post walks through the actual formula predictive dialers use to consume channels, how to size a trunk correctly, and — critically — how AMD accuracy changes the math more than most capacity planning guides admit.
The Core Formula
Concurrent channel demand for a predictive dialer isn't a fixed number — it's a function of four variables:
Concurrent Channels = Logged-In Agents × Dial Ratio × Burst Headroom
Where:
- Logged-in agents = agents actively on the campaign, not total headcount
- Dial ratio = calls placed per available agent (set by your dialer's pacing algorithm — VICIdial calls this
dial_levelor uses adaptive pacing) - Burst headroom = a multiplier (typically 1.15–1.30) to absorb pacing algorithm overshoot during answer-rate swings
A 60-agent campaign running a 3.5:1 dial ratio needs a baseline of 210 concurrent calls. Add 20% burst headroom and you're provisioning for roughly 250 channels at peak.
Worked Example
| Variable | Value |
|---|---|
| Logged-in agents | 60 |
| Target dial ratio | 3.5:1 |
| Baseline concurrent calls | 210 |
| Burst headroom (20%) | +42 |
| Recommended channel capacity | 252 |
That's the number you take to your carrier or SIP trunk provider — not "however many we had last quarter."
Erlang B Still Matters, But It's Not the Whole Picture
Traditional trunk sizing leans on the Erlang B formula, which was built for inbound call centers with relatively predictable call-arrival patterns. It calculates the number of trunks needed to keep blocking probability (the odds a call gets a busy signal) under a target threshold, usually 1%.
Erlangs = (Calls per hour × Average call duration in seconds) / 3600
For outbound predictive dialing, Erlang B undersells your real requirement because predictive pacing generates deliberate burst traffic — the dialer is placing calls faster than agents can absorb them, betting that a known percentage will go unanswered, hit voicemail, or ring out. That's the entire mechanic that makes predictive dialing efficient, and it's also exactly why static Erlang math falls short here. You need Erlang B as a floor, then layer the dial-ratio formula above it, then add burst headroom on top of both.
Where AMD Accuracy Enters the Equation
Here's the part most SIP capacity guides skip entirely: AMD accuracy directly changes how many channels you need to hit a given connect target.
Every call your dialer places occupies a channel from dial to disposition — including the 1.5 to 2.5 seconds most AMD engines need to classify the call as human or machine. That detection window is unavoidable overhead per call, whether the AMD is accurate or not. But the bigger cost is what happens when AMD gets the classification wrong:
- False positives (a live person is misclassified as an answering machine) get dropped or routed to a voicemail-drop flow instead of an agent. The channel-seconds spent reaching that person were wasted — no agent connect, no sale, no data collected. To hit the same number of live connects, your dialer has to place more calls, which means more concurrent channels at peak.
- Stock Asterisk AMD runs a 15–25% false positive rate. On a 60-agent floor dialing at 3.5:1, that's potentially dozens of real prospects per hour being silently discarded — and the channel capacity spent reaching them evaporates with nothing to show for it.
Run the numbers: if 20% of your live answers are misclassified and dropped, you need roughly 20% more dial volume to land the same number of agent connects. That's not a small rounding error in your channel math — it's the difference between provisioning 250 channels and 300, on carrier costs that scale directly with channel count.
Lower your AMD false positive rate to the 1–3% range and that inflation mostly disappears. You reach your connect target with fewer calls placed, which means fewer concurrent channels needed to hit the same throughput — or the same channel budget now supports meaningfully higher connect volume. This is the conversation we cover in more depth in our AMD false positive cost and ROI framework, which breaks down the per-agent-hour cost of misclassified answers.
Practical Sizing Checklist
Before you call your SIP trunk provider or renegotiate a channel block, work through this:
- Pull your real dial ratio from dialer logs, not the config default. VICIdial's adaptive pacing adjusts dial_level dynamically — check actual peak values over a rolling 2-week window, not the static setting.
- Separate campaigns by ratio. A 2:1 nurture campaign and a 5:1 cold list campaign have wildly different channel footprints. Size them independently, then sum peaks (accounting for whether campaigns run concurrently or in shifts).
- Audit your AMD false positive rate. If you don't know this number, that's the first gap to close — you can't size channels accurately while an unknown percentage of your dial volume is being wasted on misclassified live answers.
- Build in burst headroom, not steady-state average. Carriers bill you for what you provision, but under-provisioning during a Monday-morning volume spike costs you abandonment-rate compliance and agent idle time — both more expensive than a few extra channels.
- Re-run the math quarterly. Agent headcount, list quality, and AMD tuning all drift. A channel plan sized in January is stale by Q3.
What Over- and Under-Provisioning Actually Cost
| Scenario | Symptom | Cost |
|---|---|---|
| Under-provisioned | Calls queue at carrier level, pacing throttles, abandonment rate rises toward 3% FCC ceiling | Compliance risk, agent idle time, missed connects |
| Over-provisioned | Channels sit unused most of the day | Wasted carrier spend, no operational benefit |
| Correctly sized + high AMD false positive rate | Channels consumed reaching prospects who get misrouted as machines | Wasted channel-seconds, inflated "true" channel need, lower effective ROI per channel |
| Correctly sized + accurate AMD | Channel spend maps directly to real agent connects | Lowest cost per live connect |
The last row is the target state, and it's the one most capacity planning conversations miss because they treat AMD accuracy as a dialer-tuning issue rather than a line item in the trunk budget.
Tying It Together
SIP trunk sizing isn't a one-time setup task — it's a formula with moving parts, and AMD accuracy is one of the parts that gets ignored most often. If you've already gone through SIP trunking basics and failover and redundancy planning, capacity sizing is the next layer — and it's the one that shows up directly on your carrier invoice every month.
Before you renegotiate a channel block upward to compensate for missed connects, it's worth checking whether the real problem is AMD misclassification eating your dial volume rather than a genuine capacity shortfall. amdify.io replaces Asterisk's default AMD logic with a purpose-built AI model that drops false positive rates from the 15–25% range down to 1–3%, which means more of every channel-second you're already paying for actually reaches a live prospect and an available agent. See how amdify.io fits into your dialer stack.