Replacing a discontinued Shopify inventory app, step by step

Whatever you were using, the part you are missing right now is a loop with four jobs in it. Only four.

• Know what you have. Current stock per SKU, kept current, not counted once a week when someone remembers.
• Know how fast it leaves. A sales rate per SKU over a window you choose, rather than a feeling about your best seller.
• Know how long resupply takes. Lead time per SKU, because a domestic reprint and a sea freight container are not the same problem.
• Tell a person in time to act. A trigger that reaches you before the shelf is empty, not a report you have to remember to open.

Before you shop, write down which other jobs you were leaning on that tool for. Purchase order documents, supplier records, stock transfers, barcode counts and cost tracking are separate problems. Being without them does not cost the same. Supplier paperwork can live in email for a month without hurting you. Alerting cannot. The days you spend deciding about your stack are days where nothing is watching your fastest movers.

So rebuild in that order. Get the alerting back this week, however crudely. Then decide whether you want a planning suite, a spreadsheet you actually maintain, or a small app that does one thing.

The shape of the loop

Sales rate, times lead time, equals the level at which you must place the order. Cross that level, you get told. Once a week, you look at everything that crossed, and you order. That is the whole loop. Everything else in inventory software is an opinion about how to decorate it.

Running out is not a neutral event. While a SKU sits at zero, your ad spend keeps running. Your traffic keeps landing. Your product page keeps ranking. The customer buys the thing somewhere else. The order does not arrive late, it does not arrive at all.

We will not attach a number to that for your store. We do not know your margin, your reorder cycle, or how much of your traffic is paid. Anybody quoting you a precise saving does not know either. The direction is the honest part. Catching a reorder point early costs a phone call to a supplier. Catching it late costs the sale plus the scramble.

The quiet bit is how long a stockout can go unnoticed on a store with a few hundred SKUs. Nobody notices the item that stopped selling. Zero sales on one line looks the same in a report as a bad week, and nothing arrives to announce it. That is the failure mode a low stock alert actually prevents: not ignorance of the number, but never looking at it.

What you lose when you fall back to manual checks

A manual check works while you have the attention to spare. It fails in the exact week you need it, which is the busy one. Peak season, a campaign, a press hit, a supplier delay: those are the weeks when your sales rate moves fastest and your spare attention is gone. An alert is worth having because it does not care how busy you are.

There is no trick to it. Two numbers, one multiplication.

Daily sales rate times lead time in days. If a SKU sells 6 units a day and the supplier takes 21 days door to shelf, your reorder point is 126 units. Hit 126 and the order goes out today, because the 126 you have left is exactly what you will sell while you wait.

That formula has no room for error in it, which is why most operators pad it. Two common ways:

• Pad the lead time. If the last three orders took 21, 24 and 30 days, use 30. Now the arithmetic carries the supplier's worst behaviour instead of its best.
• Pad the level. Add a buffer on top, sized by how badly you want to avoid a stockout on that line. A week of cover on a hero SKU is defensible. On a slow accessory it is dead cash on a shelf.

Both are judgement calls about your own cash and your own supplier. Formal safety stock models exist, and they lean on demand variability, service level targets and standard deviations. If you have the sales history and the appetite, use one. If you do not, padding the lead time gets you most of the protection with none of the maths.

What Restoc does with these numbers

Restoc's reorder point engine takes your sales velocity window, either 7, 14 or 30 days, and the lead time you enter per SKU. It computes the reorder point from those two inputs. It is implemented as a tested pure function, which is a way of saying the number is deterministic: the same inputs always give the same answer.

Being plain about the edges. There is no separate safety stock field and no demand forecasting in the build, and neither is on what we are committing to build. If you want a buffer, you put it in the lead time. If you want forecasting, you want a planning suite, and we would rather point you at one than pretend.

This choice does more to your alerts than anything else you set, and it is the one merchants skip past.

7 days. Reacts fast. A campaign lands, the rate jumps, the reorder point rises with it and you get told early. The cost is noise: one strong Saturday on a slow SKU can double its measured rate and fire an alert you do not need. Good for high-volume staples with steady daily sales.

30 days. Smooths everything. A single freak day barely moves the number, which makes it honest for lumpy sellers and seasonal lines. The cost is lag. If demand genuinely trebles this week, a 30-day average takes a while to notice, and on a long lead time SKU that lag is the whole problem.

14 days. The default worth starting from. Long enough to absorb a weekend, short enough to register a real change within a cycle.

A rule of thumb worth arguing with

Match the window roughly to the volatility, then let lead time decide how much lag you can afford. Short lead time and you can tolerate a slow window, because you can recover. Long lead time and you want to see change early, because you cannot.

How Restoc handles it, stated plainly. The velocity window is a store-wide setting of 7, 14 or 30 days on every plan. A per-SKU override is part of the Pro plan's custom reorder rules, so you can run 14 days as a house default and move a handful of spiky heroes to 7. On Starter and Growth the window is one choice for the whole store. That is enough for most catalogues and it is not enough for some.

