Participant Pool Safety Stock: Sizing the Buffer So Recruiting Never Blocks a Study (2026)

Most research teams size their participant panel by feel, discover it was too small at the worst possible moment, and conclude they need to recruit harder. Inventory theory answers the question properly, and the answer is not intuitive: the size of the buffer you need is driven mainly by how unpredictable your recruiting is, not by how much research your organisation asks for.

A participant pool behaves like inventory. Demand arrives irregularly, replenishment takes time, that time itself varies, and running out has a real cost - a study sits blocked while a product decision waits. That is exactly the problem safety stock was invented for, and the standard result transfers directly.

This guide is about the size of the buffer. For how long a single study takes end to end, see research lead time; for why a fully booked team gets slower, see utilisation and queue time. Those cover flow. This covers the cushion.

The formula

Safety stock is the quantity you hold above expected demand so that normal variation does not cause a stockout. The standard form is:

safety stock = Z x sigma_LT

where sigma_LT is the standard deviation of demand over the replenishment lead time, and Z is the service-level factor from the standard normal distribution. Z is the only place your risk appetite enters:

When both demand and lead time vary - which is always true in research - sigma_LT combines the two:

sigma_LT = sqrt( Lbar x sigma_d^2 + dbar^2 x sigma_L^2 )

with dbar the average demand per period, sigma_d its standard deviation, Lbar the average lead time in periods and sigma_L its standard deviation. The reorder point, the level at which you start recruiting again, is then:

reorder point = dbar x Lbar + safety stock

A worked example

Take a team that consumes an average of 12 participants a week with a standard deviation of 5, and whose recruiting takes an average of 3 weeks with a standard deviation of 1 week.

sigma_LT = sqrt( 3 x 25 + 144 x 1 ) = sqrt( 75 + 144 ) = sqrt(219) = 14.8

At a 95% service level, safety stock = 1.645 x 14.8 = 24 participants. The reorder point is 12 x 3 + 24 = 60. In plain terms: start a recruiting push whenever your qualified, available pool drops to 60 people, and hold about 24 as the cushion.

Changing only the service level:

Going from 95% to 99% costs 10 extra people in the pool. That is the price of turning a one-in-twenty blocked study into a one-in-a-hundred, and it is usually worth it.

The finding that changes what you should work on

Look again at what went into sigma_LT. The two terms are not equal:

• Demand variability contributes Lbar x sigma_d^2 = 3 x 25 = 75
• Lead-time variability contributes dbar^2 x sigma_L^2 = 144 x 1 = 144

Lead-time variability accounts for 144 of 219, or about 66% of the variance driving the buffer. The unpredictability of your recruiting matters roughly twice as much as the unpredictability of your demand.

This is not an artefact of the numbers chosen. The lead-time term is multiplied by the square of mean demand, so for any team doing a meaningful volume of research it tends to dominate. The busier you are, the more the lead-time term outweighs the demand term.

Test it by halving each source of variation in turn:

Halving how erratic your recruiting is saves more than twice as much buffer as halving how erratic your demand is. And demand variability is mostly not yours to control - it comes from the roadmap. Recruiting variability is entirely an operations problem.

One more comparison, because it is the one teams get backwards. Cutting the average lead time from 3 weeks to 1.5, with variability unchanged, moves safety stock only from 24 to 22 - but it moves the reorder point from 60 to 40. Faster recruiting mainly reduces the working stock you must hold in transit. Making recruiting more consistent is what reduces the cushion; making it faster is what reduces the total. Both are worth doing, and they are different projects.

Why you cannot pool your way out of it

There is a classic result that tempts people here. If you hold separate buffers for several independent segments, the total buffer you need scales with the square root of the number of segments rather than linearly. Four independent segments pooled into one need about half the total buffer of four separate ones.

The catch is the word independent, and more importantly the word interchangeable. Pooling only works if a participant held for one segment can serve another. In research they usually cannot: an enterprise admin does not substitute for a first-week trial user. So the square-root saving is unavailable exactly where your demand is, and a panel that looks comfortably large in aggregate can be simultaneously out of stock in the one segment a study actually needs.

The operational consequence: track pool depth per segment, not in total. An aggregate number is close to meaningless, and it is the single most common reason a team with a large panel still gets blocked.

Participants are perishable, which ordinary inventory is not

Three caveats keep this model honest.

Holding cost is real and unusual. Panel members go stale. They become less representative of new users the longer they have been on the panel, and repeated participation changes how they answer. So oversizing the buffer is not free in the way holding extra widgets is - it degrades the asset. See panel management for the maintenance side.

