Noxia

https://www.noxia.co.uk/field-notes/why-ten-per-cent-busier-doubles-the-wait · printed from noxia.co.uk · sources checked 23 September 2026

Field note · What we found

Ten per cent busier, and the wait more than doubles.

Everyone who has run a small team knows the feeling: things were fine, volume went up a little, and suddenly nothing is on time. It is not a failure of effort, and it is not a mystery. It is the one piece of arithmetic that governs every queue, and it is worth knowing the shape of it.

3 min read Sources checked 23 September 2026

The short answer

For a single-server queue with random arrivals, average waiting time scales as ρ ÷ (1 − ρ), where ρ is the fraction of time the server is busy. At 80% busy the average wait is about four job-lengths. At 90% it is nine. At 95% it is nineteen. Going from 80% to 90% is a 12.5% increase in work and a 2.25× increase in waiting. The cause is variability: work does not arrive evenly.

On this page · 6 sections

Here is the shape. The dashed line is what people expect — more work, proportionally more delay. The solid line is what actually happens.

Waiting time against how busy you areAs utilisation rises from zero toward 92 per cent, average waiting time follows utilisation divided by one minus utilisation, which curves upward sharply after about 80 per cent. The dashed line shows the linear relationship people intuitively expect, in which waiting time rises in proportion to workload. The two are close below 50 per cent utilisation and diverge dramatically above 80 per cent.what happenswhat people expecthow busy you are → 0% to 92%average waitWaiting time against how busy you areAs utilisation rises from zero toward 92 per cent, average waiting time follows utilisation divided by one minus utilisation, which curves upward sharply after about 80 per cent. The dashed line shows the linear relationship people intuitively expect, in which waiting time rises in proportion to workload. The two are close below 50 per cent utilisation and diverge dramatically above 80 per cent.what happenswhat people expecthow busy you are → 0% to 92%average wait
The two meet at half load. Past it, only one of them is right.The standard single-server queueing result. We checked it against a simulation of 400,000 arrivals per point.

We did not take that on trust. We ran a discrete-event simulation — 400,000 arrivals at each load, random arrival times, random job lengths — and compared it with the formula. At 80% the simulation gave 4.00 against a predicted 4.00. At 90%, 9.05 against 9.00. At 95%, 19.9 against 19.0, where the run-to-run variance is itself part of the point.

Where the time actually goes

One job through a queue that is 90% busyAn animated diagram following a single job through a queue running at 90 per cent utilisation. The job arrives, then waits nine job-lengths before anything happens to it, then takes one job-length of actual work, and is finished after a total of ten. The waiting stage is marked as the slow one: nine of the ten units are spent not being worked on.ONE JOB THROUGH A QUEUE THAT IS 90% BUSYarrives0the clock startswaits9job-lengths, untouchedworked on1job-length of actual workfinished10total, start to endeach mark is the job moving to the next stageNine tenths of the elapsed time is queueing. None of it is effort.One job through a queue that is 90% busyAn animated diagram following a single job through a queue running at 90 per cent utilisation. The job arrives, then waits nine job-lengths before anything happens to it, then takes one job-length of actual work, and is finished after a total of ten. The waiting stage is marked as the slow one: nine of the ten units are spent not being worked on.ONE JOB THROUGH A QUEUE THAT IS 90%BUSYarrivesthe clock starts0waitsjob-lengths, untouched9worked onjob-length of actual work1finishedtotal, start to end10each mark is the job moving to the next stageNine tenths of the elapsed time is queueing. None ofit is effort.
At 90% busy, nine of every ten units of elapsed time are spent waiting.Derived from the same result: mean wait 9 job-lengths at 90% utilisation, against 1 of service.
Average wait at three loadsAverage waiting time measured in job lengths: 2.3 at 70 per cent utilisation, 5.7 at 85 per cent, and 19 at 95 per cent. The three steps in utilisation are roughly equal but the waits are not.70% busy2.3job-lengths of waiting85% busy5.7job-lengths of waiting95% busy19job-lengths of waitingAverage wait at three loadsAverage waiting time measured in job lengths: 2.3 at 70 per cent utilisation, 5.7 at 85 per cent, and 19 at 95 per cent. The three steps in utilisation are roughly equal but the waits are not.70% busy2.3job-lengths of waiting85% busy5.7job-lengths of waiting95% busy19job-lengths of waiting
Three roughly equal steps in load. The third costs eight times the first.Simulated at 400,000 arrivals per load; figures match the analytic result to within run-to-run variance.

Why it does this

Because work does not arrive evenly. If four jobs arrived at exactly four-hour intervals and each took exactly four hours, you could run at 100% with no queue at all. Nothing real works that way. Enquiries cluster, three cases land in one morning, one job takes three times as long as the last.

When you are half busy, the gaps absorb the clusters. When you are 90% busy there are no gaps, so every cluster is added to a backlog that has not cleared yet. The queue is not storing work; it is storing variance.

A queue does not store work. It stores the difference between when work arrived and when you were free.

