Staffing and utilization: how many people are needed?
Staff demand is the work a process generates per period: cases times processing time per case. Divided by the working time of one full-time person, it gives the full-time equivalents (FTE) needed. Compared with the time the people actually have for the process, it gives the utilization. Above 100%, cases pile up.
Demand: the work per period
Demand is calculated per lane, that is per role or department. For each step that is not automated, the processing time (including query effort) is multiplied by the visits per case; parallel branches all count. The sum over the lane, multiplied by the cases per period, is the demand in hours. The total staff demand counts only your own staff, that is lanes of the kind role or department; external partners, customers and IT systems are not included.
Capacity: the time the people really have
Capacity is the working time the people in a lane have for this process. The key figure is availability: the share of their working time that goes into this process. A purchasing clerk who also handles supplier management and complaints might have 60% for purchase orders. Two people at 90% are 1.8 people for this process, not two.
Worked example: accounts payable
In the invoice example, accounts payable spends 16 minutes per invoice (enter 6, check 1.25 × 4, post 5). At 1,000 invoices a month the demand is 16,000 minutes, 266.7 hours. A month has 220 ÷ 12 = 18.33 working days. Two people with 90% availability and 8 hours a day have 2 × 0.9 × 8 × 18.33 = 264 hours.
| Lane | Demand | Capacity | Utilization | FTE needed |
|---|---|---|---|---|
| Accounts payable | 266.7 h | 264 h | 101% | 1.82 |
| Division management | 24.8 h | 29.3 h | 84% | 0.17 |
Backlog above 100%
If demand exceeds capacity, the difference is work that is not done in the period. The app shows it as a growing backlog in cases per period: the uncovered share of demand multiplied by the cases that pass through this lane. In reality the backlog is cleared by overtime, by postponing other tasks or by cases waiting longer. All of these are visible symptoms of an overload that the calculation makes explicit.
Only the cases that actually pass through the lane count. Division management only sees the 300 invoices above €5,000. If a single person with 15% of their time handled approvals, the lane would have 22 hours of capacity for 25 hours of demand: 114% utilization. Then (25 − 22) ÷ 25 × 300 = 36 approvals a month are left over, not 120 as a calculation with all 1,000 invoices would suggest. The backlog in working hours is unambiguous: work of the arriving cases minus capacity, here 3 hours a month – that much is left over each month. Distinguish it from the missing hours (“… full-time equivalents are missing”): demand for all cases minus capacity – that much is missing to handle all cases. Without an overloaded lane upstream, both are equal.
If several lanes are overloaded, their backlogs in cases are not added up: a case stuck in two lanes is one open case, not two. The app calculates the whole process along the flow, assuming “work in progress first”: every lane finishes the cases it has already worked on and accepts only as many new ones as its capacity covers for their entire work in that lane. What is left over upstream does not arrive downstream. “Open cases grow by …” is then the number of arriving cases minus the cases that reach an end; if only one lane is overloaded, that is exactly its backlog. In the example with division management at 15% this comes to 36 invoices a month, not 10 + 36 = 46: accounts payable no longer has to post the 36 invoices waiting for approval. Its demand drops to 263.7 hours against 264 hours of capacity, so it is no longer overloaded. The working hours left over, on the other hand, may be summed across lanes, because work adds up.
The app calculates the values per lane with the cases that actually arrive there. If an overloaded lane comes first, fewer cases arrive than at full inflow; the app then names the value at full inflow at the lane, labeled as such. A lane that would be above 100% at full inflow can therefore keep up in reality, like accounts payable in the example. And because the backlog of the whole process counts cases, not work, more staff does not reduce it in every process: if some cases end early, for instance as “not approved”, or if case types need very different amounts of work, a relieved lane can pass on more of the laborious cases, and the next overloaded lane accepts fewer simple ones in return. Then fewer cases reach an end although more work gets done. The working hours left over in the lane you strengthen, on the other hand, never increase. Check a staffing measure against both figures.
Why 100% is too much in an office
A role at 100% has no slack at all. Cases do not arrive evenly, and some take much longer than the typical time. When the role is fully loaded, every irregularity turns into waiting: cases queue until someone is free. The closer utilization gets to 100%, the longer these queues become. That is why the app marks lanes from 85% in amber and above 100% in red; the lane with the highest utilization from 85% is the bottleneck and is marked red as well.
The instant calculation does not derive this waiting time itself; it uses the waiting times you entered. The simulation in the analysis area sends cases through the process with limited staff and shows how queues build up. For the reasoning behind the threshold and what to do about it, see Bottleneck analysis.
Estimating availability honestly
Availability is the figure most often overestimated. Ask the people involved, not their managers. The app keeps two inputs apart: the working days per year (default 220) are the days left after weekends, public holidays and annual leave, so leave and public holidays are already included there. Availability is the share of that working time that really goes into this process. Deduct from it:
- other processes and tasks of the same role
- meetings, training, internal coordination
- sickness and other absence that is not annual leave
- part-time contracts, counted as a share of a person (or entered as fewer people)
| Input | Calculation | Result |
|---|---|---|
| Working days per year | 365 − 104 weekend days − 11 public holidays − 30 days of leave | 220 days |
| Working time per person and month | 8 h × 220 ÷ 12 | 146.7 h |
| Availability | 100% − 5% meetings − 5% sickness | 90% |
| Capacity | 2 × 0.9 × 146.7 h | 264 h per month |
| Utilization | 266.7 h demand ÷ 264 h | 101% |
| Leave deducted twice | availability 90% − 30 ÷ 220 = 76.4%; 2 × 0.764 × 146.7 h = 224 h | 119% – a bottleneck that does not exist |
From the calculation to a staffing decision
A demand of 1.82 FTE does not mean "hire 0.02 people". It means the team is at its limit and any growth in volume, any additional query or any absence tips it over. The useful question is which lever is cheapest: reducing the load per case, for example fewer queries; shifting work to another role; or adding capacity. In the worked example, halving the incomplete invoices from 20% to 10% brings accounts payable down to 97.5% without hiring anyone. Use the staffing calculator for quick what-if checks, and the lesson on volumes and case counts for reliable input.
Try it in the editor
Invoice check (worked example) · 1,000 / month
In the worked example accounts payable is at 101% with 1.82 FTE needed; change the number of people or the availability and watch the lane color change.
Open the example in the editorFrequently asked questions
What is an FTE?
A full-time equivalent is the working time of one full-time person in the period: hours per day times working days. 1.82 FTE means the work of almost two full-time people.
Why does the app show no utilization for some lanes?
Utilization needs the number of people. Without a headcount there is no capacity, and the app shows only the demand. External partners, customers and IT systems are not given a utilization.
Is waiting time part of the staff demand?
No. Demand is processing time only. Waiting affects the lead time, not the number of people needed.
Can I use this for back office capacity planning?
Yes, for planning based on average volumes and estimated times. For peaks, calculate a second variant with the peak volume; for the effect of queues, use the simulation.
Self-test
Keep learning
Would you like to map or improve a process together with us? Contact