Whichever you choose, review it after a peak. The window that worked in a flat month is the one most likely to embarrass you in November.

No app can read your lead time out of Shopify, because it is not in Shopify. It is in your supplier's production queue, your freight forwarder's schedule, customs, and the two days your own warehouse takes to receive and put away. Any tool that claims to know it is guessing.

So treat it as your input and get it right. What to include, in order:

• Time for the supplier to acknowledge and produce or pick the order
• Transit, including the slow leg if you ship by sea
• Customs and clearance, if it crosses a border
• Your own receiving, counting and putaway before the stock is actually sellable

That last one is the most commonly forgotten. Stock in a box in your own building is not stock you can sell. If receiving takes three days in a busy week, those three days belong in the lead time.

Keep it per SKU, and revise it

One supplier can ship one line in ten days and another in forty. Store lead time per SKU. Restoc takes a merchant-input lead time per SKU on every plan for exactly this reason, and the reorder point moves with it the moment you change it.

After each purchase order, compare what happened to what you had recorded. If a supplier slipped, raise the number. This is fifteen seconds of work per order and it is the highest return maintenance task in the loop. A wrong lead time makes every reorder point built on it wrong in the same direction.

An alert is only as good as the place it arrives. Two routes cover almost every store.

Email. Works when one named person owns reordering. It sits in an inbox until dealt with, which is a feature. It fails when the alert goes to a shared address nobody treats as theirs.

Slack. Works when reordering is a team habit and the channel is already part of the day. Put stock alerts in their own channel, not the general one, so the list is skimmable on a Monday.

Restoc fires alerts when a SKU crosses its reorder point: by email on every plan, and by Slack incoming webhook on Growth and Pro. Note the wording. Crosses its reorder point, not drops under a flat number you picked once. The threshold moves with velocity and lead time, so a SKU that starts selling faster gets flagged earlier without you touching anything.

The duplicate problem

Here is where most homegrown alerting dies. A job runs, the SKU is still under its threshold, so it sends again. And again the next day. Within a fortnight the channel is noise and everyone mutes it. At that point you have an alerting system worse than nothing, because you believe you are covered.

Restoc delivers alerts through an idempotent background job. In plain terms, re-running it for the same SKU and the same threshold crossing does not send you the same alert twice. One crossing, one alert. That is the difference between a channel people read and a channel people mute.

Alerts are interrupts. They are good at telling you something changed and bad at telling you what to do about fifteen SKUs at once. The counterpart is a scheduled list, and it is the habit most merchants miss when they rebuild.

The review is simple. Same slot every week. In front of you: every SKU currently below its reorder point, how much to order, and nothing else. You group by supplier, you place the orders, you close the tab. Thirty minutes, and the interrupts during the week become confirmation rather than surprise.

Restoc produces a weekly reorder report listing the SKUs below their reorder point with a suggested order quantity for each. You can read it in the app or export it as CSV, which is the format that survives contact with a supplier. Paste it into an email, drop it into a purchase order template, hand it to whoever places orders. Between reviews, the dashboard shows current stock, days of inventory remaining and reorder status per active SKU, so a mid-week question gets answered on one screen.

Read the suggestion, then use your judgement

A suggested quantity is arithmetic, not a decision. It does not know that your supplier has a minimum order of 500, that a container is cheaper full, that you are discontinuing a colourway in spring, or that cash is tight this month. Treat it as the starting number and override it on purpose. The value is not that the software decides for you. It is that you are deciding from a complete list instead of from whatever you happened to notice.

Whatever you pick, run it past this list before you install it. Six questions, five minutes.

• Does it do the four jobs? Stock, velocity, lead time, alert. If any one is missing you will be back in a spreadsheet within a month.
• Does the threshold move? A fixed low stock number is a guess that goes stale. A reorder point built from velocity and lead time updates itself as your store changes.
• Does the SKU cap fit your real count? Count active stocked SKUs, not products. Variants are what get tracked, and stores are often surprised which side of a cap they land on. Restoc's caps are 200, 1,000 and 2,000 tracked SKUs on Starter, Growth and Pro, enforced on the server rather than as a polite suggestion.
• How many locations do you need? Restoc covers one location per plan. If you hold stock in three warehouses and need different reorder points per location, this is not your tool, and we would rather say that now than after you have installed it.
• Where do alerts land, and will they be read? One channel, owned by a person, with no duplicate sending.
• Can you get your data back out? You are on this page because a tool went away. Ask the export question on day one, not on the day you need it.

A note on names

Descriptive comparison, stated once for clarity: the discontinued Shopify inventory tool many merchants are migrating from is Stocky, which is Shopify's product name and Shopify's trademark, used here only to identify it. Restoc is an independent app for inventory reorder alerts on Shopify stores, and it is not affiliated with or endorsed by Shopify. Everywhere else on this site we describe what the app does in functional terms, which is also the more useful way to shop.