Every formula Stockmind™ uses, in plain terms — including the places where the model is an approximation rather than a truth.
Replenishment tools tend to present their output as fact. In reality every suggestion rests on a chain of assumptions, and a buyer who can't see those assumptions can't tell a reliable number from a fragile one. This page sets out the whole chain.
ShelfDays™ — the days a product was actually in stock during the measurement window. Used as the divisor for velocity in place of calendar days.
Phantom Slow Mover — a product whose recorded sales understate real demand because it was unavailable for part of the window. Conventional velocity treats these as weak sellers and under-orders them, which keeps them empty.
Censored demand — the statistical name for this problem. When a product is out of stock you don't observe zero demand; you observe nothing at all, and the two are not the same. Sales data from a stockout period is censored: it records a lower bound on demand, not demand itself. The literature on this is decades old. What's unusual is how few replenishment systems act on it.
Velocity is the engine — everything downstream inherits its accuracy. The conventional definition divides units sold by days elapsed:
This assumes the product was available to sell on every one of those days. When it wasn't, velocity is understated — and the products that sell out fastest are punished hardest. Stockmind divides by the days the product was actually in stock:
Stockmind samples historical stock balances from your warehouse at intervals across the period, and counts how many of those snapshots showed stock on hand:
A product absent from a snapshot had no stock then — which also means a product launched mid-period is naturally measured from launch, with no special case needed.
A floor of 14 ShelfDays applies. A product available for only two days can't imply an enormous rate from a tiny sample, so confidence scales with volume rather than with luck.
Where measurement isn't available, Stockmind falls back to inferring the window from the product's age and its most recent sale — better than a flat calendar divisor, but blind to stockouts that have since been refilled.
Reports that work at device level — which generations are rising, which are finished, which ranges are worth extending — need to know which device a product fits. That comes from the compatibility class recorded in the warehouse system rather than being inferred from the product code, so it is your own catalogue data rather than a guess.
Two cases are handled explicitly:
Where a product carries no class at all, it falls back to its product code rather than being dropped, and the number of products affected is reported.
Verdicts such as worth expanding or over-extended are set by quartiles of your own catalogue, not fixed thresholds — the top quarter for demand per SKU is the top quarter whatever the catalogue looks like, so the judgement does not drift as it changes.
Demand is measured net of returns. A returned unit re-enters stock, so counting it as demand does two things wrong at once: it overstates how fast the product sells, and it double-counts a unit that is already in the on-hand figure.
Returns are read from the order line the unit left on, so nothing separate is fetched and the figure is available for every product that has sold. A return rate — units returned as a share of units shipped — is reported per product, and a high one is worth investigating rather than simply absorbing: the cause is usually a photograph, a size, or a compatibility claim rather than the product itself.
Deducting returns is a setting rather than a silent behaviour, because it changes every velocity, reorder point and suggested quantity in the system.
A device is reported as generation over only when nothing on it has sold in 365 days — the same window the dead stock analysis uses. A device with sales this year but none in the last quarter is fading, which is a different situation and deserves a different word.
The distinction matters because the two windows are easy to conflate. Judging "generation over" on ninety-day sales while judging "dead" on a year would report a device as finished when a product on it sold four months ago. Both figures are shown side by side so the verdict can be checked rather than taken on trust.
A reasonable question at this point is why not simply use an established intermittent-demand forecaster — Croston's method, or a Poisson model. Both are well-founded and both are widely used. The issue isn't that they're wrong; it's that they assume something this data doesn't satisfy.
A Poisson model estimates an arrival rate λ from observed sales. If the product spent forty days unavailable, those forty days contribute zeros to the estimate — and the fitted λ comes out too low. The model isn't malfunctioning; it's being fed censored observations and has no way to know it.
Croston's method fails more interestingly. It works by separating demand into two series — how large each demand event is, and how long the gaps between events are — then smoothing each. That decomposition is exactly what makes it good at genuinely sporadic demand. But it cannot tell a stockout from a quiet period. Forty days with no stock look identical to forty days with no customers, so the gaps get longer, the estimated inter-arrival interval inflates, and the forecast falls. A product that sold out because it was popular is reclassified as intermittent because it was popular.
This is why availability is measured before any forecasting decision, not as an adjustment afterwards. Correcting censored data is upstream of choosing a method — and once corrected, Croston's or a Poisson model would work better on it too.
Every method above estimates parameters from a product's own past. A product launched three weeks ago hasn't got one. Croston's needs demand events to smooth; a Poisson model needs observations to fit λ. With a few weeks of data both produce an answer, but not one worth acting on.
Stockmind's answer to a new product is deliberately modest, and worth stating plainly: it measures from launch rather than from an arbitrary window start, so a short history isn't mistaken for weak demand. Beyond that it does not pretend to forecast a product that has never sold. What it offers instead is context from products that have: how the same variant mix has historically split across colours, and how the equivalent range performed for the previous device generation. That's a starting point for a buying decision, not a forecast, and describing it as one would be dishonest.
A flat average over the full period treats a rising product and a falling one identically. Stockmind can compare the recent rate against the full window and blend them:
The recent window is availability-adjusted in its own right, so a product that spent last month out of stock isn't mistaken for one whose demand collapsed.
The weight w is not fixed. It rises with recent volume, so a well-evidenced shift moves the number and a single sale barely does:
| Recent units | Share of maximum weight | Effect |
|---|---|---|
| 1 | 25% | Barely moves — one sale is noise |
| 3 | 50% | Modest influence |
| 18 | 86% | Strong influence — a real signal |
The trigger is the stock level below which an order must be placed to avoid running dry before it arrives:
Both lead time and review period can be set per supplier, with global defaults for anything not overridden — an overseas supplier ordered quarterly and a local one restocked weekly aren't held to the same schedule.
Available stock is compared against it — counting stock already on order, but only what arrives in time to matter:
A shipment landing after that horizon is tracked and displayed, but it can't mask a stockout that happens before it lands.
Most tools size an order to cover the lead time. That's not enough: the order has to last until the next order arrives. Stockmind uses the standard periodic-review target:
The review period is how often you actually place orders. Order weekly and quantities stay lean; order monthly and they scale accordingly, because they have to survive a longer gap.
By default safety stock is a flat number of days applied to every product. Optionally, it scales to how erratic each SKU's demand actually is, measured as the coefficient of variation across three equal sub-periods:
Variability is measured from sales rates, not raw quantities. A product that sold nothing in one period because it was out of stock isn't erratic — it had nothing to sell. Periods with no availability are excluded rather than counted as a collapse in demand.
| Demand pattern | CV | Buffer |
|---|---|---|
| Steady — 10, 10, 10 units, always in stock | 0.00 | 0.5× base |
| Mild swing — 12, 10, 8 units | 0.16 | 0.7× base |
| Steady but out of stock one period — 10, 0, 10 | 0.00 | 0.5× base — the empty period is excluded |
| Genuinely spiky — 30, 1, 2 units, always in stock | 1.22 | 1.7× base |
This tends to redistribute protection rather than simply add it: predictable products need less cushion, volatile ones more. Products with too few sales to judge keep the flat buffer.
Dead stock uses a deliberately different window — a full year, not the 90 days that drive reordering. A seasonal product would look dead on a short window and get cleared right before its peak.
Results split by whether stock is physically present: items in the warehouse need handling, while zero-stock listings are pure catalogue cleanup.
Stockmind can write a plain-language summary of the week using a language model. It is worth being precise about what that layer does, because it would be easy to assume it influences the numbers.
It does not. No reorder point, quantity, velocity or forecast is produced by a language model. Every figure on this page is arithmetic, and the same inputs always produce the same output.
The summary receives figures that have already been calculated, and is instructed not to compute, estimate or infer anything. Every number it writes is then checked back against the source data before display; anything unverifiable is flagged rather than shown as fact. The feature is optional and can be switched off without affecting any calculation.
No forecast is neutral, and every one of these choices trades something. Here's what to keep in mind when reading a suggestion.
Availability is sampled at intervals, not continuously, so a stockout shorter than the gap between snapshots can be missed. Daily sampling is the default, resolving availability to roughly half a day. Coarser intervals run faster — weekly leaves about ±4 days — but the error lands in the denominator, so it hurts most on the thin-stock products this correction exists to serve.
A product available two days that sold one unit would imply forty-five a quarter. A floor on the denominator prevents that, and the floor is a judgement rather than a derivation — so its effect is measurable rather than asserted. Stockmind can recompute the whole catalogue at several floors and report how many products change decision.
On one catalogue of 226,000 SKUs the floor affected 1% of selling products and changed three reorder decisions. That is the reassuring answer: the constant barely matters. It also means any "largest correction" figure is bounded by that floor rather than observed, which is worth knowing before quoting one.
The exception is a new range: a product added last week has only days of availability however well it sells, so the guard does real work for a period after a launch.
Returns are deducted — velocity is measured on net demand, because a returned unit goes back on the shelf and was never demand in the first place. The residual approximation is timing: a return can arrive weeks after the sale it cancels, so the most recent days of any window understate the eventual return rate. The effect is small on a 90-day window and largest on a product that has only just started selling.
An item can hold enough cover to avoid being flagged today, yet run dry before your next scheduled order. Widening the trigger would catch these at the cost of flagging considerably more items.
Every figure is a statistical estimate from historical data. Supplier behaviour, market shifts, promotions and pricing changes are all outside the model. The output is there to inform your judgement, not replace it.
If any of this matters to how you'd use the system — or you think a different assumption would suit your catalogue better — that's exactly the sort of thing worth raising before you commit.
We're happy to walk through how any of this would apply to your catalogue.
Get in touch →