Capacity planning for processes: why the naive calculation is always short

Table of contents+

The calculation everybody does

Demand    =  volume per day  ×  processing time
Capacity  =  people  ×  hours per day
Staffing  =  demand ÷ hours per person

Example. 120 cases a day at 12 minutes each = 1,440 minutes of demand. At 8 hours of working time that is 3.0 FTE.

That number is wrong, and systematically low. Three reasons, each with a multiplier.

Addition 1: productive rather than nominal hours

Eight hours of attendance are not eight hours of processing. Subtract meetings, queries, training, system outages, phone calls, movement, and the share spent on other duties.

Rule of thumb: 70 percent. So roughly 5.5 to 7 productive hours per full-time day, depending on the role. In roles with heavy interruption (service desk, customer support) it can be less.

3.0 FTE ÷ 0.7  =  4.3 FTE

Omit this factor and you plan a workforce that can only meet demand if nobody attends a meeting.

Addition 2: the peak day, not the mean

A process averaging 120 cases has 180 on busy days. Plan against the mean and those days run at 150 % utilisation. The backlog that forms does not clear the next day.

This is the most underestimated point. Clearing a backlog uses only the difference between capacity and inflow, not the full capacity. At 85 % normal utilisation that is 15 %. A backlog of 60 cases then takes about three weeks to disappear.

Practically: plan against the 90th percentile of daily volume, not the mean. The figure is in your systems; retrieving it costs one query.

Addition 3: target utilisation of 80 to 85 percent

Capacity for 100 % utilisation means waiting time grows without bound. The reason is the factor ρ/(1−ρ) from queueing theory:

(Approximation for a single server at moderate variation; in a pool the values are lower, the non-linearity remains.)

The planning rule: 80 to 85 % on the peak day. Not 95 %, because every fluctuation then breaks through. Not 60 %, because that burns money needed elsewhere.

The full calculation

1. Peak volume        =  daily volume P90
2. Demand             =  peak volume × processing time (mean)
3. Productive hours   =  attendance × 0.7
4. Raw capacity       =  demand ÷ productive hours
5. Planned capacity   =  raw capacity ÷ target utilisation (0.85)

The same example, computed properly:

• Peak volume: 180 cases
• Demand: 180 × 12 min = 2,160 min = 36 h
• Productive hours per FTE: 8 × 0.7 = 5.6 h
• Raw capacity: 36 ÷ 5.6 = 6.4 FTE
• Planned at 85 %: 6.4 ÷ 0.85 = 7.6 FTE

Against the naive 3.0 FTE that is more than double. The largest single contribution comes from the peak day, the second from productive hours.

Before you panic: the naive 3.0 FTE is not what is staffed today. It is what a spreadsheet computes. What is staffed today usually sits between the two figures, and the difference explains your lead time.

The fourth lever: variation

If the calculation above alarms you, there is an alternative to adding capacity. In the Kingman approximation, variation enters waiting time squared:

Wq  ≈   ρ/(1−ρ)   ×   (ca² + cs²)/2   ×   te

Halve the variation and you quarter its contribution to the queue. Concretely:

• Separate cases by type. Simple and complex work in one queue creates high variation. Two separate queues cut waiting for both.
• Level the inflow. Fixed handover times, appointment slots, deadline management instead of a flood.
• Abolish queries. Every query is a case that waits twice.
• Fix rework at the source.

These measures cost no position, which is why they appear in almost no staffing plan.

The fifth lever: pool instead of assignment

At identical capacity, two handlers with their own queues are worse than two handlers sharing one. The reason: in the separated version somebody waits while somebody next to them is free.

Practically: shared trays instead of personal ones, cover arrangements instead of "that is her case", qualification across more than one case type. That is capacity gained without hiring.

What planning still omits

• Absence: holiday, sickness, training. With 30 days of leave and typical sickness rates, roughly 15 percent of annual capacity is missing. Anyone planning in annual FTE has to add that.
• Ramp-up: a new hire is not productive from day one. For demanding review work, three to six months is normal.
• Seasonality: an annual average with uneven distribution is the single most misleading metric. Compute quarters separately.

Where a simulation gives more than the formula

The calculation above treats one step in isolation. What it cannot do:

• Coupling. A step never receives more than the slowest one ahead of it lets through. Build capacity at the wrong step and you pay for it with no effect.
• Backlog over time. How long does the month-start pile take to disappear?
• Migration. If you add capacity here, where does it stick afterwards?

That is exactly what a computational model is for. The arithmetic of identifying the constraint is in Calculating the bottleneck, the procedure for a full analysis in Bottleneck analysis.