Your email platform knows a great deal about your customers. It knows almost nothing about your stock.
That asymmetry is invisible while everything is in stock, and it produces five distinct failures the moment something is not. All five are common, all five are quiet, and the most expensive of them is the one that looks most like success — a back-in-stock alert with an excellent open rate, sent to four hundred people about twelve units.
This guide covers what breaks, what can be configured away, and what cannot.
Back-in-stock is the highest-intent message you will ever send
Worth establishing first, because it justifies the care.
Every other automated message infers intent. A browse abandonment email guesses that looking means wanting. A back-in-stock alert does not guess: the customer found the product, found it unavailable, and volunteered their email address specifically to be told when they could buy it. There is no stronger signal in ecommerce.
Agencies publishing benchmarks report conversion rates on this flow well above other automations — figures in the twenties and thirties are commonly quoted. Treat those as directional rather than authoritative; they are self-reported by parties with an interest. Your own number is the one that matters, and it is measurable.
What follows is how stores waste it.
Failure one: alerts registered at product level
The notify-me widget must appear on sold-out variants, not only on sold-out products.
This is the most common configuration error in the category and it is easy to miss, because a store whose products rarely sell out entirely will appear to have no back-in-stock subscribers at all. The founder concludes there is no demand. In fact the widget never appeared, because the product was never out of stock — only the medium was.
A customer who wanted a medium in navy does not want to hear that a large in black has returned. Alerts that fire at product level train people to ignore them, and an ignored alert is worse than no alert, because you have spent the goodwill.
Check yours by setting a single variant to zero on a test product and viewing the page as a customer. If no notify-me option appears, the widget is bound to product availability rather than variant availability.
Failure two: sending to everyone
The arithmetic that nobody runs.
Four hundred people are subscribed to a variant. Twelve units arrive. The default behaviour of most tools — including Klaviyo's native back-in-stock — is to alert everyone at once.
The first twelve buy. The other 388 receive an email inviting them to buy something that was gone before most of them opened it. Some click through and land on an out-of-stock page. Some mark it as spam. All of them learn that your restock emails are unreliable, and the next one performs worse.
You did not gain twelve sales you would otherwise have missed. You gained twelve sales you would have made anyway — those units were selling regardless — and paid for them with 388 units of trust.
The fix is batching. Release alerts in waves sized against the quantity actually received. Twelve units means a first wave of perhaps twenty-five to forty, then a second wave only if stock remains. Most back-in-stock tools support batched or staggered sending; almost nobody configures it, because the default works and the cost of the default is invisible.
The related discipline: if you run a follow-up email in the sequence, condition it on stock still being available at send time. A "last chance" email for something already sold out is the same failure with worse framing.
Failure three: the multi-location trap
Specific, documented, and unfixed for years.
Klaviyo's native back-in-stock functionality does not distinguish between Shopify locations. It reads total available inventory for a variant across every location you hold stock in. If you add stock at a retail shop, a pop-up, or a location not enabled for online fulfilment, the alert fires — and the customer arrives at a product page that still says sold out.
This has been raised repeatedly in Klaviyo's own community over a period of years and remains the behaviour.
If you hold stock in more than one location and only some are enabled for online orders, this affects you now. It will affect you more the moment you add a second location, which is the subject of a later guide in this series. Dedicated back-in-stock apps vary in how they handle it — this is a specific question to ask before choosing one, and it will not be answered on the App Store listing.
Failure four: cart and browse recovery for things you no longer have
Abandoned cart, abandoned checkout and browse abandonment flows all reference a product the customer interacted with at some point in the past. Between that moment and the send, stock can go to zero.
Shopify's own abandoned checkout recovery and every third-party equivalent will happily send an email featuring an item that is no longer available. The customer clicks — these emails convert well, which is exactly the problem — and arrives at a dead end.
Klaviyo and comparable platforms can check a variant's current inventory at send time and skip or substitute. This is a flow filter, it takes minutes to add, and it is absent from the overwhelming majority of stores at this size because the default template does not include it.
Add an inventory condition to every flow that features a specific product. Every one.
Failure five: the campaign build-to-send gap
The one nobody talks about, and structurally the hardest.
You build Friday's campaign on Wednesday. The hero product — the reason the campaign exists, the image at the top, the subject line — sells out on Thursday afternoon. The campaign sends to eight thousand people on Friday morning exactly as designed.
Nothing in any email platform prevents this. The campaign is a static artefact from the moment it is scheduled. There is no field connecting the product this email is about to whether that product is available, in the same way there is no field connecting an ad creative to stock, which is the subject of Guide 04.
Partial mitigations exist. Dynamic product blocks pulled from a live feed will reflect current availability, which protects the grid of products further down but not the hero image or the subject line. A manual stock check immediately before sending works and depends on someone remembering.
For a store sending four campaigns a month, remembering is a reasonable system. At twelve campaigns a month across segments, it stops being one.
What can you configure this week?
Bind the notify-me widget to variant availability. Highest return, usually a theme or app setting rather than a rebuild.
Turn on batched sending and size the first wave against typical restock quantity rather than subscriber count.
Add an inventory condition to every flow that features a product. Abandoned cart, abandoned checkout, browse abandonment, replenishment, cross-sell. All of them.
Exclude people who already bought. A flow filter removing anyone who has purchased that item since subscribing. Obvious, frequently missing.
Check your location configuration if you hold stock in more than one place, particularly if any location is not enabled for online fulfilment.
Decide whether you need a dedicated app at all. If you already run Klaviyo, its native back-in-stock covers email, SMS, batching and flow integration, and for many stores at this size that is sufficient. The dedicated apps — Swym, Stoq, Restock Rocket among others — offer deeper customisation, better analytics and, in some cases, better location handling. Free and low-cost tiers are common. Do not pay for a second tool until you have established that the one you already have falls short, and Guide 02 covers this category in more detail.
What cannot be configured away?
Everything above is a setting. None of it is a system.
The remaining gap is that your messaging platform holds intent — who wants what, at variant level, right now — and your inventory holds supply, and nothing reconciles the two continuously. Batching approximates it. Flow filters catch the obvious cases. Neither can answer the question that actually matters: given twelve units arriving and four hundred people waiting across six variants, who should be told, in what order, and what should the rest be offered instead?
That is an allocation problem, and allocation requires knowing both sides at once.
The App Ceiling
This section appears in every one of The Operational Guides. It describes where the advice above stops working.
Everything above holds to roughly £1m–£1.5m in annual revenue. Past that point the constraint changes, and it changes in a way that adding further apps does not address.
Apps are built to be sold to many stores. That is what makes them affordable, and it is also what limits them: an app can only act on the data inside its own boundary. Your forecasting tool does not know what your ad platform is spending. Your ad platform does not know what is out of stock. Your back-in-stock tool does not know what your supplier lead times are. Each app is correct within its own scope and blind outside it.
Below roughly £1m, a person bridges those gaps. Someone looks at the stock report, notices a line is running low, and adjusts. The bridging is invisible because it is absorbed into the founder's day.
Above roughly £1m, three things happen at once. SKU count rises, so there is more to bridge. Order volume rises, so the consequence of missing something rises with it. And the founder's time is now spent on growth rather than operations, so the bridging stops happening reliably. Nothing breaks visibly. Revenue keeps climbing. What changes is that a percentage of it begins to leak in places nobody is looking — advertising spend running against unavailable variants, stock accumulating in the wrong location, returns sitting unprocessed for a week and a half while the item they contain is out of stock and being advertised.
That is not an app problem, and no app solves it, because the solution has to sit between systems rather than inside one. It requires something built for your specific stack, your specific SKU structure, and your specific supplier terms.
Build the foundations well now. The stores that struggle most at £2m are not the ones that used the wrong apps. They are the ones whose product data was never structured properly in the first place, which makes every subsequent automation expensive to build.
Where should you start?
Set one variant to zero on a test product. View the page as a customer. If no notify-me option appears, that is your first job and it is worth more than everything else in this guide combined.
Then open your abandoned cart flow and add an inventory condition. It takes five minutes and it stops you paying to send people to dead ends.