Why a Fully Booked Research Team Is Slower: Utilisation, Queue Time, and the 85% Rule
Queue time scales with utilisation divided by one minus utilisation. Moving a research team from 70% to 95% booked makes it about eight times slower to answer anything.
Bottom line up front: A research team booked to 95 percent of its capacity is not 36 percent busier than one booked to 70 percent. It is roughly eight times slower to answer anything. Queue time rises with utilisation divided by one minus utilisation, which is a hyperbola, not a line: the last slice of capacity you reclaim costs more delay than all the previous slices combined. Deliberate idle capacity is not waste in a research function. It is the mechanism that produces speed, and it has to be scheduled on purpose because nothing else will create it.
The reflex that makes research slower
Once a team understands that lead time is work-in-progress divided by throughput, the natural next move is to attack throughput: get more done, keep everyone productive, leave no researcher unbooked. Idle time looks like the obvious enemy. A researcher with a free afternoon looks like money on the floor.
This is where the arithmetic inverts on you. Pushing a team toward full booking is the single most reliable way to make every study late, and the effect is not gradual. It accelerates.
The reason is that a research function is a queue with variable arrivals and variable service times, and such systems have a well-characterised and deeply counterintuitive property: as utilisation approaches one, waiting time approaches infinity. Not "gets worse." Approaches infinity.
The curve nobody plans against
For a single-server queue with random arrivals, the expected number of items waiting scales with ρ / (1 - ρ), where ρ is utilisation — the fraction of available capacity that is committed.
| Utilisation | ρ / (1 - ρ) | Relative queue time |
|---|---|---|
| 50% | 1.00 | 1.0x |
| 60% | 1.50 | 1.5x |
| 70% | 2.33 | 2.3x |
| 75% | 3.00 | 3.0x |
| 80% | 4.00 | 4.0x |
| 85% | 5.67 | 5.7x |
| 90% | 9.00 | 9.0x |
| 95% | 19.00 | 19.0x |
| 98% | 49.00 | 49.0x |
Read the last rows slowly. Moving a research team from 70 percent booked to 95 percent booked increases queue time by a factor of 8.1. Moving from 85 to 95 — which any manager would describe as a modest tightening — multiplies it by 3.4. Moving from 90 to 95 still doubles it.
The managerial intuition that fails here is linearity. Booking 95 percent of capacity instead of 70 percent feels like a 25-point change, and 25 points of anything sounds moderate. But the quantity that matters is the remaining capacity, and that fell from 30 points to 5 — a sixfold reduction in the system's ability to absorb anything unexpected.
Variability is the second multiplier, and research has plenty
Utilisation is only half of it. Kingman's approximation for the single-server queue — from J. F. C. Kingman's "The single server queue in heavy traffic," Proceedings of the Cambridge Philosophical Society 57(4):902-904, 1961 — expresses average wait as the product of three terms, usually written as VUT:
Wait ≈ (variability term) × (utilisation term) × (average service time)
The utilisation term is the ρ / (1 - ρ) hyperbola above. The variability term captures how irregular arrivals and service durations are. And the two multiply, which means variability and high utilisation are not two separate problems that add up. They amplify each other.
Worked with moderate variability (coefficient of variation of 1 for both arrivals and service) and an average study absorbing five working days of effort:
| Utilisation | Expected queue time | Total lead time |
|---|---|---|
| 70% | 11.7 days | 16.7 days |
| 85% | 28.3 days | 33.3 days |
| 95% | 95.0 days | 100.0 days |
The work is five days in every row. At 95 percent utilisation the requester waits about twenty weeks for five days of effort.
Research is a high-variability queue by nature, which pushes it up this curve faster than most functions:
- Arrivals are unpredictable. Research requests are triggered by roadmap changes, competitor moves, board questions, and incidents. They do not arrive at a steady rate.
- Service times vary enormously. A pricing study and a copy test both count as "a study" and can differ by a factor of ten in effort.
- Scope changes mid-service. A study that grows a second audience halfway through is a service-time shock.
- Recruitment failure is a restart, not a delay. A screener that under-delivers can send an item back to the start of its own service.
Every one of these inflates the variability term, and the variability term multiplies the utilisation term. A research function running at 90 percent with high variability is not in the same world as a factory running at 90 percent with low variability.
Where running it hot was tried for real
The strongest evidence that this curve governs real organisations, and not just models, comes from a domain where idle capacity is politically hardest to defend: hospital beds.
In 1999, Bagust, Place, and Posnett published "Dynamics of bed use in accommodating emergency admissions: stochastic simulation model" in the BMJ (319(7203):155-158). They modelled a hypothetical English acute hospital to quantify the daily risk of having no bed available for a patient needing immediate admission. Their finding, stated plainly in the paper:
"Risks are discernible when average bed occupancy rates exceed about 85%, and an acute hospital can expect regular bed shortages and periodic bed crises if average bed occupancy rises to 90% or more."
And their conclusion:
"Spare bed capacity is therefore essential for the effective management of emergency admissions, and its cost should be borne by purchasers as an essential element of an acute hospital service."
Two things are worth extracting. First, the number: around 85 percent is where a variable-demand queue begins to break down, which is exactly where the hyperbola above starts to bend sharply. Second, and more important for research leaders, the framing. The authors did not argue that spare capacity is an unfortunate inefficiency to be minimised. They argued it is an essential element of the service whose cost should be explicitly funded.
That is the argument a research leader has to make, and it is far easier to make with a peer-reviewed precedent from a domain where the stakes are higher and the budget pressure is worse.
Utilisation you cannot see is still utilisation
The practical obstacle is that most research functions have no idea what their utilisation is, and the ways they estimate it are biased low.
Calendars undercount. Time spent on a study includes reading, thinking, writing, and the recovery cost of switching between studies — none of which appear as meetings. Sophie Leroy's research on attention residue (Organizational Behavior and Human Decision Processes 109(2):168-181, 2009) found that people perform worse on a new task when a prior task was left unfinished, because attention stays partly committed to the unfinished work. A researcher juggling four open studies is not four-quarters utilised; the switching itself consumes capacity that never appears on any timesheet.
Three practical corrections:
- Count non-study work as committed capacity. Recruitment admin, tool maintenance, stakeholder education, onboarding, and repository upkeep are real load. If they consume a day a week, the team's available capacity is 80 percent of nominal before a single study starts.
- Treat unfinished studies as partial occupancy. Anything open is holding some fraction of someone's attention. This is why WIP limits and utilisation targets are the same policy viewed from two angles.
- Measure the queue, not the calendar. You do not need accurate utilisation to know you are too far up the curve. If lead time is growing while throughput is flat, ρ has risen. That is diagnostic on its own.
Setting a target you can actually hold
The goal is not low utilisation for its own sake. It is choosing a point on the curve deliberately rather than drifting to the top of it.
| Target | What it buys | When it fits |
|---|---|---|
| 60-70% | Fast turnaround, absorbs shocks | Teams serving live decisions with short notice |
| 70-80% | Balanced; occasional slippage | Most product research functions |
| 80-85% | Efficient, fragile | Predictable roadmap-driven pipelines only |
| Above 85% | Queue grows without bound under variability | Not a viable steady state |
Holding a target requires three things that are organisational, not technical. A WIP limit, so new work cannot start merely because someone asked. A published lead time, so the cost of raising utilisation is visible to the people requesting it. And a named owner of the buffer, because unowned slack is the first thing reallocated in any planning cycle.
Reserving capacity works better when the reserve has a job. Naming the buffer "rapid response" and committing to a short turnaround for anything that fits it converts idle time from something that looks like waste into a service the organisation values — and it is exactly the capacity that lets you say yes to the decisions that arrive with short notice.
How Koji changes the trade-off
Everything above is a consequence of capacity being scarce, human, and serial. AI-native research attacks the constraint itself rather than asking a team to accept a worse trade-off between speed and busyness.
- Parallel AI-moderated interviews break the one-moderator-one-session limit. Because the service rate for fieldwork rises, the same volume of demand sits at a much lower ρ — you move down the hyperbola without anyone working less.
- Automatic thematic analysis cuts the service time term directly. Kingman's equation multiplies by average service time, so halving it halves the wait at every utilisation level.
- Voice and text interviews remove scheduling round-trips, which is a reduction in the variability term rather than the utilisation term. Because the two multiply, this is worth more than it looks.
- Customisable AI consultants and real-time reporting shrink the queue for scarce senior reviewers, which is usually the most heavily utilised single server in the whole function.
- Structured questions let one study answer what previously took two. Koji supports six types —
open_ended,scale,single_choice,multiple_choice,ranking, andyes_no— so a single instrument returns both a distribution and the reasoning behind it. Removing an item from the queue entirely is the cleanest possible reduction in ρ.
The deeper change is what it does to the politics. When a researcher-hour is the scarce resource, protecting idle capacity means arguing that expensive people should sometimes do nothing, which is a hard argument to win. When the platform absorbs the parallelisable work, the team's reserved capacity is spent on judgement — framing questions, challenging findings, deciding what not to study — and that reserve is much easier to defend as a service rather than as slack.
Common mistakes
Treating utilisation as a performance metric. A team at 95 percent looks productive on a resourcing spreadsheet and is failing every stakeholder in its queue. If utilisation is reported upward at all, report it alongside lead time so the trade-off is visible.
Cutting the buffer to absorb a one-off. Every urgent request is a one-off. Absorbing them by raising ρ works exactly once, then becomes the new baseline and the queue never recovers.
Adding headcount without a WIP limit. New capacity raises throughput, but if intake is uncapped it gets absorbed by additional open studies at the same utilisation, and lead time barely moves. Set the WIP limit first so the new capacity shows up as speed.
Assuming averages are safe. These curves describe average wait. At 90 percent utilisation the distribution has a long right tail, so the worst month is far worse than the model, and the worst month is what stakeholders remember.
Confusing this with prioritisation. Reordering the queue changes who waits. Lowering utilisation changes how long everyone waits. They are different levers and only one of them makes the function faster.
Frequently asked questions
What is a good utilisation target for a research team?
Most product research functions should target 70 to 80 percent of nominal capacity committed to studies. Above 85 percent, queue time grows sharply because waiting scales with utilisation divided by one minus utilisation, and research has highly variable arrivals and service times that amplify the effect. Below 60 percent is usually only justified for teams supporting live decisions with very short notice periods.
Why does queue time explode near full utilisation?
Because the relevant quantity is the capacity left over, not the capacity used. Going from 70 to 95 percent utilisation sounds like a 25-point change but cuts spare capacity from 30 points to 5, a sixfold reduction in the system's ability to absorb variability. The queue-time multiplier rises from 2.33 to 19.0 — about eight times worse.
Is idle time in a research team wasted money?
No. In a queue with variable demand, unused capacity is what converts arriving work into fast answers. Bagust and colleagues made this argument for hospital beds in the BMJ in 1999, concluding that spare capacity is an essential element of the service whose cost should be explicitly funded. The same logic applies to research: the buffer is what you are buying speed with.
How do I measure my research team's utilisation?
Calendars undercount it, so start with a rough estimate rather than a precise one. Subtract non-study load (recruitment admin, tooling, stakeholder work) from nominal capacity, then estimate the share of what remains that is committed to open studies. A more reliable signal is directional: if lead time is rising while throughput is flat, utilisation has increased regardless of what any timesheet says.
Does reducing variability help as much as reducing utilisation?
Often more, because Kingman's equation multiplies the variability term by the utilisation term. Standardising study types, capping scope changes mid-study, and removing scheduling round-trips all cut variability. A team that cannot politically lower utilisation can still cut wait times substantially by making arrivals and service times more regular.
Should I hire or lower utilisation first?
Lower utilisation first, because it is immediate and free, and because hiring into an uncapped intake process usually raises work-in-progress rather than speed. Once a WIP limit and a utilisation target are being held, added headcount converts cleanly into shorter lead times instead of more open studies.
Related Resources
- Research Lead Time: Why a Six-Day Study Takes Six Weeks — the Little's Law arithmetic this article builds on.
- How to Build a Research Request and Intake Process — where a WIP limit is actually enforced.
- The Questions Nobody Asks You — what a slow queue does to the demand you never see.
- Structured Questions Guide — the six question types that remove whole studies from the queue.
- How to Scale Your User Research Practice — capacity models as a team grows.
- Research Pipeline Yield — the quality analogue of this capacity argument.
Related Articles
How to Build a Research Request and Intake Process
A step-by-step guide to designing a research intake process: the request form fields that matter, how to triage and prioritize incoming requests, SLAs, and how AI-native research lets you say yes to more requests without adding headcount.
Research Lead Time: Why a Six-Day Study Takes Six Weeks (Little's Law for Research Teams)
Research lead time is set by work-in-progress divided by throughput, not by how long a study takes. Little's Law, worked examples, and how to cut the wait.
Research Pipeline Yield: Why Every Stage Passes and the Finding Still Arrives Wrong
Research stages sit in series, so their pass rates multiply rather than average. Seven stages at 95 percent deliver a correct finding 69.8 percent of the time. How to run a yield audit and fund the lowest stage.
How to Scale Your User Research Practice
A practical guide to building a research operation that generates more insights with the same headcount — using automation, democratization, and continuous research pipelines.
Structured Questions in AI Interviews
Mix quantitative data collection — scales, ratings, multiple choice, ranking — with AI-powered conversational follow-up in a single interview.
The Questions Nobody Asks You: How a Slow Research Function Hides Its Own Demand (2026)
Your research backlog is a sample of the questions someone already believed you could answer in time. Measure the fraction of decisions whose notice period exceeds your lead time.