Why Running at Full Capacity Is the Expensive Choice | HL Hunt
Why Running at Full Capacity Is the Expensive Choice
A reviewer at 90% utilization keeps each case waiting 54 minutes on average. At 95% it is 114 minutes. Five more points of busyness more than doubled the delay, and the next three points double it again. Every queue with random arrivals has this shape, and almost every financial operation runs on the steep part of it, because idle time shows up on a report and waiting does not.
What you'll learn
Waiting does not rise in a straight line
Every operation that processes work in a queue faces the same choice: how busy to keep the people doing it. A review team, a collections floor, a support desk and an underwriting function all look most efficient when nobody is idle.
The arithmetic of queues says that intuition is wrong in a specific and predictable way. Take one reviewer who handles 10 cases an hour, with cases arriving at random. Average wait before a case is picked up:
| Utilization | Average wait |
|---|---|
| 70% | 14 minutes |
| 80% | 24 minutes |
| 90% | 54 minutes |
| 95% | 114 minutes |
| 98% | 294 minutes |
The curve is not a feature of this example. It is the shape of every queue with random arrivals. Waiting time scales with utilization divided by the idle share, so as the idle share approaches zero the wait goes to infinity. The last few points of utilization are bought with the largest increases in delay, and nobody experiences them as a decision because no one chose them deliberately.
A team softens the curve but does not remove it. Five reviewers each handling six cases an hour wait an average of 5.5 minutes at 80% and 35.1 minutes at 95%. That is 19% more throughput for 6.4 times the wait, and at 95% almost nine cases in ten wait at all.
Why everyone runs too hot
If the curve is this well understood, the question is why operations consistently sit on the steep part of it. The answer is in what each number looks like on a report.
- Idle time is visible and attributable. A reviewer at 80% is visibly not working a fifth of the day, and that reads as waste.
- Waiting time is diffuse. It is spread across hundreds of cases, borne by customers rather than staff, and appears on no cost line.
- Utilization targets are easy to set and easy to hit. Wait time targets require measuring something the operation does not naturally record.
So the metric that gets managed is the one that looks like efficiency and the cost that grows is the one nobody owns. Per our review economics analysis, the applicant pays the latency of a review queue, and per our cost of waiting analysis waiting has a price even when nobody invoices for it.
The incentive is reinforced by how capacity is funded. Per our turnover analysis, adding a person is a visible annual cost decided once, while the queue it would have shortened produces a cost decided by nobody, every day.
What the wait actually costs
The wait matters only to the extent that something happens during it. In financial operations, several things reliably do.
| Queue | What decays while it waits |
|---|---|
| Credit applications in review | The applicant takes another offer. Per our stipulations analysis, the best applicants leave first because they have alternatives |
| Collections callbacks | Per our settlement analysis, an engaged consumer is in a state that does not persist |
| Early delinquency outreach | Per our early-stage analysis, the window where contact changes the outcome is days long |
| Fraud alerts | The money leaves while the alert sits, and per our alert analysis reviewers under load dismiss rather than investigate |
| Disputes and exceptions | Per our exception analysis, regulatory clocks keep running |
The first row is the one with the selection effect, and it is the most expensive. A slow queue does not lose applicants at random. It loses the ones with other options, which are disproportionately the ones a lender most wanted, and leaves a funded population that is worse than the approved population was. The queue is not only delaying decisions. It is changing what the portfolio is made of.
Load also degrades the work, not only the wait
At very high utilization, staff respond to the backlog by working faster, which shortens service time and briefly relieves the queue while raising the error rate. Per our consistency analysis, variance in the output is itself a cost, so an operation running at 95% is typically producing both longer waits and less consistent decisions, and the second shows up later and is attributed to something else.
Three ways to move down the curve
There are only three levers on a queue, and they are not equally expensive.
- Add capacity. A sixth reviewer on the five-person team at the 95% load takes average wait from 35.1 minutes to 4.0. One more person removes nearly nine-tenths of the delay, because the team moves off the steep part of the curve.
- Reduce variability. The same single reviewer at 90% with perfectly uniform service times waits 27 minutes instead of 54. Variability in how long cases take is half of the problem, and per our variance analysis it is usually the cheaper half to address.
- Reduce arrivals. Per our ambiguity analysis, a referral rule written loosely sends cases to a queue that did not need them, and tightening it is free capacity.
The second lever is the most underused. Variability comes from mixing quick cases and slow ones in a single line, from incomplete files that stall a reviewer, and from cases that need a second person. Routing complex cases to a separate line, rejecting incomplete files before they enter the queue, and standardizing the work all reduce variability without adding anyone, and the queueing formula says that halving variability is worth as much as substantial extra headcount.
The third lever is often the largest and the least noticed. Per our review economics analysis, a high share of referrals end in the decision the system would have made anyway, and every such referral is load on the queue with no change in outcome.
The case for running hot
There is a defensible version of high utilization, and it should be stated. Where the work is not time-sensitive, nothing decays while it waits, and the customer does not see the queue, idle capacity is pure cost and running at 95% is correct. Batch reconciliation, month-end reporting and back-office cleanup fit that description. The argument against running hot applies to queues where something decays, and most customer-facing financial queues are that kind. The error is applying one utilization target across both types, which is what a single efficiency metric invites, and per our scale analysis it is a common feature of operations that have grown past the point where one manager sees every queue.
Managing a queue on purpose
- Measure wait time directly, from arrival to pickup, not only throughput and utilization.
- Classify each queue by what decays while it waits. Time-sensitive queues need slack; batch queues do not.
- Set utilization targets per queue, and put time-sensitive ones in the 70% to 80% range where the curve is still shallow.
- Separate fast and slow work into different lines to cut variability.
- Stop incomplete cases at the door. A case that stalls mid-review adds variability for everyone behind it.
- Audit what enters the queue. Referrals that never change the outcome are arrivals you are choosing to accept.
- Plan for the peak, not the average. Per our dialer analysis, demand clusters by hour and day, and an operation at 80% on average can be at 105% every Monday morning.
Item seven is where the average misleads most. A queue whose arrival rate exceeds its capacity for part of the day builds a backlog that the quiet hours then work off, and the daily average utilization can look comfortable while customers who arrive at the peak wait for hours. Per our data source analysis, the same arithmetic governs recovery after an outage: a backlog drains only at the rate spare capacity allows, and a team with no spare capacity never drains it.
Frequently asked questions
Waiting scales with utilization divided by idle share. One reviewer waits 54 minutes at 90% and 114 at 95%.
Idle time is visible and attributable while waiting is diffuse and borne by customers, so utilization gets managed and wait does not.
Reducing variability: uniform service times halve the wait. Cutting needless referrals is also free. One extra reviewer at 95% load takes wait from 35.1 to 4.0 minutes.
Yes, for batch work where nothing decays while it waits. Time-sensitive queues need slack, and the mistake is one target for both.
Key takeaways
- One reviewer at 90% utilization keeps cases waiting 54 minutes; at 95% it is 114, and at 98% it is 294.
- A five-person team waits 5.5 minutes at 80% and 35.1 at 95%: 19% more throughput for 6.4 times the wait.
- Operations run hot because idle time is visible and waiting is diffuse, borne by customers, and on no cost line.
- In application queues the best applicants leave first, so delay changes what the portfolio is made of.
- One extra reviewer at the 95% load cuts average wait from 35.1 minutes to 4.0.
- Uniform service times halve the wait, so reducing variability is often cheaper than adding headcount.
- Running hot is correct for batch work where nothing decays; the error is one target for both kinds of queue.
- Plan for the peak: an operation at 80% on average can be above 100% every Monday morning.
This analysis is educational and does not constitute financial or operational advice. All figures are stylized illustrations using standard queueing models with assumed arrival rates, service rates, team sizes, and service time variability, and do not describe any particular operation. Real queues differ from these models in arrival patterns, priority rules, abandonment, and staff behaviour under load, and results will vary. Consult a qualified adviser before making staffing decisions.