The question capacity planning answers
Capacity planning is the discipline of answering one deceptively simple question: how many agents do we need to handle the work coming at us, without drowning the team or paying for people to sit idle? Get the number too low and the queue backs up, SLAs breach, and your agents grind toward burnout. Get it too high and you are carrying payroll that produces nothing but slack. The whole craft is landing in the band between those two failures and staying there as volume shifts.
Capacity planning sits downstream of forecasting. Staffing forecasting predicts how much work is coming — the ticket volume you should expect next month, next quarter, next holiday season. Capacity planning takes that forecast and turns it into how many people you need to meet it. Forecasting tells you the wave is coming and how big; capacity planning tells you how many surfers to put in the water. This article is about that second step, and about the two words people constantly confuse when they do it: occupancy and utilization.
The rough shape of the math
At its simplest, the calculation is: work coming in, times how long each piece takes, divided by how much productive time each agent actually has. If you expect a thousand tickets in a week and each takes an average of twenty minutes to handle, that is roughly 333 hours of handling work. If an agent gives you about 30 productive hours of ticket work in a week, you need on the order of eleven agents just to touch the volume — before you add any buffer for the queue not arriving in a tidy, even stream.
The two inputs that matter most are your average handling time and your productive-hours-per-agent, and both are easy to get wrong. Handling time is the per-ticket cost; if you are actively working to bring it down, do it deliberately and measure it, because the number you plug in here drives everything — see reducing average handle time for how to move it without cutting corners. Productive hours is the one people overestimate, and it is where occupancy and utilization come in.
Occupancy versus utilization — the distinction that matters
These two terms get used interchangeably and they should not be, because confusing them is how you accidentally staff a team to run hot.
Utilization is the share of an agent's paid, scheduled time spent on support work. An agent is at work for eight hours, but not all of that is available for tickets. Training, team meetings, coaching, breaks, admin, internal projects — this is "shrinkage," and it is real. If two of an eight-hour day go to those things, utilization is around 75 percent. Utilization answers: of the time we pay for, how much is actually aimed at the queue?
Occupancy is different. It is the share of an agent's available, on-the-queue time that is spent actively handling tickets, versus waiting for the next one to arrive. An agent can be fully available and still not be busy every second, because work does not arrive in a perfectly even stream — there are lulls between tickets. Occupancy answers: of the time we have pointed at the queue, how much is genuinely occupied?
The distinction is not academic, because occupancy has a ceiling that is lower than intuition suggests. Sustained occupancy above roughly 85 to 90 percent is a red flag, not a triumph. It means agents have no breathing room between contacts — no moment to reset, document, or think — and that is precisely the condition that produces rushed replies, mistakes, and burnout. Some slack is not waste; it is the shock absorber that lets the team handle a surge without breaking. A plan that assumes 100 percent occupancy is a plan that assumes your agents are machines, and it will fail the first busy week.
Why you cannot just divide
The trap in capacity planning is treating the queue as if work arrives smoothly. It does not. Tickets cluster — Monday mornings, post-launch spikes, the hour after an outage — and a team sized for the average will be underwater during every peak and idle during every trough. This is why capacity planning based purely on averages fails: the average hides the peaks, and the peaks are what breach your SLAs.
The practical consequence is that you plan for the shape of demand, not just its total. If your volume doubles predictably at certain times, you need to think about how coverage flexes to match — whether through shift patterns that put more people on during known peaks, or a seasonal peak plan for the big predictable surges. Sizing to the average and hoping is not a plan; it is a queue backlog waiting to happen.
Turn the plan into a schedule
A capacity number — "we need eleven agents" — is not yet a working plan. Eleven agents matter only if they are present when the tickets are. The last mile of capacity planning is converting the headcount into a schedule that actually covers your demand curve: enough people during peak hours, sane coverage during quiet ones, and no accidental gaps where the queue is live but nobody is watching. This is where capacity planning hands off to support coverage and on-call — the plan tells you how many bodies you need across the week, and coverage planning places them across the hours.
Make it a loop, not a one-time calculation
Capacity planning is not a spreadsheet you fill in once a year. Demand drifts, handling time changes as your product and knowledge base evolve, and agents come and go. Treat the plan as a living loop: compare what you predicted against what actually happened, watch your real occupancy and utilization against the plan, and adjust. If occupancy is creeping past the healthy band week after week, that is your early warning that you are under-staffed for the volume — long before the SLA breaches and burnout make it obvious. Wire your support team metrics so occupancy and handling time are visible on the same dashboard you already watch, and capacity planning stops being an annual guess and becomes a dial you can actually turn. See how the reporting supports this on the features page.