How Many Staff Keep Waits Short? Erlang C, Overload and Little’s Law

The problem: random calls and a busy crew

Picture a crew of quality inspectors on a factory floor. Mechanics call for an inspection when a job is ready. The calls come at random: three in ten minutes, then none for half an hour. Each inspection takes 20 minutes on average, but some take five and some take an hour. The supervisor’s question is simple: how many inspectors does it take so almost no call waits too long?

Here’s the trap: the average workload looks fine. In the lab’s starting setup, 12 calls an hour at 20 minutes each add up to 4 inspectors’ worth of work. With 5 inspectors, the crew is busy only 80% of the time. Yet only about 74% of calls are answered within 15 minutes, and one call in ten waits more than half an hour. A sixth inspector lifts that to about 94%. Random calls bunch up, and a crew with little slack can’t clear one bunch before the next one arrives.

I built the lab so you can see that happen. You set the demand, the time per inspection, the crew size and the target wait. The lab shows the share of calls answered in time, called the service level. It also shows the average wait and the fewest inspectors who answer 90% on time.

The model

The lab uses the standard textbook model for this, the M/M/c queue. Calls arrive at random, at an average rate λ (the Greek letter lambda). This kind of pure randomness is called a Poisson process. Inspection times also vary at random around their average, 1/μ. Here μ (the Greek letter mu) is how many inspections one inspector finishes in a given stretch of time, on average. This kind of random job time is called exponential service. The c is the number of inspectors, who are all alike and work from one shared line. Nobody gives up, and there’s no limit on how many can wait. Utilization, the share of time the inspectors are busy, is ρ = λ/(cμ). That’s the calls coming in, divided by how many the whole crew can handle.

First, can the crew keep up?

If calls arrive at least as fast as the crew can clear them, then ρ ≥ 1. The line never settles down. It keeps growing, so there’s no steady average backlog to report. So for a crew that’s too small, the lab never shows a normal-looking service level. It shows waits as unbounded, meaning they have no limit. It counts the service level as 0 in the numbers and the staffing chart. On the surface, it drops those spots to a floor marked “too few staff” (ρ ≥ 1). And when it looks for the fewest staff needed, it only searches crews big enough to keep up.

Erlang C: the chance of waiting

When the crew can keep up, a formula called Erlang C gives the chance that a new call has to wait at all. Call that chance C. The chance of waiting longer than a target time t is P(Wq>t)=C exp[−(cμ−λ)t]. That chance shrinks fast as t grows, and faster still when the crew has more spare capacity. So the service level for target t is 1 minus that chance. The average wait and the average line length can then be cross-checked with Little’s Law, Lq=λWq. In words, the average number waiting equals the arrival rate times the average wait.

What to watch

Arrival rate, inspection time, crew size and target wait together set the utilization and the service level. The key thing to watch is what happens as ρ gets close to 1. Crowding doesn’t grow steadily there. It shoots up. So the average busy time alone can’t tell you whether you’ll hit your service-level target.

How I check it

Any setup with ρ≥1 must be flagged as unstable, because the crew can’t keep up. Adding one more identical inspector must never make the formula’s service level worse. As calls (λ) drop toward zero, waiting should drop toward zero too. And Little’s Law has to make Lq and Wq agree, with both in the same time units.

Where the model falls short

Real inspection crews and help desks may not fit the model. Maybe not everyone works from one shared line. Maybe job times don’t follow the exponential pattern. Calls might come faster at some hours than at others, or the staff might not be interchangeable. Skills, travel, priorities, breaks and demand that shifts through the day are all reasons to step up. That means moving to a more detailed formula, or to a discrete-event simulation that plays out every call one at a time.