Free tool · Calculator
How long is the wait? Your utilisation, and what it costs you.
Nobody plans to be 92% busy. It happens one enquiry at a time, and the first sign is that everything is suddenly late. This puts a number on where you are before it does.
- Operations
- Capacity
- Small firms
- Getting started
The short answer
Enter how many jobs arrive a week, how long one takes, and how many hours a week are genuinely available for them. This returns your utilisation, the average wait implied by it, and the wait you would have if handling time fell by a fifth. Average waiting time scales as ρ ÷ (1 − ρ), so above about 80% busy the wait rises much faster than the work does.
On this page · 5 sections
The published figures are ours and deliberately ordinary: forty jobs a week, ninety minutes each, one person with thirty usable hours. That is 100% busy, which is why it does not work.
The third field is the one people get wrong. "Available hours" is not contracted hours. It is hours actually free for this category of work after meetings, holiday, admin and everything else — usually between half and two-thirds of the contracted number.
Your numbers
Opens on a worked example, not an industry average. Replace every figure with your own — there is no such thing as a default here.
—
Show the working
What this assumes, and where it breaks
It models one queue served at a steady average rate, with work arriving at random. Three limits follow.
- Pooling is assumed. The "people sharing the queue" field divides the wait, which is only true if they genuinely work from one pool. If each person has their own list, you have several small queues and each behaves like a single-server one — which is worse, sometimes much worse.
- Highly variable job lengths make it optimistic. If a tenth of your jobs take ten times as long, the real wait is longer than this shows. The direction of the error is always the same: reality is worse.
- It ignores priorities and abandonment. If urgent work jumps the queue, the average is unchanged but the experience is not. If customers give up and go elsewhere, the queue is shorter and the business is smaller.
Used as a gauge of where you sit on the curve, it is reliable. Used as a forecast of Thursday, it is not.
What to do with the number
If you are above 85%, the order of cheapness is usually: cut the variability first, cut the handling time second, add people last. Triage and templates cost nothing and shorten the tail; a person costs a salary and arrives in three months.
And if you are above 100%, stop optimising. The arithmetic says the backlog grows every week regardless of effort, and every hour spent on productivity is an hour not spent on the only three things that help.
Questions people actually ask
What is a safe utilisation for a small team?
Below about 75 to 80% for work with a service promise attached. Average waiting time scales as utilisation divided by one minus utilisation, so beyond that point each additional increment of work produces a disproportionate increase in delay — which is why teams are usually surprised by how suddenly things become late.
How do I work out available hours properly?
Start from contracted hours and subtract meetings, holiday, training, admin and anything else that is not this category of work. For most roles the genuinely available figure is between half and two-thirds of contracted hours, and using the contracted number is the single most common way this calculation is made to look healthier than it is.
Does adding a person halve the wait?
Only if both people work from the same pool. Two separate queues each behave like a single-server queue, so one person can be idle while the other has a backlog, and that idle time is not recoverable. Pooling the same headcount against one queue is free capacity.
Why does reducing handling time help more than it sounds?
Because it reduces utilisation as well as the work itself, and at high utilisation the wait is governed by how close utilisation is to one. Taking a fifth off handling time when you are 90% busy moves you to 72%, and the average wait falls by far more than a fifth.
Sources
- The calculation uses the standard single-server queue result, in which mean waiting time scales as ρ/(1−ρ) times the service time. It is textbook queueing theory, not a finding of ours. — established theory, stated as such
- We verified the formula against a discrete-event simulation of 400,000 arrivals at each of six loads on 23 September 2026: 1.00 against a predicted 1.00 at 50% utilisation, 4.00 against 4.00 at 80%, 9.05 against 9.00 at 90% and 19.89 against 19.00 at 95%. The method and the numbers are set out in the accompanying note. — our own run, reported with its method and its date
- The division by the number of people sharing a queue is an approximation, not the exact multi-server result, and it assumes genuine pooling. Highly variable job lengths make the output optimistic. Both limits are stated on the page. — a stated limit on the tool 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.
Cut the variability first. It is the only free one.
If this put you above 85%, the cheapest fix is usually not a person and not a subscription — it is taking the irregular steps out of the work. Send us the number this gave you and we will tell you which step to attack first, including when the answer is that you need a person and no software will do.
Start the conversation