Staffing to a service level

At 11 a.m. the queue is eight deep and two of your five people are at lunch. Nobody planned it that way — but nobody planned against it either. You staffed to a number your reporting tool handed you: contacts per day, or heads on the roster, and hoped the day would cooperate. It didn't, because a daily total tells you nothing about whether anyone is free at the moment a customer needs them.

Staffing to a service level flips the question. Instead of "how many contacts will we get?" you ask "how many people need to be on at 11 a.m. so that 80% of customers reach us within 20 seconds?" That target — 80/20 — is where almost every team starts, and it's worth knowing up front that it rests on nothing.

So treat 80/20 as a default to argue with, not a law. A billing queue where every contact is anxious might justify 90/15; a low-stakes async channel can live happily at a far looser target. Pick it deliberately — service level is just those two numbers, a percentage and a time — because everything downstream is built on it.

From a target to a headcount

The tool that turns a service-level target into a number of agents is more than a century old.

Erlang C takes four things: how many contacts arrive in an interval, your average handle time, and the target — 80% in 20 seconds — and it returns the minimum number of agents that must be on the floor to hit it. You don't need to derive the formula. Free Erlang calculators are everywhere, and a WFM tool is mostly a wrapper around one. What you need to understand is the shape of what it tells you.

Because the shape is the whole lesson. Staffing and service level are not linear.

Add the first few agents and service level climbs fast; add more and each one buys less.

That steepness is why chasing a near-perfect queue is so expensive, and why you never staff to 100%. The other reason is the people. Run agents flat-out and occupancy — the share of paid time actually spent on contacts — pins to a ceiling.

Push past that and you don't get more throughput. You get a slower, more error-prone, faster-quitting team, which pushes volume back up and starts the loop again.

The agents Erlang gives you aren't the people you hire

Here's the step teams skip. Erlang C tells you how many agents must be handling contacts in an interval. It says nothing about breaks, coaching, meetings, sick days, or the Monday all-hands. That gap is shrinkage, and it is large.

So if Erlang says you need 24 agents on the floor and your shrinkage is 30%, you don't hire 24 — you divide by 0.7 and schedule about 34. Skip this and you'll be underwater every single interval while wondering why a "correct" calculation never holds up in real life.

Abandonment takes care of itself

One target is enough. Teams often try to manage abandonment rate as its own goal, but it isn't a lever you can pull — it's a consequence of the one you already pulled.

Staff to your service level and abandonment falls out the bottom; starve the queue and it climbs. Chasing an abandonment number directly, without a service level behind it, just produces firefighting. Watch it, benchmark it against teams your own size in the service-level benchmarks, but don't roster to it.

The spreadsheet version

You don't need WFM software for any of this. Pull a few weeks of volume broken out by interval — the shape of the day matters far more than the total, and getting that shape right is a forecasting problem, not a staffing one. Feed each interval's contact count, your real AHT, and your chosen target into any free Erlang calculator. Divide the answer by one-minus-shrinkage to get schedules. Then check the forecast against reality for a month and correct your inputs — actual handle time, actual shrinkage — until it stops surprising you.

That's the whole method: a target you chose on purpose, a formula from 1917, an honest shrinkage number, and the discipline to cover the peaks instead of the daily average. It won't be perfect. It will beat a headcount with nothing behind it, which is just guessing with a spreadsheet open.