How Queues Form Before a Team Reaches 100% Utilization

It is a common and reasonable-sounding assumption that a queue only forms once a team is fully loaded, working at one hundred percent of its available capacity. If that were true, the fix for a growing backlog would always be simple: add capacity until utilization drops back to a comfortable level. In practice, queues routinely form and grow at utilization levels well below one hundred percent, sometimes as low as seventy or eighty percent, and understanding why changes how a team should think about staffing.

The simple model that misleads

The intuitive model treats capacity like a bucket: if a team can handle one hundred cases a day and only eighty arrive, there should be room to spare and no reason for a queue to build. This model assumes cases arrive at a perfectly even pace and take a perfectly consistent amount of time to handle. Neither assumption holds in almost any real process. Cases arrive unevenly through the day, the week, and the month, and the time each case takes varies depending on its complexity, the person handling it, and whether anything unusual comes up.

Once you allow for that variability, the bucket model stops being accurate, and a different pattern takes over.

Why variability creates waiting even below full load

When work arrives unevenly, there will be periods where several cases arrive close together, faster than they can be processed, even if the average arrival rate is comfortably below capacity. During those periods, a queue forms. If demand then drops below capacity for a while, the queue shrinks again, but it rarely shrinks all the way back to zero before the next busy period begins, especially if the busy periods are frequent or the quiet periods are short. Over time, this produces a queue that never fully clears, even though the average workload across the day would suggest plenty of spare capacity.

The same effect happens with variable task duration even when arrivals are perfectly even. If most cases take ten minutes but a meaningful share take forty minutes because they are unusually complex, those longer cases create a temporary backlog behind them that shorter cases then have to wait through, even though the average task time still looks manageable against available capacity. The combination of uneven arrivals and uneven task duration compounds the effect, which is why queueing behavior tends to get noticeably worse, not just proportionally worse, as either type of variability increases.

The practical consequence for staffing

This means that a team running at seventy or eighty percent average utilization on paper can still have customers or internal stakeholders waiting noticeably longer than expected, and it also means that pushing utilization higher, by cutting staff or adding volume without adding capacity, tends to make waiting time worse at an accelerating rate rather than a steady one. As utilization climbs toward its ceiling, small increases in workload produce increasingly large increases in queue length and waiting time. A team that looks only modestly overloaded on an average-utilization report can already be experiencing customer-facing delays that feel disproportionate to that number.

This is also why cutting a role to improve efficiency, based purely on the fact that average utilization looks low, can backfire. Removing capacity that appears to be spare on average can push the team into the steep part of the queueing curve, where waiting time grows much faster than the apparent efficiency gain would suggest. The average utilization number, taken on its own, does not tell you how close a team is to that steep part of the curve.

Seeing this without guessing

Because this behavior emerges from the interaction of variability and capacity rather than from either one alone, it is difficult to predict accurately with a simple spreadsheet calculation based on averages. A discrete-event simulation models arrivals and task durations with their actual variability, runs a large number of cases through the process, and reports the resulting waiting time and queue length directly, rather than inferring them from an average utilization figure. This makes it possible to see, before making a staffing change, whether a team already sits close to the steep part of the queueing curve or genuinely has room to spare.

It also makes it possible to test the reverse question: how much would a queue shrink if one additional person were added, or if a scheduling change smoothed out when work is checked. Sometimes a small change in scheduling produces a disproportionately large reduction in waiting time, precisely because it targets the peak periods where the queue was actually forming, rather than adding capacity that sits unused during the quieter periods.

How Processfix models this

Processfix uses a discrete-event Monte Carlo simulation to run hundreds of cases through a locked baseline of your process, capturing realistic variation in arrivals and task duration rather than relying on a single average scenario. The resulting baseline reports utilization alongside cycle time and throughput, so you can see whether a team's queueing behavior lines up with what average utilization alone would suggest, or whether variability is already producing more waiting time than the average number implies. Staffing or scheduling changes can then be tested as an Improve scenario and compared against the baseline before any decision is made.