Product
A bigger order won't save a SKU that runs out in six days
When the cover you have left is shorter than the lead time you'd order against, quantity is the wrong lever — the shortfall is denominated in days, and days aren't bought with units.
A shortfall in days is not a shortfall in units
Two rows can sit side by side in the same low-stock view and be entirely different problems.
The first crossed its reorder point with enough cover left to survive the supplier's lead time. Stock is thin, an order is due, and the only open question is how many. Quantity is the whole decision, and getting it right is a matter of velocity, cover period, and what's already inbound.
The second one runs to zero before any order placed today can land. That shortfall is arithmetic, and it is indifferent to order size. Tripling the quantity changes how deep the shelf is after the truck arrives; it does nothing to the days between now and the truck. The item is out either way, for exactly the same stretch, whether you buy eighty units or eight hundred.
| Low stock | Runs out before a reorder can land | |
|---|---|---|
| What's true | Cover outlasts the lead time | Cover is shorter than the lead time |
| What the quantity lever fixes | Everything — it's the only open question | Only the depth after arrival, never the gap |
| The open decision | How many | How fast, or whether to absorb the gap |
| Unit of the problem | Units | Days |
| Where it shows up | The suggested quantity on the row | A finding line naming the stall |
Read the stall, not the suggested quantity
The measurement is a subtraction, not a threshold.
stall (days) = supplier lead time − days of cover remaining
A product with about four days of cover left and a three-week lead time is short roughly seventeen days. A suggested order of 80 units and a suggested order of 800 produce the exact same seventeen days. (Illustrative numbers.)
When that number comes out positive, you are holding two decisions, not one: a stall window to manage, and a quantity to set for whenever the stock does land. Conflating them is how a stall gets “solved” by ordering more.
Two things have to be true before the gap is worth acting on. Incoming stock must already be netted off — units on the water that nobody subtracted make a healthy row look desperate. And the lead time in the subtraction has to be the supplier's real one, not an inherited default. In Assisty the supplier record carries Lead Time alongside Reorder Cycle, Min Stock Cover Days, and order minimums and maximums, and the buying table's suggestions use them automatically, with per-variant overrides for supplier SKU, cost, MOQ, and case quantity. The suggestion's own breakdown shows the subtraction — a cover period grossed up from daily velocity, minus incoming quantity from open POs, minus what's on hand.
This is a row class, not a one-off. The Smart Buying Table surfaces it as its own named finding with the count of affected items — “3 items run out before a reorder can land” — ranked with the other findings by money at stake, each carrying its one-tap fix. A single row states it plainly: “Tea Sampler stalls for 6 days before restock,” with an Expedite action beside it. The finding also carries a bulk action across the affected rows — the chip reads “Expedite all 3.” Work that class as its own pass, before anyone touches a quantity.
The levers that actually shorten a stall
There are four standard responses, and every one of them costs something — cash, margin, or the sale itself. None of them is a default.
| Lever | What it changes | What it costs | When it's the right call |
|---|---|---|---|
| Expedite the whole order | Compresses transit for every unit on the order | The premium applied to the full quantity — air freight is typically 4–8× faster than ocean on the same lane and roughly 8–16× more expensive per kilogram | The item has no substitute and the whole quantity is urgent |
| Rush a partial, balance on the normal route | Brings forward only the portion that covers the gap; the remainder arrives on the original schedule | The premium on a slice, plus the coordination of two arrival dates for one order | The stall is short and a fraction of the order closes it |
| Substitute an in-stock item | Moves demand rather than supply — nothing ships faster | Margin or basket value on the substituted sale, and the risk the customer doesn't accept the swap | Close in-catalogue alternatives exist |
| Accept the gap | Nothing — you plan recovery instead | The lost sales across the exposure window | The item is highly substitutable, or the freight premium exceeds the cost of being late |
The pricing is what pushes you toward the slice. Rush freight is charged per kilogram, so it is near-always worse per unit than the slow mode — which is why the common pattern reserves it for urgent replenishment, launch stock, and delayed SKUs while core replenishment keeps moving cheaply. Pay for speed when the business cost of being late exceeds the premium. That's a per-SKU judgment, and it turns heavily on substitutability: the same seventeen days of exposure is serious for an item with no alternative and close to harmless for one with three.
Before you pay for speed, check that the stall is real
A stall is a computed number, and three ordinary inputs can make it fictional. Check all three before buying a single day of freight.
Velocity measured across a stockout understates real demand. Assisty lets you exclude the days you were out of stock from the history, so the forecast reflects real demand rather than the days you couldn't sell.
Incoming stock nobody netted off closes gaps on its own — suggestions subtract open-PO quantities; an eyeball on the shelf doesn't.
A placeholder lead time inflates every stall it touches.
Paying for air freight against a bad denominator is the expensive version of this mistake — real days bought to close a gap that was never there. If reality differs from the data, tell Atlas and the whole table recomputes, with a was→now chip and per-row undo; nothing is committed until you create the order.
The rush and the regular order are two decisions
The last failure mode is contamination. Urgency found on three rows leaks outward, and the whole cycle gets bought in that mood — larger quantities, everything ordered early, safety buffers raised across the board. A six-day problem becomes a quarter of overstock.
Keep them apart procedurally. Work the at-risk rows first, as their own pass, with their own answer — the findings sit at the top of the table with the action attached. Then let ordinary rows keep ordinary quantities: select what you're ready to buy and either create purchase orders on the spot, or stage items on the Purchase List — priced with each supplier's tax and currency — and order once you've finished reviewing. When you commit, the selection splits by supplier into one PO each, with exact item counts and order values, and asks which location receives the stock. Each of those orders continues past the draft: review line items, email it to the supplier, receive against it when stock arrives.
The forecast feeds the same loop from the other end — it flags which items run out before the period ends and hands those at-risk items straight into the Smart Buying Table. Which is the shape of the whole practice: find the rows whose problem is time, answer them in the currency of time, and let the rest of the table be about quantity.