Read enough Shopify community threads and the same frustration surfaces in a different costume every week. Merchants want the store to reorder for them. They have watched a bestseller sell out three times this quarter, they know roughly how fast it moves, they know which supplier makes it, and they cannot understand why the platform that tracks every unit will not just tell them to buy more before it runs out. The answer they get is always some version of the same thing. Shopify counts your stock. It does not plan your stock. There is a purchase order screen, and merchants who find it usually come away calling it, in the exact words of one well-read forum thread, too basic.
That gap is easy to shrug off because it has no dramatic moment. A stockout on a hot product feels like an event. A reorder placed two weeks late feels like nothing at all, just a quiet stretch where the page said sold out and the customers went elsewhere. Nobody opens a support ticket about a purchase order that should have gone out on Tuesday. So the single most expensive operations decision in the store, how much of what to buy and when, gets made in the cracks of a busy week, on a spreadsheet that is always a little out of date.
Shopify will count every unit you own. It will never tell you which one to buy back.
How big the leak actually is
Running out of stock is not a rare accident, it is a constant background cost. Stockouts cost retailers on the order of one and a quarter trillion dollars a year in lost sales worldwide. At any given moment roughly eight percent of all SKUs are out of stock, about half of all products hit at least one stockout in a year, and the average stockout lasts around thirty five days from the first empty shelf to the day stock is back. That is more than a month per incident of a product page that converts a ready buyer into a shrug.
And the buyer does not wait. When a shopper finds an item unavailable, about forty three percent go straight to a competitor, and many of them do not come back. So a late reorder is not a delayed sale, it is usually a lost one, plus a small chip off the trust that brings people back. The reorder decision is where most of this is won or lost, because every one of those thirty five day gaps traces back to a purchase order that went out too late, or for too few units, or never went out at all.
What Shopify actually does, and where it stops
Shopify is good at the half of this it owns and silent on the half that matters most. It tracks inventory per location, it knows the running count of every variant, and it gives you a purchase order screen where you can record what you are buying from a supplier and receive it against stock. What it does not do is decide. There is no native engine that reads your sales and your stock, works out what is about to run out, and drafts the order. The gap shows up in three concrete ways merchants run into fast.
First, there is no reorder point that thinks per SKU. Shopify has no native field that says reorder this variant when it drops to this level, let alone one that sets that level from how fast the item sells and how long its supplier takes. The closest thing is eyeballing a low-stock report. So the trigger to buy lives in a human's memory, and it fires whenever someone happens to scroll past the right row.
Second, the purchase order itself is bare. Merchants in the forums hit the same walls again and again: the PO does not auto-populate the product cost you already entered, so you retype prices you have on file; there is no native field to store the supplier's own SKU, so you cross-reference part numbers by hand; and there is no real reporting on what is on the way, what arrived partially, and what is still pending. The screen records a decision. It does not help you make one.
Third, nothing connects the count to the calendar. The number that matters for reordering is not how many you have, it is how many days you have left at the current pace, minus how many days the supplier needs to deliver. Shopify shows you the first number and knows nothing about the second. So even a diligent merchant is forced to do lead-time math in their head, per product, for a catalog that may run to hundreds of SKUs across more than one supplier.
Why the usual fixes don't hold
Once a merchant feels the leak, they reach for one of three coping strategies. Each buys a little control and each breaks in a predictable spot.
"I track reorders in a spreadsheet." This is the honest default, and it works until the catalog grows or the week gets busy. The sheet is a snapshot the moment you build it and stale by the afternoon, it does not watch sales as they happen, and it cannot tell you that a slow mover just started trending until you go looking. The products that need the sharpest attention, the fast and the seasonal, are exactly the ones a static sheet gets wrong, because their pace is the thing that changed.
"I set one reorder point for everything." Pick a tidy rule like reorder anything that drops below ten units and you have bought too late for the bestseller with a six week lead time and far too early for the slow mover sitting on three months of cover. A flat threshold treats a product that sells forty a week and one that sells two the same way. The whole problem is that every SKU moves at its own speed and every supplier delivers on its own clock, which is the one thing a single number cannot capture.
A Shopify Flow low-stock alert. Flow can watch inventory and ping you when a variant crosses a level, which feels like progress. But an alert is not a plan. It still lands on a human who has to decide whether the dip is real demand or a blip, how many to buy given the lead time and the trend, whether to wait and bundle it with other items from the same supplier to clear a minimum, and then actually build and send the PO. The notification moves the work to your inbox. It does not do the work.
What the automation actually has to do
The real job is not "alert me when stock is low." It is "watch how each product is actually selling, know how long each supplier takes, and put a right-sized purchase order in front of me before anything runs out, grouped so it is worth sending." That means forecasting, lead-time math, and a little judgement about cash and minimums. As a Dugong playbook, in plain prose, it reads like this:
# trigger
Every morning, and whenever a product's sales pace
shifts sharply
# steps
1. Project days of cover left for each SKU from its
recent sales pace, trend, and any seasonality
2. Subtract that supplier's real lead time to find
the date each item must be reordered by
3. Size the order to cover demand through the next
cycle, not a flat number, and not so much that cash sits idle
4. Group the items by supplier so each PO clears the
order minimum instead of shipping in dribs
5. Draft the purchase order with the right cost,
supplier SKU, and quantities filled in
6. Flag anything unusual: a sudden spike, a stockout
already imminent, a price that moved
7. Hand me the drafted POs to approve, and only send
on my okaySeven lines. The compiler fills in everything underneath: pulling the sales history per variant, fitting a demand curve that respects trend and season, storing each supplier's lead time and minimum, doing the days-of-cover-minus-lead-time math for every SKU, batching the buys by vendor, and pre-filling the order with the cost and part number Shopify makes you retype. The merchant never built a rule per product. They described how a careful inventory planner works, and let the compiler do the watching and the arithmetic.
Why this is a compiler problem, not an app problem
There are capable inventory-planning apps in the Shopify ecosystem, and for many stores they earn their fee. But an app ships with its author's idea of how to forecast and reorder, wrapped in a settings page and a monthly bill that often climbs with your SKU count. What most merchants actually want is to encode their rules: this supplier needs six weeks so reorder early, never go below two weeks of cover on the hero product, hold small buys until the vendor minimum is met, treat the pre-order SKUs differently, ignore the one-off bundle that spiked last week, and always let me approve a purchase order over a certain value. Those are sentences about your business, not toggles in someone else's UI.
A natural-language compiler is the unlock because replenishment was never really a button problem. It is a forecasting and timing problem wearing a data-entry problem's clothes. Recording a purchase order is the easy part, which is why Shopify can do it. The hard part is everything before: read the demand, respect each supplier's clock, size the buy against both stockouts and idle cash, group it to clear a minimum, and know which orders are routine and which need your eyes. You can write that brief in a paragraph. You could never maintain it as a rule tree with a branch for every SKU, season, and supplier.
The workflow worth building this week
If you sell physical products that you restock from suppliers, this is the automation to build before the next sale or new launch, because it protects revenue you have already proven you can earn. It sits right next to two pains we have written about already. Reorder timing is the upstream cause of the restock alert that never fires: get the purchase order out on time and far fewer customers ever land on a sold-out page in the first place. And it depends on the same honest counts as the overselling problem no one automates, because a forecast built on a number that is wrong will reorder the wrong amount with confidence.
Describe it the way you would brief a sharp inventory planner on day one: here is how fast each thing sells, here is how long each supplier takes, here is how much cushion I want, here is how to group the buys, and here is the line above which I want to approve before anything sends. That is the whole brief. The compiler does the forecasting, the lead-time math, and the drafting. You keep your attention for the calls that need a human, and you stop discovering your bestseller is gone the same way your customers do.
If you are a Shopify merchant who has built a replenishment flow that
actually keeps the shelves full, or you have a bestseller that went dark
for a month because the reorder slipped and it still stings, the inbox is
open: field-notes@dugong.live. We are collecting case studies
for the next issue.