Occupancy calculator
What your current headcount actually does to the people on it, and how many agents it would take to get back under your ceiling. With the burnout threshold flagged before you schedule to it.
What occupancy is, precisely
Occupancy is the share of an agent's productive time spent actually handling contacts, including talk, hold and wrap. It is not a measure of how much of their shift they worked. It is a measure of how hard the queue pushed them while they were available.
Offered load is contacts multiplied by AHT, divided by the interval length in seconds. The unit is the Erlang, and one Erlang is one agent's worth of continuous work.
Occupancy is not utilisation
These get used interchangeably and they measure different things, which makes benchmarking between centers close to meaningless unless both are defined.
| Measure | Denominator | Answers |
|---|---|---|
| Occupancy | Time available to take contacts | How hard was the queue pushing while they were on it? |
| Utilisation | Total paid or rostered time | How much of the shift they paid for went into contacts? |
Utilisation therefore includes breaks, training and meetings in its denominator and always comes out lower. An 85% occupancy figure and a 60% utilisation figure can describe the very same interval. If someone quotes you a number, ask which one it is before reacting to it.
The counter-intuitive part
Occupancy is the one number in staffing that improves as you add people, because headcount is the denominator. That has a consequence worth internalising:
A ceiling on occupancy is a floor on headcount. Because occupancy falls as N rises, setting a maximum occupancy sets a minimum number of agents, and on busy intervals that minimum is frequently higher than the one your service-level target asks for.
This is why planners get asked "why does this interval say 40 when 39 hits the target" and often cannot answer. The honest answer is that service level was met at 39, but 39 leaves people at 85.5% occupancy, and the cap is 85%.
Worked example
The values the calculator loads with: 250 contacts in a 30-minute interval at 240 seconds AHT, staffed with 39 agents, capped at 85%.
- Offered load: (250 × 240) ÷ 1800 = 33.33 Erlangs
- Occupancy: 33.33 ÷ 39 = 85.5%, over the ceiling
- Service level at 39 agents: 84.2% answered within 20 seconds, comfortably past an 80% target
- Agents needed to get under the cap: ceil(33.33 ÷ 0.85) = 40
- Occupancy at 40: 83.3%, and service level rises to 89.1%
So the service-level target is satisfied at 39 and the requirement is still 40. The cap is the binding constraint, and a tool that reports only "40 agents required" has hidden the more useful half of the answer.
Common questions
What is a good occupancy rate?
Most operations target 80% to 85% and treat 85% as a ceiling rather than a goal. Sustained occupancy above roughly 85% is well established as a driver of burnout, errors and attrition, and the cost of the attrition it causes generally exceeds the headcount it saves. Below about 70% on a voice queue usually means the interval is overstaffed or the queue is too fragmented to pool properly.
Why does occupancy go up when I add volume but down when I add agents?
Because it is a ratio of work to people. More contacts or longer handle times raise the numerator; more agents raise the denominator. This is also why large queues run at higher occupancy than small ones at the same service level: pooling is more efficient, and that efficiency shows up as pressure on the people in the pool unless you cap it.
What happens if offered load exceeds my agent count?
The queue is unstable. Work arrives faster than the team can complete it, the backlog grows for as long as the condition lasts, and waiting time has no ceiling rather than settling anywhere. There is no meaningful service level to report. This calculator says so explicitly instead of returning a plausible-looking low number, which is the single most important thing an intraday tool can do.
Should occupancy include after-call work?
Yes. AHT is talk plus hold plus wrap, and wrap is contact handling. Excluding it understates both your offered load and your occupancy, and it is a common cause of a staffing model that looks fine and feels terrible on the floor.
Can I just schedule to the cap?
You can, and on a genuinely exceptional interval it may be the right call. Making it routine is not, because the cap exists to price a risk that shows up months later in attrition rather than today in service level. If you do breach it, that should be a decision somebody records, not a constraint the tool quietly drops.
One interval here. Your week has nine hundred.
SureWFM applies occupancy caps per queue across every interval, reports which constraint bound each requirement, and keeps the calculation trace attached so "why 40 and not 39" has an answer a month later.