Agent Occupancy: How Busy Should Your Help Desk Be?

A calm support agent with a headset working at a tidy desk while four colleagues work comfortably at their own desks behind her

Agent occupancy is the share of logged-in time your agents spend actually handling contacts: talking, holding and doing wrap-up. A sensible target for a large queue is 85-90%. For a small queue it’s far lower, because a handful of people can’t absorb random bursts of calls at that level. If you use one occupancy target for every team, you’ll overwork some and overpay others.

Occupancy sits right next to the numbers in my post on average speed of answer versus service level, and it comes out of the same Erlang C sheet. It’s the one figure on that sheet that tells you what your staffing plan feels like to the people in the chairs.

How do you measure agent occupancy?

There are two ways, and they answer different questions.

Planned occupancy comes from the model. It’s the traffic in Erlangs divided by the number of agents on the phones. An Erlang is one agent’s worth of work for one hour, so it’s a unit of workload, not a headcount. With 120 calls in a half hour at 300 seconds each, the traffic is 120 x 300 / 1,800 = 20 Erlangs. Here 120 is the calls, 300 is the seconds each one takes, and 1,800 is the number of seconds in the half hour, so the answer is how many agents’ worth of work arrives. Put 25 agents on the queue and occupancy is 20 / 25 = 80.0%.

Actual occupancy comes from your phone system’s report. It’s handling time divided by logged-in time:

=(TalkTime + HoldTime + WrapTime) / LoggedInTime

Here’s how I lay that out in Excel. Use one sheet, call it Occupancy, with one row per half hour. Row 1 holds the headings: A is Interval, B is Calls, C is Talk Time, D is Hold Time, E is Wrap Time, F is Logged-in Time and G is Occupancy. All the times are in seconds, copied from the interval report in your phone system. Row 2 is the first half hour, so G2 reads =SUM(C2:E2)/F2, formatted as a percentage. SUM(C2:E2) adds talk, hold and wrap for that interval, and dividing by F2 turns it into a share of logged-in time. For example, if agents logged in for 45,000 seconds and spent 22,500 on talk, 2,700 on hold and 6,300 on wrap-up, that’s (22,500 + 2,700 + 6,300) / 45,000 = 31,500 / 45,000 = 0.70, or 70%. Drag the formula down the column. Do it per half hour, not per day. A daily average hides the intervals that hurt.

Two traps. First, count wrap-up time as handling time. If you leave it out, occupancy looks lower than it feels. Second, decide what counts as logged in. If agents sit in a “not ready” state for breaks and meetings, strip that out first or you’ll understate occupancy. That’s the same shrinkage problem I covered in why 25 agents on the sheet means 36 on the rota.

A tired support agent with a headset rubbing her eyes at a cluttered desk with blinking phone lights while her team lead brings her a mug of tea
A tired support agent with a headset rubbing her eyes at a cluttered desk with blinking phone lights while her team lead brings her a mug of tea

What does occupancy look like at different team sizes?

Here’s the part most managers never see. I ran the same service goal, 80% of calls answered in 20 seconds with a 300-second handle time, through the Erlang C formula at four different volumes:

Calls per half hour Traffic (Erlangs) Agents needed Service level Occupancy
12 2 4 84.8% 50.0%
60 10 14 86.7% 71.4%
120 20 25 85.0% 80.0%
600 100 108 80.7% 92.6%

Same goal, same call length. The only thing that changed was volume, and occupancy runs from 50% to nearly 93%. The reason is statistical. A big queue pools its randomness: when a few extra calls land at once, plenty of agents are free to catch them. A small queue has no such cushion, so it needs idle capacity just to keep waits short.

Look at the bottom row. A 100-Erlang desk can run above 90% and still hit its target. The top row can’t, and shouldn’t try. Four agents who each spend half the half hour waiting aren’t wasted. They’re what keeps that queue answering quickly. Call Centre Helper makes the same point about large and small centres and puts the usual ceiling around 85-90%, with burnout, falling quality and attrition showing up above 90%.

How does the Erlang C sheet get these numbers?

