How to calculate a bottleneck: why 85 % utilisation is already too much

Two sentences said in almost every process project are both wrong:

“The bottleneck is the step that takes longest.”

“We are at 85 % utilisation, so there is room.”

Why they are wrong can be shown with three formulas that together fit on one page. After that you can find the bottleneck of any process with a pocket calculator — and see exactly where the pocket calculator stops.

1. Utilisation: the only number that reveals the bottleneck

Utilisation  ρ  =  demand ÷ capacity

Demand is volume times processing time. Capacity is available working time.

Example. The step “Review” receives 120 cases a day, each taking 12 minutes. Three people work seven productive hours each.

• Demand: 120 × 12 min = 1440 min/day
• Capacity: 3 × 7 h = 21 h = 1260 min/day
• Utilisation: 1440 ÷ 1260 = 114 %

Above 100 % means the queue grows every single day. Not “it takes a bit longer”, but without bound — until somebody escalates, works overtime, or cases are left behind.

That another step happens to take 40 minutes is irrelevant, as long as there is enough capacity there. Duration is not utilisation. The bottleneck is always the step with the highest ρ.

2. Little's Law: inventory, throughput and time are linked

Inventory  L  =  throughput λ  ×  lead time W

This relationship holds without any assumption about distributions — it is an accounting identity. It becomes practically useful rearranged:

Lead time  W  =  inventory L  ÷  throughput λ

Example. Forty unprocessed cases sit in your inbox and you complete twenty a day. Your lead time is two days — regardless of what your process documentation says.

This is the cheapest measurement available: count inventory, count throughput, divide. You need no tooling, only two numbers any department head can produce.

3. Kingman: why it explodes near the limit

The decisive formula is an approximation from queueing theory, often called the VUT equation:

Waiting  Wq  ≈    ρ / (1 − ρ)      ×   (ca² + cs²) / 2   ×   te
                └─ utilisation ─┘     └─ variability ─┘    └ time ┘

Three factors, and only the last one gets discussed in projects.

The first factor is the reason for everything. Look at how it behaves:

(Approximation for a single server at moderate variability. With several people sharing a pool the values come out lower — the non-linearity remains.)

From 70 % to 85 % is a rise of fifteen percentage points. Waiting time roughly two-and-a-half times. From 85 % to 95 % — ten more points — it triples again.

That is the answer to “why did the process suddenly collapse?” It did not collapse suddenly. It ran at 88 % utilisation and volume rose by 6 %.

The second factor: variability is a lever

The middle term is almost always overlooked. ca and cs are coefficients of variation — standard deviation divided by mean — for arrivals and for processing times.

The practical consequence: you can cut waiting time without processing a single case faster. Halve the variability and you quarter its contribution to the queue. Concretely:

• Separate cases by type instead of putting simple and complex work in the same queue
• Smooth arrivals (appointments instead of bursts, fixed handover times)
• Eliminate clarification loops — every query is a case that waits twice

These are measures without investment. They rarely appear in business cases because they are hard to sell as a project.

The calculation in practice: four steps

1. Collect demand and capacity per step. Volume × duration against available working time. A rough estimate is fine for the first pass.
2. Compute ρ and sort. The highest value is your bottleneck. Anything above 85 % is an alarm; anything above 100 % is already backlog.
3. Compute on the peak day, not the monthly mean. A process at 70 % monthly and 130 % on the first of the month has a problem invisible in the average. Use the 90th-percentile day.
4. Count inventory and cross-check with Little's Law. If measured lead time greatly exceeds computed lead time, your model is missing a queue — usually a clarification loop or an approval.

Where hand calculation stops

Three things this arithmetic cannot do, and all three decide projects:

It knows nothing about coupling. A step never sees more cases than the slowest step ahead of it lets through. While review sits at 114 %, the approval behind it looks relaxed — it barely receives anything. Fix review and approval takes the full volume. The constraint migrates. A spreadsheet computes each step in isolation and cannot see that movement.

It knows nothing about peak days. The formula works with a mean arrival rate. The real damage happens on the five worst days of the quarter.

It yields a number, not a range. A waiting time of “57 minutes” is the output of an approximation fed with estimates. It becomes defensible only as a band: P10 to P90.

That is precisely where simulation starts. It runs cases through the process for real — hundreds of times, with variability, with a calendar — and answers the question no formula answers: where does the constraint move once I relieve it, and what is that worth in money?

In summary

• The bottleneck is the step with the highest utilisation, not the longest duration.
• Waiting grows with ρ/(1−ρ) — beyond roughly 85 % every further volume increase gets expensive.
• Variability is a lever in its own right, and usually the cheapest one.
• Little's Law checks your model against reality using two counted numbers.
• For “what is a change worth?”, hand calculation is not enough, because it cannot see the constraint migrate.