The Problem
Under a manual forecasting process, a stockout rarely announces itself in advance. Somebody notices when a customer asks why their order has not shipped, or when a reorder is placed too late to close the demand gap. By then the sale is already at risk and in a wholesale relationship so is the account. A static minimum inventory level does not help, because it does not monitor variable demand or how reliable that supplier’s lead time has been lately. A threshold that was prudent six months ago is dangerously low today if demand has picked up and wasteful if demand has decelerated. The recalibration exercise is the tell. Any business running min/max at scale eventually finds itself reviewing thresholds across every location by spreadsheet, because the thresholds have drifted from reality and nobody has time to keep them honest. The work is real, repetitive and produces a number that is stale again within weeks. Does this sound familiar? How much time does your team spend manually calculating forecasts or amending min/max levels by CSV?
How It Works
Reorder point: the precise order trigger
The reorder point combines three inputs:
1. the trend-adjusted daily demand forecast
2. the lead time configured on the product record
3. statistical safety stock.
The calculation is (trend-adjusted daily demand forecast + lead time in days) + safety stock).
When available stock falls below that number, today is the day to place the order for stock to arrive before a stockout, not after. This number is calculated daily and held against every SKU for 365 days.
When you ask the question – “what items will stock out in 30 days at the central warehouse?” Stok.ly is not calculating on the fly, it is querying this pre-calculated value and providing that number for you in seconds.
Safety stock: derived from variability, not estimated
Safety stock is calculated as the 90-day demand standard deviation, multiplied by the square root of lead time in days, multiplied by 1.645. It recalculates daily.
A product becomes spiky; perhaps a B2B customer has started placing large irregular orders. This item earns a larger buffer automatically, with nobody editing a field. A product that settles down earns a smaller one, releasing capital that was sitting as unnecessary insurance.
On the 1.645, and why it is stated openly
That figure is the z-score for a 95th percentile service level: the standard for a business that intends to be in stock on nineteen of every twenty demand days. It is a commercial choice and it is published here because a buyer should be able to interrogate it rather than accept a buffer they cannot explain.
A business that needs a higher service level on a critical range should be able to have that conversation with a number in front of it.
Days of cover: the buying horizon in days
Available stock divided by trend-adjusted daily demand. Sorted ascending, it produces an ordered list of what runs out first. It is the most intuitive of the four signals for anyone who has to explain a purchasing decision to somebody else, because it answers the question in the unit people actually think in.
Stockout risk: one score to sort your product catalogue by
A composite score between 0 and 1 combining current availability, forecast demand and demand variability. Sorted descending it gives the buying team the day’s purchasing priority list in a single action. The design intent: which items do I need to order today, sort by which are closest to their reorder point, job done.
The distinction that makes the rest of it trustworthy
The data lake separately records, for each rolling window, how many days a product had zero available stock. This is what allows the system to tell the difference between two situations that look identical on a sales report:
1. I sold none because nobody wanted it
2. I sold none because I had none to sell.
The first is a slow mover to be cleared. The second is a product to buy more of. Treating them the same way is how businesses simultaneously overstock what does not sell and understock what does.
What happens when lead time is missing
If lead time is not configured on the product record, safety stock returns null and the AI flags the product for setup rather than substituting an assumption. This is deliberate. A silently assumed lead time produces a confident-looking reorder point that is wrong, and a wrong number a buyer trusts is worse than a gap a buyer can see.
Trust your stock. Transfer with confidence. Control orders. Fulfill every day like clockwork.
G2 Customer Reviews
What do you like best about Stok.ly – Inventory-Centric Cloud ERP?
“we have been a user for the last 4 years and we cannot think of life without it for our retail business. it makes listing to shopify and other marketplaces easy, keeps inventory accurate online and the POS is easy to use. accurate inventory across all sales channels is the big win for us.”
Order management and inventory ERP software for growing retail, wholesale and distribution businesses.
The Numbers, and How They Are Calculated
| Signal | What it tells you | How it is calculated | How the buying team uses it |
|---|---|---|---|
| Reorder point | The exact threshold at which to place a purchase order today | (Trend-adjusted forecast daily demand × lead time in days) + safety stock | When available stock falls below this number, order now |
| Safety stock | The buffer needed to absorb demand variability at a 95% service level | 90-day demand standard deviation × √(lead time in days) × 1.645 | Set once and left alone; it recalculates daily as variability changes |
| Days of cover | How long available stock will last at the current demand rate | Available stock ÷ trend-adjusted daily demand | Sort ascending to see imminent stockouts |
| Stockout risk | A single urgency score from 0 to 1 | Composite of current availability, forecast demand and demand variability | Sort descending for today’s purchasing priority list |
| Zero-stock days | How many days in the window the product had nothing to sell | Count of days with zero available stock across 30, 60 and 90 day windows | Distinguishes unmet demand from genuine slow movement |
| Non-zero demand days | How many days it actually sold | Count of days with demand above zero in the trailing 90 days | Identifies intermittent sellers that need different treatment |
What Actually Changes
| Min/max replenishment | Stok.ly statistical replenishment | |
|---|---|---|
| Where the threshold comes from | A person, once | Actual demand variability, daily |
| Response to a demand spike | None, until someone notices | Safety stock increases automatically |
| Response to a slowdown | Keeps ordering at the old rate | Safety stock reduces, releasing capital |
| Treatment of stockout days | Counted as low demand | Excluded from sell-through |
| Service level | Implicit and unknown | Explicit: 95% |
| Lead time handling | Usually baked into the minimum | A separate configured input |
| Missing lead time | Silently absorbed into the threshold | Returns null and flags the product for setup |
| Maintenance overhead | Periodic manual recalibration | None |
Questions the AI Answers From Pre-Calculated Data
- Which items do I need to order today, sorted by stockout risk?
- Which products will run out first, sorted by days of cover?
- What is the reorder point for this SKU at this location, and how was it calculated?
- Which SKUs have manually set minimums significantly above or below their statistically correct safety stock?
- Which products had zero stock for more than 20 of the last 90 days?
- Which products are missing a configured lead time and therefore have no safety stock calculated?
How This Compares to Cin7, Brightpearl, Orderwise and Linnworks
Positions below reflect vendor-documented capability as at 27 July 2026.
- Cin7. ForesightAI calculates reorder points and recommends safety stock using ABC segmentation. It does not document a defined statistical service level, a published safety stock formula, or exclusion of stockout days from sell-through, and it is a paid add-on priced on gross merchandise value rather than a standard capability.
- Brightpearl. Replenishment recommendations come via Inventory Planner, a connected Sage for Retail product, which does account for stockouts in its forecasting. Sage Copilot surfaces priority replenishments as an insight panel, but it is a Premium-only beta, several insights require ABC analysis to be enabled, and the flow depends on synchronisation between two products.
- Orderwise. Min/max levels and lead times feed automated purchase planning. Thresholds remain user-maintained rather than statistically derived, and no service level is published.
- Linnworks. No statistically derived safety stock or reorder point capability of this kind.
How to Test This in a Demo, Including Ours
Use the same anonymised data set and the same questions with every vendor, and insist on a live workflow rather than slides.
- Show the ten SKUs most likely to stock out in the next 30 days by location, and explain why each is at risk with the underlying transactions and the data timestamp.
- Show the safety stock for a named SKU and the formula that produced it, including the service level assumed.
- Confirm whether stockout days are excluded from the sell-through rate and demonstrate it on a product that sold out.
- Ask what happens to safety stock when lead time is not configured, and confirm whether the system guesses or flags it.
- Change a lead time and show exactly how the reorder point and the recommended action change.
- Ask the system to compare its calculated safety stock against the manually set minimum for the same SKU, and show which products are over- and under-buffered.
- Recommend a purchase order that respects lead time, minimum order quantity, case size, price breaks and a cash limit.
- Introduce stale stock and missing cost prices, then see whether the AI warns you or answers confidently from poor data.
Score on time taken, number of clicks, whether the answer is traceable to source records, and whether the insight becomes an editable draft without rekeying.
Frequently Asked Questions
Does Stok.ly calculate safety stock automatically?
Yes. Safety stock is recalculated daily for every SKU at every location from the 90-day demand standard deviation multiplied by the square root of lead time in days multiplied by 1.645, the z-score for a 95% service level. A product that becomes spiky receives a larger buffer automatically; a product that stabilises receives less, freeing capital.
How does Stok.ly decide when to reorder?
Through a reorder point combining trend-adjusted forecast demand, configured lead time and statistical safety stock: (trend-adjusted forecast daily demand × lead time in days) + safety stock. When available stock drops below that figure, today is the day to order.
What service level does Stok.ly assume, and can it be changed?
The published calculation uses a 95% service level, the standard for being in stock on nineteen of every twenty demand days. The z-score of 1.645 is stated openly so a buyer can interrogate the assumption rather than inherit an unexplained buffer. A business needing a different service level on a specific range should raise it directly, with the current number in front of it.
What is the stockout risk score and how do I use it?
A composite score between 0 and 1 combining current availability, forecast demand and demand variability, recalculated daily per SKU per location. Sorting descending produces the day’s purchasing priority list in one action.
What is the difference between days of cover and stockout risk?
Days of cover expresses urgency in days, which is intuitive and easy to explain. Stockout risk expresses it as a composite score that also accounts for how erratic demand is, so a product with volatile demand can rank higher than a product with slightly fewer days of cover but very stable demand.
How does Stok.ly tell the difference between a slow mover and a product that was simply out of stock?
The data lake records how many days in each rolling window the product had zero available stock, separately from demand itself. A product with high zero-stock days and low recorded demand is a product you had nothing to sell, not a product nobody wanted. Those two situations require opposite purchasing responses.
What happens if lead time is not configured for a product?
Safety stock returns null and the AI flags the product for setup rather than substituting a guess. A silently assumed lead time produces a confident-looking reorder point that is wrong, which is worse than no number at all.
Can the AI create the purchase orders once it has identified what to order?
Yes. It can produce the ranked list and then create the purchase orders directly, showing the full workings first. Nothing is committed until you approve it.
Can the buying team get these numbers outside the AI assistant?
Yes. All four signals are available conversationally and via API, including for Power BI, so a morning dashboard and a conversation return identical figures because both read the same pre-computed fields.
Contact Information
All our sales, support and development team are located in Hereford and Cheltenham in the U.K. Please submit the contact form and we will contact you within the same business day.