Which Erlang? (and when none of them)
Erlang C, Erlang A, Erlang X — and the cases where the honest answer is none of them. Answer four quick questions about your channel and queue and you’ll get a recommended model, with the reasoning. The chooser encodes rules of thumb, not law: it will point you at the right starting model, but only your own data — abandonment rates, redial behaviour, interval volatility — can confirm the choice. If you want to see how the models behave before committing, play with the visual Erlang explorer.
The Erlang family assumes one contact per agent at a time, handled now. Concurrency and deferrable work each break that in a different way.
At very small scale, one sick day or one long call moves the answer more than the choice of formula does.
Retries feed load back into the queue, so a model that ignores them double-counts your failures as fresh demand — or misses them entirely.
Recommended starting point
Whatever the chooser says: compare the model’s predicted abandonment, ASA and occupancy against a few weeks of your own actuals before you bet the budget on it. A model that can’t reproduce last month shouldn’t be trusted with next quarter.
How this works
The classical Erlang formulae form a ladder of realism. Erlang C is the workhorse: random (Poisson) arrivals, a single skill, and callers with infinite patience — which means that under heavy load it overstates the agents you need, because real callers leave the queue. Erlang A adds caller patience and predicts abandonment alongside service level, usually returning a slightly lower requirement for the same target. Erlang X goes further still, folding in a finite number of lines (busy tones when all are full) and the redials that failed callers generate — a feedback loop the calculator solves by iteration.
But the whole family shares two assumptions that some channels simply break: one contact per agent at a time, and work that must be answered as it arrives. Chat concurrency breaks the first — an agent juggling three conversations is not three agents, and not one either — so chat needs a concurrency-aware approach (an adjusted-Erlang approximation, a birth–death model, or simulation). Email and back office break the second: when work can wait hours or days, there is no queue to model in the Erlang sense, and a straightforward workload model — volume × handle time ÷ productive hours, scheduled against the turnaround promise — is both simpler and more honest. And below about ten agents, every model’s precision is an illusion: the maths still helps, but it’s guidance, not gospel.