Erlang B vs Erlang C: Which Formula Do You Need?
Erlang B sizes trunk lines where blocked calls are lost. Erlang C staffs call centers where callers queue. Pick the wrong one and your capacity plan will be wrong.
> **Quick Answer:** Use Erlang B when blocked calls receive a busy signal and are lost. Use Erlang C when callers wait in a queue. The two formulas model fundamentally different systems and produce different results for the same traffic load.
Agner Krarup Erlang published his foundational work in 1917, and a century later his formulas remain the backbone of every telecom capacity plan and call center staffing model in the world. But Erlang B and Erlang C solve different problems. Confusing them — or using one where the other is correct — leads to either wasted infrastructure spend or chronic service failures.
Here's exactly how to tell them apart and when to use each.
The Core Difference: Lost Calls vs. Waiting Calls
The distinction comes down to what happens when all circuits or agents are busy.
In an **Erlang B system**, a call that arrives when all resources are occupied is rejected. The caller receives a busy signal, the network "loses" the call, and the caller must try again later. The call is gone. This is called a *loss system* or *blocked-calls-cleared* model.
In an **Erlang C system**, a call that arrives when all agents are busy joins a queue and waits. Nobody is turned away — they just wait. This is called a *delay system* or *blocked-calls-delayed* model.
That single behavioral difference drives completely different mathematics, different capacity requirements, and different KPIs.
When to Use Erlang B
Use Erlang B for any system where calls are blocked rather than queued:
The key output from Erlang B is the number of trunks needed to keep the blocking probability at or below your Grade of Service target. A P.02 target (2% blocking) is the ITU-T standard for general business telephony. Emergency services plan to P.001 or stricter.
When to Use Erlang C
Use Erlang C for any environment where callers wait rather than receiving a busy signal:
The key outputs from Erlang C are the number of agents needed to hit your service level target (typically 80% of calls answered within 20 seconds, written as 80/20) and the resulting agent occupancy rate. [Try our Erlang C calculator](/erlang-calculator) to run these numbers for your contact center.
A Worked Example: Same Traffic, Different Results
Let's run the same traffic parameters through both formulas to show the difference.
**Input:**
- Calls per hour: 360
- Average call duration: 180 seconds
- Traffic intensity: (360 × 180) / 3600 = **18 Erlangs**
**Erlang B result** (target: 2% blocking):
- Required trunk lines: **24**
- Actual blocking probability: 1.8%
**Erlang C result** (target: 80% answered in 20 seconds, AHT = 180s):
- Required agents: **26**
- Service level: 80.3%
- Agent occupancy: 69.2%
For 18 Erlangs, Erlang B needs 24 trunks and Erlang C needs 26 agents. The numbers are similar here, but at higher traffic loads and stricter service level targets, the gap widens — especially because Erlang C results are extremely sensitive to the ratio between traffic intensity and agent count near the unstable threshold.
The Instability Trap in Erlang C
One critical difference: Erlang C becomes mathematically unstable when agent count equals or falls below traffic intensity. If you have 18 Erlangs of traffic and only 18 agents, the queue grows without bound — wait times approach infinity. You must always have more agents than your traffic intensity in Erlangs.
Erlang B doesn't have this problem. With the same number of trunks as Erlangs, you still get finite (though high) blocking probabilities. You'd just block a lot of calls.
This instability is why call center staffing is more sensitive to errors than trunk planning. Undersizing a trunk group by 2 circuits increases your blocking from 2% to maybe 5%. Undersizing an agent pool by 2 people during peak hour can cause queues to spiral out of control.
What About Erlang A and Other Extensions?
For completeness: **Erlang A** (also called the Engset formula for finite sources) extends Erlang B to situations where the caller population is small and finite — relevant when your source population is 50 users or fewer. For most enterprise and carrier applications, Erlang B with an infinite source assumption is accurate enough.
There are also extended queuing models (M/D/c, M/G/c) for situations where call duration doesn't follow an exponential distribution. Erlang C assumes exponentially distributed service times. If your AHT is highly predictable (say, a scripted 3-minute call), M/D/c gives more accurate results. But Erlang C remains the industry standard precisely because it's conservative — it slightly overestimates staffing requirements when service times are more predictable, which gives you a buffer.
How to Choose in Practice
Ask yourself one question: **"What happens when all my resources are busy?"**
- Caller gets a busy signal, reorder tone, or 503 SIP error → **Erlang B**
- Caller waits in a queue or on hold → **Erlang C**
If your system does both — some calls queue briefly then overflow to a secondary group or voicemail — model the primary handling with Erlang C and size the overflow trunk group with Erlang B.
Our [Erlang calculator](/erlang-calculator) handles both formulas. Select your mode, enter your traffic parameters, and get your trunk or agent count in seconds. For more on sizing SIP trunks specifically, see our [SIP trunk sizing guide](/blog/how-to-calculate-trunk-lines).