Sizes and colours deplete differently: a reorder point per variant
Shopify counts stock per variant, which means a reorder point for the parent product is an average of your fastest seller and your slowest. Restoc is built to put a reorder point on every variant it tracks, worked out from your own sales velocity window and the lead time you enter for that SKU.
The job: one number per size and colour
You list one hoodie. Five sizes, three colours, fifteen variants, fifteen separate piles on the shelf. The product page reports 180 units in stock and looks healthy. Medium black is on three. XL sand has not moved in a month and will still be sitting there at Christmas.
That is the moment this page is about. Shopify holds inventory per variant, your supplier ships per variant, and your customers buy per variant, so the only reorder point you can act on is the one attached to the variant. A single number for the parent product blends the fast mover with the dead one and tells you nothing in time.
Merchants say it plainly: sizes and colours deplete differently, and some items sell in bursts rather than evenly. Since the inventory tool many Shopify stores leaned on was retired, a lot of this arithmetic has gone back into a spreadsheet, one row per variant, rebuilt by hand on a Monday morning and already out of date by Wednesday.
The decision in front of you is not which forecasting engine is cleverest. It is whether you keep recomputing per-variant reorder maths by hand, or have a number sitting beside each variant that moves as the sales come in.
Why the parent product number misleads you
Three things go wrong when the reorder point sits one level too high.
- The averages cancel out. Medium black at four units a day and XL sand at a tenth of a unit a day average to something no variant actually sells at. The average looks safe while the fast variant is days from zero.
- The stockout is per variant, not per product. A customer who wants medium black does not buy XL sand instead. The product stays listed, the revenue does not arrive, and the loss is invisible on a product-level stock count.
- Lead time belongs to the SKU. A reprint, a dye lot, a different supplier for the oversized sizes: the wait is rarely identical across a run, and a product-level number cannot carry more than one of them.
What a per-variant reorder point actually needs
Three inputs, and only three. Sales velocity for that variant over a window you choose. The lead time for that specific SKU, which is the number only you can supply. A current stock figure you trust, read from Shopify rather than retyped. The arithmetic itself is the easy part. Keeping it current across several hundred variants is the work, and that is the part Restoc is built to take.
If you want the formula itself, or the argument about which window to use, the pillar has separate pages for both. This one is about what the formula looks like when it runs once per variant instead of once per product.
How Restoc works a reorder point per variant
- Connect the store once
A Shopify OAuth install pulls real-time inventory levels and historical sales data through webhooks plus a scheduled sync job. Restoc is a web app, with no mobile app and no browser extension.
- Every variant becomes a tracked SKU
Each variant is tracked on its own: title, your SKU code, Shopify variant id, current stock, lead time and computed reorder point. Nothing is rolled up to the parent product.
- Pick the sales velocity window
Choose 7, 14 or 30 days for the store. A short window reacts to a burst, a long one smooths a lumpy seller. On Pro you can override the window for an individual SKU when one variant behaves differently from the rest of the catalogue.
- Enter the lead time for that SKU
Lead time is merchant input, per SKU, because no API knows how long your supplier really takes on that colour. The reorder point is calculated from velocity and lead time by a tested function, so the same inputs always give the same number.
- Read the dashboard per variant
Current stock, days of inventory remaining and reorder status for each active SKU, one row per variant, so the medium black line and the XL sand line are never the same line.
- Let the crossing come to you
When a SKU crosses its reorder point, an alert fires by email, and by Slack webhook on Growth and above, delivered through an idempotent background job so one crossing means one message.
- Turn the week into an order
A weekly reorder report lists the SKUs below their reorder point with a suggested order quantity, viewable in the app and exportable as CSV, which is the list you actually send to a supplier.
What this gives a store running sizes and colours
One row per variant
The dashboard is built around the active SKU, so a fifteen-variant hoodie reads as fifteen lines with their own stock, runway and reorder status.
The fast colour gets its own clock
Days of inventory remaining is computed from that variant's velocity, so the size that empties first surfaces first instead of hiding inside a healthy product total.
Lead time where lead time belongs
Set it per SKU. If the oversized sizes come from a slower supplier, their reorder points sit higher, without touching the rest of the run.
Burst sellers and steady sellers in one store
The store-wide window of 7, 14 or 30 days covers most catalogues, and Pro adds a per-SKU velocity window override for the variants that refuse to behave like the others.
Alerts that name the SKU
The alert fires on the crossing of that SKU's reorder point, so you learn which variant needs ordering rather than that something somewhere is low.
A reorder list, not a dashboard tour
The weekly report names the SKUs below their reorder point with a suggested quantity and exports to CSV, so a variant-heavy order takes minutes rather than a morning.
Where each per-variant number comes from
| The number | Where it comes from | Set at |
|---|---|---|
| Current stock | Shopify inventory levels for that variant, via webhooks plus a scheduled sync | Each tracked SKU |
| Sales velocity | Your own sales history for that variant over the chosen window | Store-wide window of 7, 14 or 30 days; per-SKU override on Pro |
| Lead time | You type it in; nobody else knows your supplier's real wait | Each tracked SKU |
| Reorder point | Calculated from velocity and lead time by a tested function | Each tracked SKU |
| Days of inventory remaining | Current stock measured against that variant's velocity | Each tracked SKU |
| Reorder status | Whether the variant's stock sits below its reorder point | Each tracked SKU |
Plans, counted in tracked SKUs
Starter, $29 per month
Up to 200 tracked SKUs and one location. Reorder point per SKU from your velocity and lead time, a store-wide window of 7, 14 or 30 days, email alerts on a crossing, the weekly reorder report with CSV export, and the days-of-inventory dashboard. Billed by Shopify on your Shopify invoice.
Growth, $59 per month
Up to 1,000 tracked SKUs, five times Starter's capacity and enforced at sync time, plus Slack alerts through an incoming webhook alongside email. The sensible tier once a size run multiplies your variant count.
Pro, $99 per month
Up to 2,000 tracked SKUs, everything in Growth, and custom reorder rules: a per-SKU sales velocity window override for the variants that sell in bursts.
Paid yearly
Starter $290, Growth $590, Pro $990 a year: ten months' price for twelve. Every plan carries a 60-day free trial, long enough that at least one full weekly reorder cycle completes before the first charge.
Where this stops, said plainly
We would rather you know the edges before you connect a store.
- The velocity window is store-wide on Starter and Growth. The per-SKU override is a Pro feature, so on the lower tiers every variant shares one window and differs by its own velocity, stock and lead time.
- Each variant counts as one tracked SKU against your plan's cap, and the caps of 200, 1,000 and 2,000 are enforced server-side at sync time. A catalogue of 60 products in six sizes is 360 SKUs, not 60, so size the plan on variants.
- Plans cover one location.
- Restoc is a web app. There is no mobile app and no browser extension.
- A freshly connected store needs sales history before velocity means anything. There is a separate page in this pillar on what the numbers look like on day one.
- Lead time is yours to supply. Restoc will not guess it, and a reorder point built on a guessed lead time is a guess.
Questions
Does a reorder point per variant mean one for every size and colour?
Yes. Each variant Restoc tracks is its own SKU, with its own current stock, lead time, computed reorder point, days of inventory remaining and reorder status. Nothing is averaged up to the parent product.
Can two variants of the same product use different sales velocity windows?
The window of 7, 14 or 30 days is set for the store on Starter and Growth. Pro adds a per-SKU override, so a variant that sells in bursts can use a shorter window than the rest of the catalogue.
Can I set a different lead time for each variant?
Yes. Lead time is merchant input per SKU, which is the point: if the larger sizes come from a slower supplier, their reorder points rise without you touching the fast movers.
Does every variant count against my plan's tracked SKU limit?
It does. Caps are 200 on Starter, 1,000 on Growth and 2,000 on Pro, enforced server-side at sync time. Count variants, not products, when you pick a tier.
What does the dashboard actually show per variant?
Current stock, days of inventory remaining and reorder status for each active SKU, so you can see which variant empties first rather than reading a product-level total.
What happens to a variant with no recent sales?
With no sales in the window there is no velocity to work from, so that variant has no meaningful runway until orders land. In practice those are the slow colours you are watching for dead stock rather than for reordering.
How do I hear about a crossing?
By email when a SKU crosses its reorder point, and by Slack webhook on Growth and above. Delivery runs through an idempotent background job, so one crossing produces one message, not a stream of repeats.
Is there a mobile app?
No. Restoc is a web app only, with no mobile app and no browser extension. Alerts reach your inbox or your Slack channel, which is where most merchants want them anyway.