Attrition means the pool leaks. Your available pool is not the number of people on the list. It is the number who are reachable, still qualify, and have not participated too recently. Apply your realistic response rate to the list before doing any of this arithmetic, or you will hold a buffer that exists only on paper.

The normal approximation has limits. The Z-factor table assumes demand over lead time is roughly normally distributed. If your research demand is lumpy - three studies land in one week and nothing for a month - the tail is fatter than the model assumes and the true service level will be worse than the stated one. Treat the output as a well-reasoned floor rather than a precise guarantee, and prefer a higher Z when demand is genuinely bursty.

How Koji handles this

Because recruiting-time variability is the dominant term, anything that removes a source of schedule uncertainty has outsized effect on the buffer you must carry.

• No scheduling step. Koji interviews are asynchronous and unmoderated, so there is no calendar coordination between participant and researcher. Scheduling is normally the largest single contributor to sigma_L, and removing it attacks the term that dominates the formula.
• No no-shows to absorb. A moderated study plans for missed sessions, which widens the spread of how long fielding takes. A Koji study does not have a session to miss - participants complete when they choose.
• No moderator availability constraint. Koji runs any number of interviews in parallel, so fielding time does not stretch because a researcher was busy. That removes a second independent source of lead-time variance.
• Faster cycles mean a smaller working stock. Because Koji analyses interviews automatically and produces reports without a manual synthesis stage, the whole replenishment cycle shortens, which is what lowers the reorder point.
• Structured profile questions keep segment depth measurable. Koji supports six question types - open_ended, scale, single_choice, multiple_choice, ranking and yes_no - so panel attributes can be captured as countable single_choice or yes_no items rather than free text, which is what makes per-segment pool depth something you can actually query. The structured questions guide covers each type.
• Low marginal cost per interview changes the trade-off. When each additional interview is inexpensive, a higher service level costs less to hold, so teams using Koji can reasonably run at 99% where a moderated team would settle for 90%.

The honest limit: Koji shortens and stabilises the fielding step. It does not recruit for you. If your participants come from a slow, unpredictable source - a partner list, an intermediary, a hard-to-reach professional segment - that variance stays in sigma_L and stays in your buffer.

Frequently asked questions

How big should my research participant panel be?

Size it as a reorder point rather than a single number: average weekly demand multiplied by average recruiting lead time, plus a safety stock of Z x sigma_LT. For a team using 12 participants a week with a standard deviation of 5, and recruiting that takes 3 weeks with a standard deviation of 1, a 95% service level implies 24 participants of safety stock and a reorder point of 60. Recalculate per segment, because segments are not interchangeable.

Why does recruiting variability matter more than demand variability?

Because of how the two terms enter the formula. Demand variability contributes average lead time multiplied by the variance of demand, while lead-time variability contributes the variance of lead time multiplied by the square of average demand. In the worked example the lead-time term accounts for about 66% of the total variance, and its share grows as research volume grows. Halving recruiting variability cut the required buffer by 29% against 12% for halving demand variability.

What service level should a research team target?

Between 95% and 99% for most teams. The step from 95% to 99% costs about 10 extra people in the worked example, against a benefit of turning one blocked study in twenty into one in a hundred. Because Koji makes each additional interview inexpensive, holding the higher service level is cheaper than it would be for a team running moderated sessions, so aim high unless your participants are genuinely scarce.

Can I just hold one big pool instead of per-segment buffers?

No, and this is the most common expensive mistake. Pooling only reduces the required buffer when participants are interchangeable across segments, which they rarely are - an enterprise administrator does not substitute for a trial user. A panel that looks large in aggregate can be out of stock in the exact segment a study needs. Track depth per segment.

Does this apply if I recruit fresh for every study rather than keeping a panel?

Yes, with the buffer expressed as time instead of people. If you do not hold a pool, your cushion is the slack between when recruiting starts and when the study must begin, and the same arithmetic tells you how much slack the variability of your recruiting requires. Teams that recruit fresh every time are carrying the buffer in the schedule, usually without having measured it.

What is the first thing to measure?

The spread of your recruiting lead time, not the average. Most teams can tell you that recruiting takes about three weeks and cannot tell you the standard deviation, yet that second number drives most of the buffer. Log the start and finish of fielding for your next ten studies and compute it - it is the highest-value measurement in research operations that almost nobody takes.

Related Resources

• Structured Questions in AI Interviews - the six question types, including the ones that make panel attributes countable
• Research Lead Time and Little's Law - the flow identity this buffer sits alongside
• Utilisation and Queue Time - why a fully booked team is slower
• How to Build a Research Participant Panel - building and maintaining the pool itself
• Research Screener Questions - qualifying the pool so depth figures mean something
• Recruiting from Communities and Events - widening the replenishment sources