You don’t need to trust my table. The Erlang C formula gives the chance that a caller has to wait, and everything else follows from it. Set up a second sheet called Erlang with traffic in B1 (20), agents in B2 (25), target answer time in seconds in B3 (20) and average handle time in seconds in B4 (300). The formula, in plain terms, takes the load that a full queue would have (the traffic raised to the number of agents, scaled by how close you are to saturation) and divides it by that same figure plus the sum of the smaller loads below it. For 20 Erlangs and 25 agents the answer is 0.2091, so 20.9% of callers wait at all. If you want the background on the unit itself, the Erlang entry on Wikipedia covers where it came from.

Two more cells finish the job. Service level is 1 minus the wait probability times e raised to the power of minus (agents minus traffic) x target seconds / handle seconds. Step by step: (25 – 20) x 20 / 300 = 0.3333, and e to the minus 0.3333 is 0.7165. Multiply 0.2091 x 0.7165 = 0.1498. Service level is 1 – 0.1498 = 0.8502, or 85.0%, which matches the 85.0% in the third row of the table. Average speed of answer is the wait probability times handle time divided by the spare agents: 0.2091 x 300 / 5 = 12.5 seconds. And occupancy is just 20 / 25 = 80.0%. Three cells, one formula each, all driven off the same four inputs.

What happens when you push occupancy too high?

Take the 20-Erlang desk and take agents away one at a time:

Agents Occupancy Service level Average speed of answer
25 80.0% 85.0% 12.5 sec
24 83.3% 77.2% 22.4 sec
23 87.0% 66.0% 41.6 sec
22 90.9% 50.3% 85.2 sec
21 95.2% 28.8% 228.2 sec

Going from 25 agents to 21 looks like a 16% saving (4 / 25 = 0.16). What it buys you is an average wait of nearly four minutes and fewer than three calls in ten answered inside the target. Waits don’t grow in a straight line as occupancy rises. They bend upward and then fall off a cliff, and the cliff sits just above where most spreadsheets stop warning you.

Notice what happens between 23 agents and 22. Occupancy only moves from 87.0% to 90.9%, about four points, yet average wait doubles from 41.6 to 85.2 seconds and service level drops from 66.0% to 50.3%. The denominator in the formula is the number of spare agents, and when that spare number shrinks from 3 to 2 to 1, the wait jumps accordingly. That’s why a rota that looks only a little tighter on paper feels so much worse on the floor.

The cost isn’t only on the customer side. On a small desk I worked with that ran close to full occupancy for a long stretch, the pattern was always the same: answer times and sick days got worse together. When there’s no gap between calls, there’s no time to finish notes properly, so wrap-up gets rushed, repeat contacts rise and the workload grows. High occupancy feeds itself.

Does AI-assisted support change the target?

It changes what the occupancy number is made of, not the maths behind it. In 2026 many queues have a chatbot or an AI assistant taking the simple contacts first. What reaches your agents is the harder, longer work, so handle time goes up and the same headcount carries a heavier load per contact. Re-run the Erlang sheet with the new handle time, not the old one. If average handle time moves from 300 seconds to 420 on the same 120 contacts, traffic goes from 20 Erlangs to 120 x 420 / 1,800 = 28 Erlangs, and the 25 agents that were comfortable at 80% would now be short of the work altogether.

Hard contacts also drain people faster than easy ones. A desk that held 85% occupancy comfortably on password resets may not hold it on billing disputes. Treat any occupancy figure you set before the bot went live as stale and test it against a fresh month of interval data.

What should your target be?

Start from the Erlang table for your own volume, not from a benchmark. Run your busiest and quietest intervals through the sheet at your service goal and read off the occupancy. That figure is the highest your team can run before the queue becomes unstable.

Then apply three rules:

  • Treat the model’s occupancy as a ceiling, not a goal. If the sheet says 80% for your size, rostering to 88% is a service level miss waiting to happen.
  • Set a different expectation for small teams. Under about ten agents on the phones, ignore any 85-90% target you read and use your own numbers.
  • Watch the busiest interval, not the day. If 11:00 to 11:30 hits 92% while the day averages 74%, the day is fine and the half hour isn’t.

The last check is the cheapest. Pull last week’s occupancy by half hour into the Occupancy sheet, sort column G from highest to lowest and read the top five rows with your team lead. Those are the intervals where somebody had no room to breathe, and they’re usually the ones nobody put in a report.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.