A founder's story
I went looking for a specific kind of quote: a founder, on the record, describing the moment they realized a customer had walked to a competitor because a waitlist never converted into an actual notification. I searched podcast transcripts (Shopify Masters, DTC Pod), Starter Story and Indie Hackers interviews, founder blog post-mortems, and ecommerce forum threads. I did not find one clean, verbatim quote that matches this exact story attributed to a named person I could verify.
What I did find, from a real and checkable source, is a founder talking about a closely related version of the same problem: the gap between "we told the customer something" and "we told the customer something in the way that matched how badly they wanted it." Christian Nørbjerg Enger, co-founder and CPO at Segmento, put it this way in a Klaviyo case study: "Using email only for a high-demand restock can be a subtle insult to the customer's intent." He continues: "It communicates, 'Get to this whenever you have time.' We implemented SMS to match the physiological urgency of 'I don't want to miss this again,' which aligns better with the customer's desire." That's a real, sourced quote about restock communication, not a fabricated one, though it's about channel and urgency rather than the specific "you never told me" failure I was originally looking for.
So here's the honest version: a pattern that shows up repeatedly across founder interviews and DTC operator threads, not attributed to any single named person, because I won't put words in someone's mouth that I can't verify they said. A bestseller shade or size sells out. A waitlist form catches the interested customers, dozens or hundreds of them. Weeks pass. The item comes back, and what actually happens next is either nothing (nobody remembers to email the waitlist), or a generic restock announcement goes to the whole marketing list, not just the people who asked. The customers who signed up specifically for that variant get the same email as everyone else, if they get one at all, often after they've already bought the equivalent item somewhere that did notify them. The founder finds out only when a customer support ticket or a comment says some version of "I signed up for this months ago and never heard anything." That's the story. It's common enough that it didn't need one dramatic quote to be true, but I'd rather say that plainly than invent one to make the opening punchier.
Elaborating the pain
The batch restock email is the default because it's the easy thing to build: a segment, a campaign, a send. But it fails the customers who mattered most in a specific way.
A waitlist for a sold-out item is really several audiences bundled together, split by exactly which variant someone wanted. Someone who joined a waitlist for a size 8 in black doesn't care that size 6 in white is back. A batch email announcing "it's back!" to the full waitlist, without checking which variant actually restocked, either gets ignored by everyone who wanted the wrong variant, or worse, sends them to a product page where their size still shows sold out. That's a broken promise delivered as a marketing win.
Timing compounds it. Batch sends usually go out on a schedule (end of day, next morning, whenever someone remembers to build the campaign), not the moment stock actually updates. For anything with real demand, that delay is the whole game. The customers who cared enough to join a waitlist are, by definition, more likely to be watching elsewhere too. A same-day competitor restock, a similar item from another brand, an impulse purchase that fills the same need: all of it happens in the gap between "back in stock" and "customer told."
And a waitlist without an automated trigger is often just a form that dead-ends. It captures intent (an email address, sometimes a size or shade preference) but doesn't connect that capture to inventory in any live way. Someone has to remember the list exists, remember which variant restocked, and manually match the two. In a lot of smaller operations, that manual step just doesn't happen reliably, especially for a mid-tier SKU that isn't the obvious hero product getting all the attention.
What a solution could look like (the general landscape)
There isn't one right way to solve this, and it's worth being honest about what each common option actually does and doesn't solve.
A native platform waitlist widget, the kind bundled into a theme or a basic Shopify app, usually just captures an email against a product page. Some of these are variant-aware, most aren't. When stock comes back, they typically fire a single templated email to everyone on that product's list, without distinguishing which specific variant restocked. It solves "capture interest" and mostly fails at "notify the right subset of people at the right moment."
A dedicated back-in-stock app (Back in Stock, Swym, and similar tools) is a real step up. These are usually built to be variant-aware and can trigger sends automatically when inventory changes, which solves the manual-forgetting problem. What they don't solve on their own: they're still bound by the platform's inventory update frequency, they add another subscription and another data source to reconcile, and the send quality (is it going by email, SMS, both, and is the copy actually good) varies a lot between vendors.
A manual "email the list when it's back" process is what a lot of smaller brands actually run, whether or not they'd call it a process. Someone notices stock is back, pulls a list, sends a campaign. It's cheap and requires no new tooling. It's also the slowest option and the most variant-blind, because pulling "everyone who wanted this exact size" out of a spreadsheet or a basic app is tedious enough that people often just send to everyone who wanted the product at all.
A fully custom, variant-specific triggered alert is the most work to build and the most precise result. It watches inventory at the variant level, matches against a waitlist stored with variant-level detail, and fires the moment the match is true, not on a batch schedule. It's not the right investment for every brand. For a store with one or two SKUs and low variant complexity, a decent back-in-stock app is probably enough. It starts to matter more the more variants a catalog has and the more those variants genuinely don't substitute for each other in a customer's mind (a shade, a fragrance, a size that either fits or doesn't).
The solution I'd build
Here's how I'd actually build this, if I were solving it as a system rather than picking an app off a marketplace.
The core idea is simple: don't treat "back in stock" as a product-level event. Treat it as a variant-level event, and match it against a waitlist that was captured at the same level of specificity.
Start with capture. The waitlist form on a sold-out product page needs to record the exact variant, not just "interested in this product." If someone lands on a page for a shirt in six sizes and only size medium is sold out, the form needs to know that's the one they're waiting for, not silently default to "notify me about this product" and lose the size.
Next, watch inventory at the variant level, not the product level. Most platforms expose inventory via webhook or a polling API down to the SKU. The system needs to listen for the specific transition that matters: a variant going from zero (or below a threshold, if you want to catch "restocked but limited") to available. That's the trigger, and it needs to fire close to real time, not on whatever cadence a batch job happens to run.
Then match. When a variant restocks, the system queries the waitlist for everyone who asked about that exact variant, not the product family. This is the step that's easy to get lazy about, because it's tempting to just say "someone wanted this product, they're probably fine with any version of it." They're often not, and treating a shade or size waitlist as interchangeable is exactly the failure this whole system exists to fix.
Finally, send, immediately, with a direct link to the exact variant (not the product page, the actual buyable variant), and ideally through the channel most likely to get seen fast. Email is fine for most cases. For something genuinely high-demand, matching Christian Nørbjerg Enger's point above, a faster channel like SMS closes the gap between "back" and "bought" further, at the cost of needing explicit opt-in and being more expensive per send.
One more piece worth building in from the start: a short window (minutes, not hours) where the system checks it isn't about to notify more people than there's stock for. That's a real failure mode, not a minor edge case, and it leads into the next section.
Pros and cons
The upside is real: this reaches the customers who are most likely to buy, at the moment they're most likely to buy, with the exact thing they asked for. That's a genuinely different audience than a marketing blast, and it behaves differently.
The downsides deserve equal space, because a system like this can create new problems while solving the old one.
It depends entirely on accurate variant-level inventory data. If a platform's inventory count lags reality, or a warehouse system updates on its own schedule, the system will confidently notify people about stock that isn't actually there yet, or miss a restock because the count didn't update. Garbage inventory data in, garbage notifications out, and this is a system where a wrong notification is worse than no notification.
There's a real risk of a flash-sale stampede. If forty people were waiting on a variant and only twelve units came back, an instant, simultaneous notification to all forty creates its own bad experience: a wave of disappointed customers who got the email and still couldn't buy. That's arguably better than silence, since at least they know, but it's not free of downside, and it's worth deciding up front whether to throttle sends, cap the notified group, or just accept the scramble as the tradeoff for speed.
It doesn't fix a supply chain that genuinely can't keep the item in stock. If the underlying problem is that a popular SKU sells out every restock within hours no matter how it's communicated, no notification system solves that. It solves the communication gap, not the inventory gap, and it's worth being clear with yourself about which one you actually have.
And opt-in list quality varies a lot. Some waitlist signups are genuine, specific intent. Others are casual "sure, notify me" clicks from someone who's since forgotten the product exists. Conversion on any restock alert, however well built, is going to reflect that mix, not a uniform, highly-motivated audience.
How it gets implemented
The practical shape of this, independent of any specific vendor, has four parts.
Waitlist capture sits on the product page itself, tied to the specific variant selector, not a separate generic form. It needs to store product ID, variant ID, and a contact method (email, phone, or both depending on the channel strategy).
Variant-level stock watching connects to the platform's inventory events, typically a webhook that fires on stock level changes, sometimes supplemented by polling if the webhook coverage is incomplete for a given platform or app combination. This is the piece most sensitive to platform quirks: some platforms fire inventory webhooks reliably at the SKU level, others require extra configuration or a different endpoint to get that granularity.
Match-and-trigger logic is the part that turns a raw inventory event into a filtered, specific list of who to notify. It queries the waitlist store for exact variant matches, applies any throttling or capping logic decided on for the stampede scenario, and hands off to the send layer.
The send channel is usually email at minimum, with SMS as an option for higher-intent or higher-demand items where the opt-in exists and the urgency justifies the cost. Either way, the message needs a direct link to the specific variant, not the general product page, so the customer lands exactly where they need to be to buy, not back at a page that still shows their size as sold out.
KPIs: the cost of the pain, and the cited improvement
The most-cited number in this space traces back to a 2011 MarketingSherpa case study of a single retailer, BirkenstockCentral.com: a 22.45% conversion rate on back-in-stock alert emails. That's one company's result from one program, not an industry-wide benchmark, and it gets repeated often enough in marketing blog posts that it's worth restating the caveat every time: treat the number as illustrative of what a highly-intentioned, already-opted-in audience can do, not as a number any brand should expect to hit by default.
I looked for additional, independently verifiable statistics to add alongside it. Several vendor sites (back-in-stock app providers, in particular) publish conversion and click-through figures for their own back-in-stock alerts, but without disclosed methodology, meaning it's not clear whether those numbers come from a single customer, an average across their book, or a marketing claim without underlying data. I'm not including those here, because a number without a traceable source is exactly the kind of stat this article is arguing against citing.
What's verifiable and worth keeping in view instead is the logic, not a second percentage: a back-in-stock alert reaches a list that already told you, explicitly, that it wants this specific thing. That's a fundamentally different audience than a cold send or a generic newsletter blast, which is most of why the one verified case study number is as high as it is, and why the underlying mechanism (variant-specific, immediate, targeted) is worth building correctly even without a second citation to lean on.