Your sales history does not record what customers wanted. It records what you managed to ship. For any item that ever ran out, those are different numbers, and the gap is largest exactly where it hurts most.
The mechanism, in one paragraph
When an item is in stock, sales and demand are the same thing. When it goes out of stock, demand continues and sales stop. The order line does not appear in your system: the contractor asks, hears "two weeks", and buys it from the branch down the road. Nothing about that lost sale is recorded anywhere. Statisticians call this censored data. You observe the outcome only up to a limit imposed by the process itself. Your sales curve is not a measurement of demand; it is a measurement of the minimum of demand and availability.
Why this specifically breaks new-item buying
The damage is not spread evenly. Stock-outs cluster in the launch window of successful items, because that is when a first buy sized on a guess collides with demand that exceeded it. So the products whose history is most distorted are your winners, and those are exactly the products you pull up as comparables when you size the next first buy.
That closes a loop worth stating plainly. A first buy that was too small causes a stock-out. The stock-out truncates the sales curve. The truncated curve becomes the evidence for the next first buy. The next first buy is too small for the same reason. Nothing in the data ever contradicts the original mistake, and the method reproduces it item after item, year after year. This is not a forecasting error that averages out. It is a bias that only ever points one way.
A worked example you can rebuild in Excel
Take a valve you launched with a first buy of 400 units. The weekly sales your system recorded:
| Week | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
|---|---|---|---|---|---|---|---|---|
| Units sold | 38 | 52 | 61 | 64 | 3 | 0 | 58 | 60 |
| In stock | yes | yes | yes | yes | no | no | yes | yes |
Recorded total over eight weeks: 336 units. That is the number that ends up in your comparables file, and it is wrong in a knowable direction. Weeks 5 and 6 are not demand observations at all: the shelf was empty. The honest reconstruction is to ignore them and use what the item did when it could actually be bought: the last week in stock before the gap sold 64, the first week back in stock after it sold 58. Averaging those two puts each missing week at 61, so demand over the eight weeks was 455 units, not 336.
That is 35% higher. Put the other way round, your sales record captured 74% of what customers actually wanted. It was short by about a quarter. Size the next comparable item off the recorded 336 and you under-buy by that much again, and the new item probably runs out too, producing another censored curve. In Excel this is one column of in-stock flags and an AVERAGE of the two surrounding in-stock weeks. =AVERAGE(64,58) is the whole correction. The difficulty was never the arithmetic; it is that the flags are usually not in the export.
These are the figures this site's own engine produces from the table above: the same correction it applies to your file when you upload one, not a worked example maintained separately from the code.
What to do about it, in order of effort
Get the availability flag into your export. Most ERPs can report whether an item had stock on hand at the end of each week or period. That single extra column turns a guess into a correction. It is the highest-value change you can make to your own data, and it costs one conversation with whoever writes the reports.
Failing that, detect the shape. A stock-out has a recognisable signature: sales collapse to near zero from a healthy level, stay there briefly, then recover to roughly the previous level. Genuine decline looks nothing like that. It slopes down and stays down. Flagging the collapse-and-recover pattern catches most stock-outs without any availability data, which is what SKUZero does automatically when your file has no stock column.
Then impute, conservatively. Replace the censored weeks with the level of the surrounding weeks, as above. Do not try to model how much extra demand the stock-out itself destroyed. A stock-out at launch also costs you customers who never come back, and that effect is real but not recoverable from this data. A conservative correction that admits it is conservative beats an elaborate model of something you cannot observe.
Why nobody mentions this
Replenishment systems mostly do not need to care. For an established item you reorder frequently, errors get corrected within a cycle or two, and a service level target does the work implicitly. The first buy has none of those safety nets: one decision, one shot, and the evidence you are reasoning from is systematically biased downwards. That is why a tool built for this decision has to treat censoring as a first-class concept rather than a data-quality footnote, and why SKUZero flags every censored launch in your upload, tells you which weeks it corrected, and shows you the corrected curve next to the recorded one before it uses either.
There is a pleasant side effect. Once you start marking stock-outs in your launch history, you also acquire an honest record of what your fill rate has actually cost you on new items, which is a far more persuasive number in a stocking discussion than anyone's recollection of that valve two years ago.