Back-in-stock alerts: how to build the flow and what it is worth

Every other flow in your account infers intent. Cart abandonment infers it from a cart, browse abandonment from a handful of page views, replenishment from an average interval. A back-in-stock request does not infer anything. Somebody typed their email address into a box underneath a product they could not buy, specifically so that you would tell them when they could.

That makes it the highest-intent audience a shop ever assembles, and the conversion rates on these alerts are unlike anything else you send. The reason shops under-invest in them is not that the value is unclear. It is that the mechanics are slightly awkward — they depend on stock data arriving quickly, on variants being tracked correctly, and on a set of decisions about fairness that nobody enjoys making. All of that is worth the trouble, and none of it is difficult once the decisions are written down.

Why this request is unlike every other signal you collect

It is worth being precise about what a back-in-stock request actually tells you, because the precision is the reason the flow performs.

A cart tells you somebody assembled an order and stopped. There are a dozen reasons for that, and most of them are about your checkout: the shipping cost appeared late, the payment method they wanted was missing, the delivery estimate was longer than they hoped. The message that recovers a cart is fighting whichever of those it was, without knowing which.

A product view tells you considerably less. People arrive from search, realise they are in the wrong place, and leave. Treating a view as intent produces a flow that emails everybody about everything.

A back-in-stock request tells you something narrower and far more useful: this person wanted this exact thing, was ready to act, and was stopped by one specific obstacle that you control and that is temporary. There is no ambiguity about the reason and no persuasion required. When the obstacle is removed, the only job left is telling them.

That is why the flow deserves more engineering attention than its size suggests. It is also why the failure modes are so costly. An alert that arrives late is not a slightly worse email; it is a promise you made to somebody who was ready to buy, broken at the one moment it mattered. Shops that run this badly generate more ill will per message than any campaign they send.

Capturing the request without losing most of them

The form is small, and every additional field on it costs you requests. Treat it as the single-purpose thing it is.

1. Email address only. Not a name, not a phone number, and not a marketing checkbox as a condition of submitting. You can ask for more later, once you have delivered something useful and earned the right to.
2. Capture the exact variant. A notify-me button on a product page with size and colour selectors has to record which combination the person was looking at. An alert telling somebody their item is back, in a size they cannot wear, is worse than no alert — it consumes the goodwill and delivers nothing.
3. Do not require an account. The request itself is the beginning of the relationship. A registration wall in front of it removes the majority of them, and the people it removes are disproportionately first-time buyers, who are exactly the ones you are trying to convert.
4. Offer the marketing opt-in separately, and afterwards. A back-in-stock request is a specific, limited permission for one message about one product. Treating it as a general newsletter subscription is a compliance problem under any reading of consent rules, and practically it is a fast route to complaints from people who never asked for a newsletter.
5. Confirm immediately, with the product name and the variant written out in full. This is not a formality. It is how somebody knows the request registered, and it is your only chance to correct a wrong variant before the restock happens.

One further detail that is easy to miss: record the timestamp. It costs nothing at the time and it becomes the fairest possible ordering rule when the restock turns out to be smaller than the queue.

Speed is not a nice-to-have, it is the entire product

This is the flow where synchronisation lag stops being an abstraction and starts being the difference between revenue and an apology.

The chain is short and every link matters. Stock changes in the shop. Your marketing system learns about it. The alert sends. If any of those three is batched rather than immediate, the flow is decorative. A restock of forty units with three hundred people waiting is decided within the first hour, and frequently within the first ten minutes. An alert that goes out on tomorrow morning's catalogue sync reaches people after the thing has gone again — and reaches them with an email that says, in effect, that you told them too late.

The mechanism that works is a webhook on product or stock update, processed immediately, with the send happening on its own rather than waiting for a scheduled window. The mechanism that does not work is a nightly or hourly catalogue import, however reliable it is otherwise.

Measure it rather than assuming it. Record the shop's own timestamp for the stock change alongside the moment your alert went out, and keep the distribution — median and ninety-fifth percentile, not the average, which a single stuck record will ruin. If the ninety-fifth percentile is measured in hours, fix that before touching a word of the copy. No subject line compensates for arriving second.

There is one deliberate exception to sending immediately. If a restock lands at three in the morning in the customer's timezone, sending at once is correct anyway — the people who act on these alerts check their phone at odd hours precisely because they know stock is finite. Holding the message until a polite hour is optimising for an etiquette nobody in this audience asked for.

What to do when the restock is smaller than the queue

Sending three hundred alerts for forty units creates two hundred and sixty disappointed people, several of whom will write to you about it. This is a fairness problem before it is a marketing problem, and the honest options are all better than the clever ones.

1. Send in waves, oldest request first. Batch sizes roughly matched to the stock, with a gap between waves so the first group has a genuine chance. First-come, first-served is a rule people understand and accept, and it rewards the person who asked earliest, which is the only defensible ordering.
2. Say how many there are when the number is genuinely low. "Back in stock — 40 available" sets an expectation that a sell-out then meets rather than breaks. The same sell-out, unannounced, reads as a bait-and-switch.
3. Never hold a wave back to manufacture urgency. Real scarcity does not need help, and layering invented pressure on top of it is the version of this that turns into a complaint and, in the EU, into a potential unfair-practices question.
4. Tell the people who missed it. A short note — it sold out again, you are still on the list, we have more arriving — costs nothing, keeps the request alive, and converts a bad experience into a neutral one. Almost nobody does this and it is the cheapest goodwill available in the whole flow.

