M/M/c Queues and the Erlang C Formula

A trading desk's execution support line receives calls from traders needing manual order intervention, arriving randomly, and handled by a pool of $c$ staff, each taking a random amount of time per call. Management wants to know: with $c=4$ staff, what fraction of calls have to wait at all, rather than being answered immediately? Adding staff clearly helps, but by how much, and is there a point of sharply diminishing returns? This is the classic M/M/c queue — Poisson arrivals, exponential service times, $c$ parallel servers — and its answer, the Erlang C formula, is one of the oldest and most widely used results in applied probability, dating to early telephone exchange design and still governing staffing decisions today.

An analogy: checkout lanes at a grocery store

A single checkout lane gets overwhelmed quickly once the store gets even moderately busy, because there's no flexibility — one slow customer backs up everyone behind them. Add a second lane, and a slow customer in one lane doesn't block a fast one in the other; the two lanes absorb random bursts by having idle capacity elsewhere at any given moment. This is the core benefit of "pooling": $c$ parallel servers handling one combined queue is dramatically more efficient than $c$ separate single-server queues each handling its own slice of the load, because pooling lets servers cover for each other's random slow moments. The Erlang C formula quantifies exactly how much pooling helps.

The formula, one piece at a time

Let $\lambda$ be the average arrival rate, $\mu$ be the average service rate per server, and $c$ be the number of parallel servers. Define the offered load $a = \lambda/\mu$ (in "Erlangs" — the average number of servers that would be busy with infinite capacity) and the utilization $\rho = a/c$ (must be below 1 for the queue to be stable). The Erlang C formula gives the probability an arriving customer must wait (finds all $c$ servers busy):

$$P(\text{wait} > 0) = \frac{\dfrac{a^c}{c!} \cdot \dfrac{1}{1-\rho}}{\displaystyle\sum_{k=0}^{c-1} \frac{a^k}{k!} + \dfrac{a^c}{c!}\cdot\dfrac{1}{1-\rho}}.$$

In plain English: the numerator represents the "weight" of all states where every server is busy (customers queue up behind a full bank of servers), and the denominator normalizes it against every possible state, from empty system to fully saturated with a queue. The result is a single probability between 0 and 1 — how likely a random arrival is to face any wait at all before being served, purely as a function of the offered load $a$ and the number of servers $c$.

Worked example 1: sizing the support desk

Suppose calls arrive at $\lambda = 8$ per hour and each staff member handles calls at $\mu = 3$ per hour on average (about 20 minutes each), so offered load $a = 8/3 \approx 2.67$ Erlangs. With $c=3$ staff, utilization is $\rho = 2.67/3 \approx 0.89$ — dangerously close to saturation, and the Erlang C formula gives $P(\text{wait}>0) \approx 0.76$: 76% of calls wait. With $c=4$ staff, $\rho = 2.67/4 \approx 0.667$, and the formula drops to $P(\text{wait}>0) \approx 0.44$ — adding just one more staff member (a 33% headcount increase) nearly halves the fraction of calls that wait at all, because utilization moved away from the steep, near-saturation part of the queueing curve.

Worked example 2: diminishing returns at c=6

Push further to $c=6$ staff with the same $a=2.67$: utilization drops to $\rho \approx 0.445$, and $P(\text{wait}>0)$ falls to roughly 0.09 — only 9% of calls wait. Going from $c=4$ to $c=6$ (a 50% headcount increase) cut the wait probability from 44% to 9%, a large absolute drop, but the marginal benefit per extra staff member is now much smaller than the jump from $c=3$ to $c=4$ was — comparing gains, $c=3\to4$ cut wait probability by 32 percentage points for 1 extra staff, while $c=4\to6$ cut it by 35 points but needed 2 extra staff. This illustrates the general shape of Erlang C: wait probability falls steeply as $c$ moves away from the saturation boundary ($\rho$ near 1), then flattens into diminishing returns once utilization is comfortably below it — telling a staffing manager roughly where "good enough" capacity lies.

What this means in practice

The Erlang C formula (and its refinements, like Erlang A which adds customer abandonment) underlies staffing decisions for any pooled-server system: execution support desks, market-making quoting engines that need enough parallel capacity to avoid queueing client orders, or cloud compute pools sized against a variable request rate. It's also directly relevant to understanding why pooling matters operationally — merging two separate, moderately-loaded queues into one combined queue with the same total server count structurally reduces average wait, without adding a single server, purely from the statistical smoothing pooling provides.