If four hundred people are waiting and you restock thirty, notifying everyone produces three hundred and seventy customers who click through to a sold-out page for the second time. The fix is to match the notification to the stock — alert only as many people as you can serve, in the order they joined, or send in waves and stop when it runs out. Which of the two you choose depends on how scarce the item is and how fast your waitlist converts.
Why "notify everyone" is the default and why it is wrong
Most apps send to the whole waitlist because it is the simplest behaviour to build and it produces an impressive number in a dashboard: four hundred notifications sent.
What it produces on the customer side is a race nobody was told they were entering. Thirty people win. The rest experience a second rejection on the same product, this time after being specifically invited back.
The damage is not the lost sale — those units sold either way. It is that you have taught three hundred and seventy people that your restock emails are not worth opening, which costs you every future restock.
Quantity-matched notification
Alert exactly as many subscribers as you have units, in the order they joined the list. Thirty units, thirty emails.
Advantages: everyone notified can actually buy. Nobody is disappointed. The queue is visibly fair — first in, first told — which is defensible if anyone asks.
Cost: if some of those thirty do not act, units sit unsold while people further down the list would have bought. You have traded revenue for goodwill.
Right for genuinely scarce items, high-value products, and anything where the waitlist converts well.
Batched sending
Notify in waves — fifty, then another fifty after an hour — and stop when stock runs out.
Advantages: recovers more revenue when conversion is partial, because each wave backfills for the people who did not act.
Cost: some later waves will find it sold out. Fewer than notifying everyone, but not zero.
Right for larger restocks, lower-priced items, and any waitlist where you expect a low click rate.
Choosing between them
The deciding number is what share of notified subscribers buy.
- High conversion? Quantity-matched. If most notified people buy, waves only add the risk of disappointing later ones.
- Low conversion? Batched, sized so each wave is expected to sell roughly the stock it is aimed at. Alerting thirty people about thirty units when only one in five acts leaves twenty-four units unsold and a waitlist still waiting.
You will not know your rate before the first restock. Start quantity-matched — the failure mode is unsold stock rather than annoyed customers — and move to batches once you have a number.
Ordering the queue
Once you are not notifying everyone, you are choosing who to tell first, and that is worth being deliberate about.
- Signup order. The default and the easiest to defend. First in, first told.
- By customer value. Effective and hard to explain if it comes out. A customer who joined first and was told third will be unimpressed.
- By likelihood to convert. Maximises revenue per notification, and is really the same thing wearing different clothes.
Signup order is the right default for most stores. If you do prioritise, know that you are making a choice you would have to justify.
Telling the people who are still waiting
The subscribers you did not notify are the whole reason this problem is worth solving, and most stores say nothing to them at all.
Saying something is straightforward and works:
- If more stock is coming: "This restock was small and sold out. You are still on the list and near the front for the next one." That converts a non-event into a reason to stay.
- If it is not: say so, and point at the closest alternative. A subscriber told the product is discontinued may buy something else. One left waiting indefinitely buys nothing and eventually unsubscribes.
Silence is the worst option and it is the default.
What the notification should say when stock is short
A notification sent against limited stock is a different message from one sent against a full restock, and treating them the same wastes the difference.
Two things belong in it:
- That the restock is small. "Back in stock — limited quantity" is true, sets the right expectation, and gives an honest reason to act now. It also softens the blow if the recipient is too slow, because they were told.
- A direct link that adds to cart, not a link to the collection. Every extra click on a race you created costs a customer who was told in good faith.
What does not belong: other products. A restock alert bundled with four recommendations is a newsletter, and it converts like one — while also slowing down the person you are supposedly helping.
And resist urgency language beyond what is true. "Only a few left" is fine when a few are left. On a full restock it is the kind of small dishonesty that customers notice across enough emails, and this list is one you particularly do not want to teach scepticism.
The upstream fix
A waitlist consistently larger than your restocks is telling you something about purchasing, not about notifications.
That is the underrated value of the data. Sixty people waiting on one size is a demand measurement you cannot get from a sales report, because a sales report only counts demand you were able to fulfil.
So use it:
- Reorder quantities should reflect waitlist size, not just past sales.
- Size and variant splits are visible in the waitlist with unusual clarity — it shows exactly which variant people wanted and could not get.
- Repeatedly long waitlists on the same product mean you are systematically under-ordering it.
Fixing that is worth more than any notification strategy. The best outcome is a waitlist that shrinks because the stockouts stop.
Overselling, which is the other failure
There is a second way this goes wrong that has nothing to do with who you notified.
Thirty units, thirty notifications, and forty orders. Shopify's inventory decrements at checkout, but a burst of simultaneous checkouts on the same variant can complete before the count catches up — and a restock notification is precisely engineered to produce simultaneous checkouts.
You are then cancelling orders from the customers you invited back, which is worse than not having notified them.
Three things reduce it:
- Do not send the whole batch in the same second. Even a few seconds of spread between notifications flattens the spike enough to matter.
- Hold a small buffer. Notifying against 28 of 30 units costs almost nothing and absorbs the race.
- Check your oversell setting. A store allowing orders past zero inventory will take every one of those forty and leave you to sort it out.
Worth deciding in advance what you do if it happens: cancel the last orders and refund promptly with an apology and something for the trouble, or honour them and eat the backorder. Either is survivable. Deciding during the incident is not.
Setting it up
- Check your app can do either. If it only offers "notify all", this problem is coming.
- Start quantity-matched.
- Measure notification-to-purchase on the first two restocks.
- Move to batches if conversion is low, sizing waves to the stock.
- Write the still-waiting email once and reuse it.
- Feed waitlist size into reordering.
Stok supports both quantity-matched and batched notifications, so the behaviour is a setting rather than something you discover after a restock.
Where to go next
If your waitlists are long because restock dates are uncertain, a preorder may be the better instrument — preorders or alerts covers the test. For channel choice and timing generally, see the back-in-stock guide.