Waves also give you something operationally useful: a read on how fast this particular product converts. If the first wave of forty clears the stock in twenty minutes, the buyer should know that, because it is a far stronger signal than a sales report.

Variants, partial restocks and requests that go stale

The awkward mechanics live here, and they are the reason many shops end up with a flow that technically works and practically annoys people.

• Alert per variant, not per product. One person waiting on two sizes of the same shirt is two requests. They should receive one alert when either arrives, not two near-identical emails within seconds of each other, and not one alert that fails to say which size came back.
• Handle partial restocks properly. A product returning in three of its eight sizes should alert only the people waiting on those three. Alerting everybody because the parent product now has stock is the single most common implementation bug in this flow, and it is indistinguishable from carelessness on the receiving end.
• Expire old requests. A request made fourteen months ago is not intent any more; it is an address that will be surprised to hear from you. Six months is a reasonable life. After that, ask once whether they still want to know, and drop the ones who do not answer.
• Clear a request once it is fulfilled. Somebody alerted, who then bought, should not remain in the queue for the next restock of the same item.
• Suppress if they acquired it another way — a different variant, a different channel, in person. Checking the order history at send time costs one query and prevents the most avoidable version of a wasted alert.

None of this is conceptually hard. All of it depends on having variant-level stock and order data available quickly, which is the same dependency as the speed requirement above. Get that right and the rest is a modest amount of logic.

Writing the alert

This is the rare marketing email where the writing barely matters, which is itself the instruction: do not get in the way.

1. Say the thing, in the subject. "Oud Royale 50 ml is back" is the whole message. Nothing clever, nothing withheld. The person already wants this; a teasing subject line only delays them.
2. Name the variant in the body, exactly as they chose it. Size, colour, capacity. This is the field that stops an alert being useless.
3. One button, straight to the product with the variant preselected. Every additional step between the email and the cart loses a share of a conversion you had already earned. Landing on a generic category page is the fastest way to waste the best email you will send this month.
4. Price from the shop at send time, not from the moment the request was made. Prices move, and a stale price in this email produces a support ticket at the exact moment somebody is trying to buy.
5. No discount, no cross-sell, no newsletter block. The entire value is speed and clarity. Anything else in the message is competing with the one action you want.
6. Keep it short enough to read on a phone in four seconds, because that is the situation nearly all of these are read in.

The only optional element worth including is quantity, when it is genuinely low, for the reasons in the previous section. Everything else is subtraction.

The demand signal your buyer is not getting

The revenue from these alerts is the obvious output. The second output is frequently worth more, and almost no shop routes it to the person who needs it.

A ranked list of products by outstanding notification requests is the cleanest read on unmet demand that a shop can produce. It is better than internal search logs, which capture people looking for things you may never have sold. It is better than a wishlist, which captures aspiration rather than readiness. A back-in-stock request comes from somebody who reached the product page, decided, and was stopped only by availability — the last possible moment before a sale.

That list answers questions merchandising otherwise guesses at. Which sizes are chronically under-ordered. Which colourway to repeat next season. Whether a discontinued line still has a queue waiting for it. Which supplier's delays are costing the most, measured in people rather than in units.

Put it in front of whoever does the buying, weekly, ranked by requests and by the revenue those requests would represent at current prices. Include the conversion rate on past restocks of the same product, because a queue that historically converts at sixty per cent is a different argument from one that converts at ten.

One caveat worth stating in the same report: requests accumulate while a product is unavailable, so a long absence inflates the queue relative to genuine ongoing demand. Show the request rate per week alongside the total, and the two together tell the truth.

Measuring it, and the one test not worth running

This flow is unusual in that the standard measurement advice mostly does not apply, and it is worth being explicit about why.

A holdout is close to pointless here, and arguably wrong. Withholding an alert that somebody explicitly requested is not a measurement decision, it is a service failure. The counterfactual you would be measuring — what happens to people who asked to be told and were not — is one you should never create deliberately. Run holdouts on cart recovery, on browse, on win-back. Not on this.

What to measure instead:

• Revenue per alert sent, which will be the highest figure in your whole programme and should be reported separately so it does not flatter your campaign averages.
• Time from stock change to send, as a distribution. This is the operational number and the one most likely to degrade quietly after an unrelated change.
• Conversion rate per wave. If the second wave converts far worse than the first, your waves are too large or too far apart.
• Requests per product per week, for the merchandising report above.
• Unsubscribes and complaints on alerts, which should be near zero. Anything else means you are sending alerts people did not ask for — usually the partial-restock bug.

Finally, resist the temptation to expand the flow. The moment a back-in-stock alert starts carrying a promotion, a related-products grid or a newsletter signup, its performance decays and its complaint rate rises, because you have converted a service message into a marketing one. It is the most valuable email you send precisely because it is the least commercial.