A daily store request nobody has to assemble by hand
A forecast answers how much will sell. Replenishment answers what must arrive at a specific location and when — with its lead time, safety stock and delivery days.
What is wrong today
- The request is assembled in the evening from memory rather than from stock and sales velocity.
- Delivery days are ignored: the order goes out on a day when no van serves that location.
- The store over-orders “just in case”, and the surplus settles across the network.
How it works
By morning the location has a list: what to bring, how much, and why exactly that much. The manager reviews and adjusts the exceptions.
If the next van comes in three days, the need is computed to that day, not to tomorrow.
Goods in transit are subtracted from the need — otherwise the location orders the same thing twice.
What it looks like in use
The order, ready by morning. Every quantity can be challenged — the reason for it is written alongside.
| Item | Location | Need | Pack | Order | Why |
|---|---|---|---|---|---|
| Drinking water 0.5 l | Location B | 255 | ×12 | 264 | stockout in 2 days |
| Toothpaste 100 ml | Location D | 85 | ×6 | 90 | routine top-up |
| Shampoo 400 ml | Location A | 40 | ×6 | 42 | routine top-up |
| Wet wipes, 60 pcs | Location C | 0 | ×24 | 0 | 80 days already on hand |
An anonymised example: locations are lettered and the dataset is shared across every screen on this site.
Who stays in control
The request is confirmed by a person at the location. Edits are stored with their author and show where the calculation systematically diverges from the shelf.
How it is measured
By the share of lines that went through without a manual edit, and the number of locations that hit zero on fast movers.
Show us one critical process. We will show how it runs here.
We look at your cycle: how an order is assembled today, who decides, where time leaks and what the system takes over.