Erlang C vs. Little’s Law: Staffing a Waiting Line Without a Full Simulation
Two classic formulas give a quick first guess at how many people it takes to answer most requests on time. You can use them before anyone builds a detailed simulation.
The problem: inspection requests
Picture a factory floor. When mechanics finish a job, they post an inspection request on a callboard, a shared list of work waiting to be checked. Several quality inspectors (QA, for quality assurance) work through those requests at the same time. The goal isn’t just to keep the inspectors busy. It might be to answer 90 percent of requests within 15 minutes. That’s the same shape as a call center. Requests show up at random times and wait for the next free inspector who’s qualified to do the check.
A discrete-event simulation is a step-by-step computer model of the floor. It can include real details: work areas, rush jobs, walking time, breaks, who’s trained for what, batches, and demand that changes through the day. But first, a queueing formula, math that predicts how a waiting line behaves, can do a lot. It shows roughly how big the team needs to be. It warns you when your numbers would make the line grow forever. And it gives a staffing estimate you can defend.
What Erlang C works out
Erlang C is a formula for a waiting line with a few simple assumptions. Requests arrive at random, at a steady average rate (called Poisson arrivals). Job times are random too: most are short and a few run long (an exponential spread). There are c identical inspectors, called servers, all working from one shared line. The line has no size limit, and nobody gives up and leaves. Experts write this setup as M/M/c. Now a few names. λ (lambda) is the arrival rate, like requests per hour. μ (mu) is the service rate, the jobs one inspector can finish per hour. The offered load a = λ/μ is how many inspectors’ worth of work keeps coming in. Utilization ρ = λ/(cμ) is the share of time the inspectors are busy. If ρ is one or more, work arrives at least as fast as the team can finish it. Then the line keeps growing, and the wait never settles down.
The main Erlang C formula, C(c,a), gives the chance that a new request has to wait at all. For a goal like ours, a second formula matters more. It gives the chance that the wait in line, Wq, is longer than some time t: P(Wq > t) = C(c,a) exp(-(cμ-λ)t). In words, the chance of a long wait shrinks fast as t grows. It shrinks faster when the team has more spare capacity, cμ-λ. Flip it around and P(Wq ≤ t) is the share of requests that wait t or less. So you can try bigger and bigger teams and stop at the smallest c that meets your goal. For example, that could be 90 percent answered within 15 minutes.
What Little’s Law works out
Little’s Law is L = λW. In words: the average number of things inside a system (L) equals the rate they come through (λ) times the average time each spends inside (W). Think of a coffee shop. The more people walk in each minute, and the longer each one stays, the more crowded it gets. Applied to just the waiting line, it reads Lq = λWq. It holds over the long run for a very wide range of systems, once things settle into a steady pattern. Unlike Erlang C, it doesn’t need random Poisson arrivals or exponential job times.
But because it works almost everywhere, Little’s Law can’t answer the staffing question on its own. Say you know λ and you want a certain W. L = λW doesn’t tell you how many inspectors it takes to get that W. It also can’t tell you what share of requests get answered within 15 minutes. Erlang C describes how the line actually behaves. Little’s Law is more like a bookkeeping rule: what goes in has to come out. That makes it a great sanity check.
Why an average isn’t a 90 percent goal
An average wait of ten minutes doesn’t mean 90 percent of requests get answered within fifteen minutes. A few very long waits can hide behind a nice average. A goal like that is about the whole spread of wait times, not just the average. This matters a lot on a real floor. As the inspectors get close to busy all the time (utilization near one), waits don’t grow steadily. They shoot up.
For the inspection example, I’d use Erlang C to estimate staffing for the 90%-within-15-minutes goal. Then I’d use Little’s Law to double-check the average line length and time in the system that go with it. I’d also set the formula’s inputs from real data: how requests actually arrive, and how long inspections actually take. The formula is a starting point, not the final truth.
Other queueing formulas
Erlang C is just one tool in a bigger toolbox. In the shorthand, the first letter describes arrivals and the second describes job times. M means random in the Poisson and exponential way, and G means general, so any pattern. The last part is the number of servers. M/M/1 is the basic model with a single server. M/M/c handles several servers. Erlang B is for systems with no waiting room, where a request that finds everyone busy is simply lost. Erlang A adds people who run out of patience and leave. M/G/1 lets job times follow any pattern. Its Pollaczek–Khinchine formula shows exactly how uneven job times make waits longer. Kingman’s formula gives a really useful estimate for one server with any pattern, G/G/1. It uses how busy the server is, plus how much arrivals and job times vary (their coefficients of variation).
When there are several servers and job times aren’t exponential, an estimate like Allen–Cunneen can be closer to reality than Erlang C. Queueing networks model several connected stations, where one line feeds the next. Priority queues handle requests that don’t all get the same treatment, like rush jobs that go first. Finite-source and finite-capacity models matter when only so many people can send requests, or there’s only so much waiting space. All of these sit in a useful middle ground. They do more than simple flow rules like Little’s Law, and less than a full discrete-event simulation.
When to move up to a full simulation
Erlang C starts to miss the mark when real life gets messier. Maybe requests pour in during one shift and trickle in during another. Maybe inspectors aren’t interchangeable, or some requests need a certain qualification or work area. Walking between jobs might take real time. Rush jobs might interrupt ordinary work. Job times might be far from exponential. Or inspectors might spend a lot of time on work outside the line. A simulation can build in all of those things directly.
So a good approach works in layers. Start with Little’s Law to check that the flow adds up. Use a queueing formula for a quick staffing number, and to see how much it moves when your inputs change. Move to a discrete-event simulation when the floor’s details really change the decision. On top of either one, an optimizer can search for the best staffing pattern, schedule or set of assignments. The goal isn’t to use the fanciest method. It’s to use the simplest model that still captures what matters for the decision.