Four things this changes

  1. "We are at 90% capacity" is not a comfortable number. It is the number at which delays become visible to customers. Treat the high 70s as the working ceiling for anything with a service promise attached.
  2. Reducing variability beats adding capacity, and is usually cheaper. Triage, batching, standard templates, a fixed daily slot for one category of work — all of these shorten the tail without adding a person.
  3. Small automations pay more than their size suggests. Taking 15% off the average handling time does not take 15% off the wait; at high utilisation it takes far more, because you are moving back down the steep part of the curve. This is the honest version of the case we make in the payback calculator.
  4. Two people pooling one queue beat two separate queues. Separate queues mean one person idle while the other is buried. Pooling is free capacity.

What this does not tell you

The clean formula assumes a single server, random arrivals and random job lengths. Real operations have several people, priorities, work that can be dropped, and customers who go away. Multi-server queues behave better than this; queues where people give up behave differently again.

So treat the numbers as the shape rather than a forecast of your Tuesday. The shape is the part that does not change: the cost of being busy rises faster than the busyness, and it rises fastest exactly where most firms sit. If you want your own numbers, the wait calculator takes three figures you already have. What all this costs in unanswered enquiries is a different calculation, and the chasing note is the same maths from the customer's side.

Questions people actually ask

Why does a small increase in workload cause a large increase in waiting?

Because average waiting time scales as utilisation divided by one minus utilisation. Near full capacity the denominator is small, so each further increment of work has a disproportionate effect. Going from 80% to 90% busy is a 12.5% increase in work and roughly a 2.25-fold increase in average wait.

What utilisation should a team aim for?

For work with a service promise attached, the high 70s is a more realistic ceiling than 90%. Above about 80% the waiting curve steepens sharply, so the visible symptom — things becoming late — appears suddenly rather than gradually, which is why teams are usually surprised by it.

Does reducing variability help more than adding capacity?

Often, and it is usually cheaper. Queue length is driven by the variability of arrivals and of job lengths as well as by utilisation. Triage, batching, templates and fixed slots for a category of work all shorten the tail without adding a person.

Why do pooled queues perform better than separate ones?

Because separate queues allow one server to be idle while another has a backlog, and that idle time cannot be recovered. Pooling the same people against one queue removes that waste, which is why a shared inbox with a rota usually beats individually assigned work at the same total capacity.

Sources

  1. The result quoted is the standard single-server queue with random (Poisson) arrivals and exponential service times, in which the mean number waiting scales as ρ/(1−ρ). It is a textbook result, not a finding of ours. — established theory, stated as such
  2. We checked it rather than quoting it. A discrete-event simulation of 400,000 arrivals at each load, run on 23 September 2026, returned mean waits of 1.00 at ρ=0.5 (theory 1.00), 2.34 at 0.7 (2.33), 4.00 at 0.8 (4.00), 5.68 at 0.85 (5.67), 9.05 at 0.9 (9.00) and 19.89 at 0.95 (19.00). The widening gap at 0.95 is sampling variance, which is itself part of the argument. — our own run, reported with its method and its date
  3. The clean formula assumes one server, random arrivals and random job lengths. Multi-server queues behave better, and queues where customers abandon behave differently again. The numbers are the shape, not a forecast. — a stated limit on the coverage above

Checked 23 September 2026. Numbers that move — leaderboards, live indices — are re-checked every 30 days; annual datasets and rules in force every six months; dated research once a year. If something here has gone stale before we got to it, tell us and we will correct it and say what changed.

Cite this note

Noxia, “Ten per cent busier, and the wait more than doubles”, Field notes, 23 September 2026; sources checked 23 September 2026. https://www.noxia.co.uk/field-notes/why-ten-per-cent-busier-doubles-the-wait

Taking 15% off the handling time does not take 15% off the wait.

At high utilisation it takes considerably more, because you move back down the steep part of the curve — which is the honest reason small automations pay. Tell us the volume, the handling time and the headcount, and we will show you where you sit on that curve before we quote for anything.

Talk to us about this
What we found: Ten per cent busier, and the wait more than doubles.

Read next

Getting started: Eighty-six hours a year chasing money you have already earned.

Getting started

Eighty-six hours a year chasing money you have already earned.

The Small Business Commissioner cites 86 non-productive hours spent chasing debt and 38 small businesses closing every day because of late payment. A bill now in the Lords caps terms at 60 days.
Appointments: The cheapest fix for missed appointments is one line in a text message.

Appointments

The cheapest fix for missed appointments is one line in a text message.

Two randomised trials at a London NHS trust found that adding the cost of the appointment to the reminder text cut no-shows by roughly a quarter. Nothing was installed.
Pensions: Six weeks to connect. What the dashboard deadline is really testing.

Pensions

Six weeks to connect. What the dashboard deadline is really testing.

Nearly 1,500 providers and schemes have connected, carrying more than 70 million records — around 85% of those in scope. The deadline is 31 October 2026; the public comes later.