The forecast is not the deliverable
A demand forecast for an online store is a means to an end, and the end is a purchase order with a number on it. That sounds obvious and it is the thing most projects get wrong. A team spends eight weeks pulling weighted error on the top two hundred SKUs from 48 percent down to 41 percent, presents the improvement, and nothing about the buying changes. The buyer was never blocked on accuracy. She was blocked on a minimum order quantity of 500 units, a case pack of 24, a container that has to be filled to be worth shipping, and a credit line that decides how much inventory the business can hold at one time. Start from the purchase order and work backwards, and the modeling question gets both smaller and more answerable.
Three numbers per SKU come out of a working system, and only three. Whether to place an order this cycle. How many units, expressed in something the supplier will accept. And what the site should promise about availability between now and the next receipt. Everything upstream of those three exists to serve them. If a piece of the pipeline does not change one of those numbers, it is decoration.
You are probably here because
- A best seller was out of stock for three weeks and the listing has not recovered
- The warehouse is full of a colorway nobody wanted and nobody is quite sure how it got there
- Forecast accuracy improved and the in-stock rate did not move at all
- Every buying decision runs through one spreadsheet and one person, and that person is going on leave
The first two are almost always a data problem rather than a model problem, and the sections on lead time and censored history cover them. The third is a measurement problem. The fourth is the one worth paying to fix.
Lead time is the horizon. Everything else is a preference.
Ask what the forecast horizon should be and you will get answers like “a quarter” or “twelve weeks, that feels right.” The horizon is not a preference. It is the total replenishment lead time plus the review period, and it is measurable from data you already have.
For an imported private-label product the clock runs like this: the purchase order goes out, the supplier acknowledges and schedules, production takes roughly thirty to sixty days, the freight forwarder books a sailing, ocean transit runs about twenty-five to forty days port to port, then drayage, deconsolidation and receiving at the third-party warehouse add another five to fifteen business days before a unit is sellable. Ninety to a hundred and fifty days door to door is ordinary. A domestic supplier on a two to four week turn is a completely different business, and the same software serving both needs a per-supplier lead time, not a global constant.
Two consequences fall out of this and both get missed. First, if you buy weekly on a hundred-and-ten-day lead time, the thing you need is the distribution of cumulative demand over about seventeen weeks, not a tidy week-by-week path. Teams build a weekly forecast, then feed it into a safety stock formula that wanted the variance of lead-time demand, and the two quietly disagree.
Second, lead time variance often matters more than demand variance. If your received dates swing by three weeks either side of plan, that swing dominates the buffer. Almost nobody has computed the standard deviation of their own lead times, and it is sitting in the purchase order table: order date, promised date, actual receipt date, per supplier, per lane. That is a one-afternoon query and it regularly reorders the whole project plan.
Your sales history is not your demand history
This is the defect that ruins the most models and it is invisible in a chart. If a SKU was unavailable for nine days last month, last month's units understate what customers wanted. Retrain naively and the model learns that demand fell. You order less. You stock out sooner. The forecast falls again. On a dashboard it looks like a product going quietly out of fashion; in the store data the product page conversion rate never moved.
The repair is not sophisticated. Mark out-of-stock days and treat those days as missing rather than as zeros. A serviceable version imputes from in-stock days of the same weekday within a short window. A better version fits on in-stock periods only and treats the gaps as right-censored observations. Either beats training on the raw number.
Both require something most stores do not have: a daily availability history, one row per SKU per location per day, recording on-hand and whether the item was buyable. Your platform holds current stock and overwrites it. Once a day is gone it cannot be reconstructed. Writing that snapshot is about fifty lines of code and a scheduled job, and it is the highest-value data asset in the entire project. If you do nothing else after reading this, start the snapshot this week. Everything else can be built later against the history you are accumulating now.
Most of your catalog is intermittent, and the usual tools are wrong for it
A nine-hundred-SKU catalog is really two catalogs. The top forty items carry something like two-thirds to three-quarters of units and behave like well-mannered time series. The tail sells zero units in most weeks and one or two in the others. Exponential smoothing applied to a mostly-zero series returns a smooth positive number like 0.7 units per week, which is never a possible outcome and is a poor basis for a buffer.
Two things help. Croston's method and the Syntetos-Boylan variant handle intermittent series by modelling demand size and the gap between demands separately, which is the actual structure of the data. And for the tail specifically, stop forecasting weekly at all: bootstrap the total over a lead-time-length window directly from history and read the quantile you need off the empirical distribution. It is simpler than it sounds and it answers the only question you were asking, which is how many units cover the next seventeen weeks with the confidence you want.
Before choosing any method, classify the catalog by average interval between demands and the variability of demand size. The four-quadrant split into smooth, erratic, intermittent and lumpy takes an afternoon and decides more than the model choice does. It also tells you honestly which SKUs no method will forecast well, which is worth knowing before you promise anyone a number.
Service level is a money decision, not a policy
Somebody picks 95 percent because it sounds responsible. It is not a policy, it is a purchase, and the right level differs by SKU because the two costs differ by SKU. The classic ratio is the cost of being short divided by the sum of the cost of being short and the cost of holding a spare unit.
Shortage cost is the lost contribution margin, plus the ranking decay a marketplace listing suffers when it goes unavailable, plus the paid traffic you keep sending to a page nobody can buy from. Overage cost is carrying cost, usually somewhere between twenty and thirty percent annually once capital, space, insurance and shrink are counted, plus the probability of markdown times the depth of that markdown.
Run that per archetype and the answers spread out. A nine-dollar consumable with a twelve-month shelf life and healthy margin wants a very high fill rate; the leftovers sell eventually. A hundred-and-forty-dollar seasonal apparel item wants a lower one, because the leftovers get marked forty percent off in January and the arithmetic is brutal. A single catalog-wide service level is the most common default and the most expensive one.
One vocabulary trap while you are here. Cycle service level is the probability of not stocking out during a replenishment cycle. Fill rate is the fraction of demanded units actually served. They are different numbers, executives say one and mean the other, and a 95 that was meant as fill rate and implemented as cycle service level will hold materially more inventory than anyone signed off on.
| SKU archetype | What to optimize | Sensible starting target | What goes wrong |
|---|---|---|---|
| Top-decile core item steady, long-lived | Fill rate; never go dark | 97–99% fill | Buffer set from demand variance while lead time swings three weeks |
| Long-tail staple 1–2 units a week | Cover over the lead-time window | 90–95% cycle service | Weekly smoothing on a mostly-zero series |
| Seasonal or fashion one selling window | Sell-through by end of season | 85–92%, deliberately short | Same service level as the core, then a January markdown |
| New launch under 12 weeks live | Range, not point; re-buy speed | Buy small, decide at week 4 | A first buy sized off a marketing plan nobody validated |
| Component in a kit | Combined demand across parent SKUs | Match the strictest parent | Kit sales never flow through to component demand |
The four constraints the model does not know about
A recommendation of 173 units is not an answer when the case pack is 24 and the minimum order is 500. Turning a forecast into a purchase order is a small constrained optimization, and it is arithmetic rather than machine learning, which is exactly why it gets skipped.
Case pack and minimum order. Round up or down to a shippable quantity, and decide the rule deliberately. Rounding always up on a long tail is how a warehouse fills with three years of cover on slow items.
Container fill. If you are shipping a forty-foot container, the marginal cost of the last unit is close to zero and the marginal cost of a second container is enormous. So the real question is which SKUs get the leftover cube, and the answer is the ones with the highest expected value per cubic foot, not the ones with the highest forecast.
Open to buy. Cash caps the order. When the unconstrained plan exceeds the budget, something has to give, and letting a planner cut lines by feel at 6pm on a Thursday is how the top sellers get trimmed to fund a hunch.
Supplier calendar. Factories close for holidays. A two-week closure inside a hundred-day lead time moves receipt dates for every line on the order and it is knowable months ahead. Put it in the calendar table, not in someone's memory.
Where the recoverable error usually comes from — our ranking
Our ranking across the inventory work we are called into, not a measurement of your catalog. The ordering is the useful part: model choice is last, and it is where most projects start.
New products, and why cold start never ends
If you launch ten to fifteen SKUs a quarter, a standing share of the catalog has under twelve weeks of history at any moment. Cold start is not a phase you get through, it is a permanent operating condition, and a system that handles it only at onboarding will be wrong forever.
What works is unglamorous: analog-based priors from product attributes, meaning category, price band, colour family, and which channel the launch is being pushed through, blended with actual sell-through as soon as three or four weeks of it exist. The blend should move fast. Real data on a new SKU beats an analog quickly, and systems that weight the prior for a full quarter are still buying to a guess in month three.
Be honest about the first buy. For a genuinely new product it is a judgment call, and the contribution of a system is not a point estimate but a range and a decision rule: buy small, and know now what you will do at week four in the high branch and in the low branch. Most of the money in launches is made by re-buying fast, not by predicting well.
Measuring it so the number means something
Never report aggregate monthly accuracy. Aggregation cancels errors. Over-forecast one colour and under-forecast another and the total looks excellent while every buying decision underneath it was wrong. A catalog can be six percent off at the month level and useless at the SKU level, and the six percent is the number that ends up on the slide.
Measure at the grain of the decision. That means SKU by lead-time window, which is the quantity the purchase order is actually built on.
Use weighted error, not percentage error. Percentage error explodes on small denominators and is undefined in a zero-demand week, which is most weeks for most of your catalog. Weight by units or, better, by margin dollars, so the metric cares about the same things the business cares about.
Score against a baseline the room believes. Same period last year, an eight-week moving average, and the buyer's own number. Then measure whether the model beats the buyer, and whether the buyer working from the model beats both. A common and useful result is that the buyer wins on the top forty SKUs and loses badly on the tail. That is not a failure of the project, it is the assignment for the next quarter.
Alongside accuracy, track what the business feels: in-stock rate weighted by margin, the distribution of weeks of cover, sell-through at eight and sixteen weeks, and dollars of inventory older than a hundred and eighty days. Accuracy is a proxy. Those four are the outcome.
Keep the overrides, and score them
Buyers override the number. They know a wholesale order is landing, that a creator collaboration ships in March, that the supplier's plant is closing for two weeks. Deleting the override is the wrong instinct, because most of that knowledge is real and none of it is in your data.
Log every override with a reason code, the number before, the number after, and who made it. Score them monthly against what actually happened. The consistent pattern is that a minority of overrides add value, a majority subtract it, and the subtracting ones cluster in one or two people or one category. That turns an argument about whether to trust the model into a specific conversation about eleven SKUs.
Put the recommendation where the purchase order is cut
The most common quiet failure is a forecast that lives in a tool the buyer does not open on the day the order goes out. If the buying happens in a spreadsheet on Thursday afternoon, the output belongs in that spreadsheet on Thursday morning, with the order quantity already rounded to case pack and the constraint that bound it named in a column. A better model delivered somewhere else loses to a worse one delivered in the right place, every time.
Send us twelve months of orders and we will tell you where the error is.
Order lines with dates, a SKU list with case pack and supplier, and whatever availability history exists, to contact@precisionfederal.com. You get back a short written note naming the three things we would change first and roughly what each is worth. One business day. No charge and no meeting.
contact@precisionfederal.comWhat we find in the first week
- No daily availability snapshot, so stockout periods cannot be reconstructed and every model is trained on censored demand
- One service level for the whole catalog, usually 95, usually never revisited
- Accuracy reported monthly and in aggregate, the one grain where it looks good
- Safety stock from demand variance alone, with lead time entered as a single number per supplier
- Returns netted at the original order date, so a sale and its reversal appear months apart and the series looks lumpier than the demand was
- Kits and bundles consuming component stock that the component forecast never sees
- Marketplace and direct channels forecast separately while drawing from one pool of inventory
A six-week build that usually settles it
Replenishment build order
Weeks five and six are the ones teams cut for schedule and the ones that decide whether anybody uses it. A recommendation that has not been reconciled against a real purchase order is a research result.
When you do not need software for this
Under roughly a hundred and fifty SKUs, one domestic supplier, four-week lead times, ordering weekly: a spreadsheet with an eight-week moving average, a lead-time buffer and a reorder point column gets most of the available value. The honest recommendation there is to fix the data hygiene, write down the service level assumptions, and keep the spreadsheet. Building a system would be a worse version of what you have with a login screen in front of it.
The case for building shows up when SKU count runs into the high hundreds, lead times pass about sixty days, inventory splits across channels or warehouses, or the whole buying process depends on one person's judgement and that person is a single point of failure. Those four are what actually change the arithmetic.
And one more honest case for not building. If containers arrive three weeks late half the time, forecasting is not your constraint. Cutting the variance of your own supply chain will beat every modelling improvement available to you, and it is a supplier conversation rather than a software project.
Before the first purchase order goes out on it
- Daily availability history is being written and is at least one full season deep
- Lead time mean and variance computed per supplier from received dates, not from a contract
- Stockout days excluded or imputed everywhere the model trains
- Catalog classified, with a documented method per class
- Service levels derived per archetype from margin and markdown, and written down
- Fill rate and cycle service level distinguished explicitly in every report
- Order quantities respect case pack, minimum order, container and open to buy
- Scored against seasonal naive and against the buyer, at SKU by lead-time window
- Overrides captured with reason codes and reviewed monthly
- The recommendation appears in the place and on the day the order is actually cut
Bottom line
Inventory forecasting for an online catalog is mostly not a forecasting problem. The horizon comes from lead time, the history has to be repaired before anything is trained on it, the tail needs different methods from the head, the service level is a margin calculation, and the output has to survive contact with case packs and a credit line. Get those five right with a plain moving average underneath and you will beat a sophisticated model sitting on censored data with one catalog-wide service level. Then, if you want, improve the model. That part is real, it is just last.
Frequently asked questions
For seasonal products, two full cycles, so about two years; with one year you cannot separate a season from a trend. For non-seasonal items, six to nine months of clean daily data is workable. Availability history matters more than length: eighteen months of sales with no record of when items were unavailable is weaker than nine months with it.
At SKU by week on a long-tail catalog, weighted error in the thirty to sixty percent range is normal and not a sign of a bad model. It improves substantially when you aggregate to the lead-time window, which is the grain you actually buy on. Be suspicious of anyone quoting under twenty percent at SKU by week; it usually means the metric was computed on the head of the catalog or after aggregation.
Often yes. Off-the-shelf planning tools handle reorder points, multi-location and purchase order workflow competently. They tend to be weak on censored demand repair, per-archetype service levels and container-level order building, so the practical answer is frequently to buy the workflow and build the small piece that computes the recommendation feeding it.
With analogs from attributes, and with a plan rather than a number. Pick three to five comparable past launches by category, price band and launch channel, use their early sell-through curves as a prior, buy conservatively, and set in advance what you will do at week four in the high and low cases. The value is in re-buying quickly, not in the first estimate.
Not necessarily, and you cannot tell until the overrides are scored. Log each one with its reason and compare outcomes for three months. Overrides that add value are knowledge the model lacks and should become features; overrides that subtract value are usually concentrated in a few people or one category and are a training conversation, not a software change.