{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-09-23T13:44:57.447Z"},"content":[{"type":"documentation","id":"90086b34-b696-4e24-8d58-7e00c5725eb9","slug":"participant-pool-safety-stock","title":"Participant Pool Safety Stock: Sizing the Buffer So Recruiting Never Blocks a Study (2026)","url":"https://www.koji.so/docs/participant-pool-safety-stock","summary":"A participant pool behaves like inventory, so safety stock theory sizes it exactly. Safety stock equals Z multiplied by sigma_LT, where sigma_LT is sqrt(Lbar x sigma_d^2 + dbar^2 x sigma_L^2), and the reorder point is dbar x Lbar plus safety stock. In a worked example of 12 participants per week (standard deviation 5) and a 3-week recruiting lead time (standard deviation 1 week), sigma_LT is 14.8, giving 24 participants of safety stock and a reorder point of 60 at a 95% service level. The decisive finding is that lead-time variability contributes 144 of the 219 total variance, about 66%, because it is multiplied by the square of mean demand; halving recruiting variability cuts the required buffer by 29% against 12% for halving demand variability. Cutting mean lead time reduces working stock rather than safety stock. Risk pooling does not help because participants are not interchangeable across segments, so pool depth must be tracked per segment. Caveats: participants are perishable, pools leak through attrition, and the normal approximation understates risk when demand is bursty.","content":"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.\n\nA 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.\n\nThis guide is about the size of the buffer. For how long a single study takes end to end, see [research lead time](/docs/research-lead-time-littles-law); for why a fully booked team gets slower, see [utilisation and queue time](/docs/research-team-utilization-queue-time). Those cover flow. This covers the cushion.\n\n## The formula\n\nSafety stock is the quantity you hold above expected demand so that normal variation does not cause a stockout. The standard form is:\n\n**safety stock = Z x sigma_LT**\n\nwhere 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:\n\n| Target service level | Z | Meaning |\n| --- | --- | --- |\n| 90% | 1.282 | One replenishment cycle in ten runs short |\n| 95% | 1.645 | One in twenty |\n| 97.5% | 1.960 | One in forty |\n| 99% | 2.326 | One in a hundred |\n\nWhen both demand and lead time vary - which is always true in research - sigma_LT combines the two:\n\n**sigma_LT = sqrt( Lbar x sigma_d^2 + dbar^2 x sigma_L^2 )**\n\nwith 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:\n\n**reorder point = dbar x Lbar + safety stock**\n\n## A worked example\n\nTake 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.\n\nsigma_LT = sqrt( 3 x 25 + 144 x 1 ) = sqrt( 75 + 144 ) = sqrt(219) = 14.8\n\nAt 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.\n\nChanging only the service level:\n\n| Service level | Safety stock | Reorder point |\n| --- | --- | --- |\n| 90% | 19 | 55 |\n| 95% | 24 | 60 |\n| 99% | 34 | 70 |\n\nGoing 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.\n\n## The finding that changes what you should work on\n\nLook again at what went into sigma_LT. The two terms are not equal:\n\n- Demand variability contributes Lbar x sigma_d^2 = 3 x 25 = **75**\n- Lead-time variability contributes dbar^2 x sigma_L^2 = 144 x 1 = **144**\n\nLead-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.\n\nThis 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.\n\nTest it by halving each source of variation in turn:\n\n| Change | New sigma_LT | Safety stock at 95% | Reduction |\n| --- | --- | --- | --- |\n| Baseline | 14.8 | 24 | - |\n| Halve demand variability (sigma_d 5 to 2.5) | 12.8 | 21 | 12% |\n| Halve recruiting variability (sigma_L 1 to 0.5) | 10.5 | 17 | 29% |\n\nHalving 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.\n\nOne 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.\n\n## Why you cannot pool your way out of it\n\nThere 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.\n\nThe 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.\n\nThe 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.\n\n## Participants are perishable, which ordinary inventory is not\n\nThree caveats keep this model honest.\n\n**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](/docs/research-panel-management) for the maintenance side.\n\n**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.\n\n**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.\n\n## How Koji handles this\n\nBecause recruiting-time variability is the dominant term, anything that removes a source of schedule uncertainty has outsized effect on the buffer you must carry.\n\n- **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.\n- **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.\n- **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.\n- **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.\n- **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](/docs/structured-questions-guide) covers each type.\n- **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%.\n\nThe 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.\n\n## Frequently asked questions\n\n### How big should my research participant panel be?\n\nSize 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.\n\n### Why does recruiting variability matter more than demand variability?\n\nBecause 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.\n\n### What service level should a research team target?\n\nBetween 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.\n\n### Can I just hold one big pool instead of per-segment buffers?\n\nNo, 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.\n\n### Does this apply if I recruit fresh for every study rather than keeping a panel?\n\nYes, 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.\n\n### What is the first thing to measure?\n\nThe 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.\n\n## Related Resources\n\n- [Structured Questions in AI Interviews](/docs/structured-questions-guide) - the six question types, including the ones that make panel attributes countable\n- [Research Lead Time and Little's Law](/docs/research-lead-time-littles-law) - the flow identity this buffer sits alongside\n- [Utilisation and Queue Time](/docs/research-team-utilization-queue-time) - why a fully booked team is slower\n- [How to Build a Research Participant Panel](/docs/research-panel-management) - building and maintaining the pool itself\n- [Research Screener Questions](/docs/research-screener-questions) - qualifying the pool so depth figures mean something\n- [Recruiting from Communities and Events](/docs/recruiting-participants-communities-events) - widening the replenishment sources\n","category":"Research Operations","lastModified":"2026-09-23T03:33:39.707749+00:00","metaTitle":"Participant Pool Safety Stock: How Big Should Your Research Panel Be?","metaDescription":"Recruiting variability, not demand variability, drives how big your participant pool must be. The safety stock formula applied to research panels.","keywords":["participant pool size","research panel size","safety stock formula","recruiting lead time","research operations","participant recruitment planning","reorder point","service level","research panel management","research ops metrics"],"aiSummary":"A participant pool behaves like inventory, so safety stock theory sizes it exactly. Safety stock equals Z multiplied by sigma_LT, where sigma_LT is sqrt(Lbar x sigma_d^2 + dbar^2 x sigma_L^2), and the reorder point is dbar x Lbar plus safety stock. In a worked example of 12 participants per week (standard deviation 5) and a 3-week recruiting lead time (standard deviation 1 week), sigma_LT is 14.8, giving 24 participants of safety stock and a reorder point of 60 at a 95% service level. The decisive finding is that lead-time variability contributes 144 of the 219 total variance, about 66%, because it is multiplied by the square of mean demand; halving recruiting variability cuts the required buffer by 29% against 12% for halving demand variability. Cutting mean lead time reduces working stock rather than safety stock. Risk pooling does not help because participants are not interchangeable across segments, so pool depth must be tracked per segment. Caveats: participants are perishable, pools leak through attrition, and the normal approximation understates risk when demand is bursty.","aiPrerequisites":["Basic familiarity with research operations and participant recruitment","Comfort with standard deviation and simple algebra"],"aiLearningOutcomes":["Calculate the safety stock and reorder point for a participant pool from demand and lead-time statistics","Explain why lead-time variability dominates the buffer calculation","Choose a service level and understand what it costs in pool size","Explain why risk pooling across participant segments does not work","Identify the limits of the model, including participant perishability, attrition and bursty demand"],"aiDifficulty":"intermediate","aiEstimatedTime":"12 min"}],"pagination":{"total":1,"returned":1,"offset":0}}