Your restock email is late, and that is deciding who gets the sale

A customer signs up for a restock alert because they want the product now, or as close to now as they can get it. That single fact explains almost everything about why timing, not just whether the email sends, decides whether you get the sale.

Here is the part that is easy to miss when you are focused on getting the alert to send at all: a customer who signed up for your waitlist did not stop shopping while they waited. Many of them kept looking. Some found the same product, or something close enough, somewhere else. When your restock email finally lands, you are not just notifying a customer. You are racing every other option they found in the meantime, and the race started the moment the item sold out, not the moment it came back.

Demand does not wait for your app to catch up

When a product goes out of stock, a lot of customers do not wait around. In a 2024 AlixPartners holiday shopping survey, two-thirds of respondents said they would leave a store, online or physical, and shop elsewhere rather than wait for an item to come back (reported by SGB Media). Of those who left, about a third bought the item from a different retailer instead.

That is the baseline you are working against. Every subscriber on your back in stock list is a customer who, by definition, did not immediately buy elsewhere: they cared enough to leave their email and wait. But “waited” is not the same as “will still be waiting when you finally send.” The longer the gap between restock and notification, the more of that list has quietly moved on, bought a substitute, or lost the specific urge that made them sign up. Nobody re-signs up to tell you they changed their mind. They just do not click, and the product sells to whoever your competitor notified first.

This is why the real question is not “does our back in stock app work.” It is “how many minutes pass between the moment inventory updates and the moment the email actually lands in an inbox.” That gap is the entire product.

Too slow loses the sale, too fast loses the inbox

The obvious fix is to make that gap as small as possible. Fire the email the instant inventory ticks up. But sending instantly, to your entire list, all at once, creates a different problem, and it is one that can undo the speed advantage you were trying to buy.

Mailbox providers treat a sudden burst of outbound email as a signal worth watching. Google’s own guidance for bulk senders is direct about this: “Avoid sending email in bursts” and “avoid introducing sudden volume spikes if you do not have a history of sending large volumes,” because a spike like that can trigger rate limiting or hurt sender reputation (Google’s bulk sender guidelines). A popular item restocking to a waitlist of a few thousand people is exactly this kind of spike: a sending pattern that looks, structurally, like the pattern spam filters are built to catch, regardless of what the email actually says.

So the failure runs in both directions. Wait too long to send, and demand has already decayed, some subscribers have bought elsewhere, and the ones still interested feel like an afterthought. Send everything in one uncontrolled blast, and you risk landing a chunk of that same batch in spam folders, which produces the exact same outcome (a customer who never sees the email) for a different reason. Either way, “the app sent something” is not the same as “the customer got it while they still wanted it.”

The fix is not a single lever, it is pacing: releasing a large batch in controlled waves rather than firing every message in one instant, so volume stays inside what a receiving mail server considers normal for your sending history, while still getting every subscriber notified within a tight window, not a tight instant.

What “notify me” subscribers actually expect

Nobody who clicks “notify me when back in stock” is expecting a same-day digest. The mental model a customer has when they sign up is closer to a price alert or a flight-tracking notification: something changed, and I want to know close to when it changed, not at the provider’s convenience. A restock alert that arrives hours after the product actually came back reads, to the customer, less like “we told you as soon as we knew” and more like “we got around to it.”

That expectation gap matters because it changes how a slow alert gets interpreted. A fast alert reads as attentiveness. A slow one does not read as neutral, it reads as the store not really being on top of its own inventory, which is a strange thing for a stockout recovery message to communicate. The message is supposed to fix the trust dent from the original stockout. A late send re-opens it.

How to audit your current app’s send latency

Most merchants have never actually measured this gap. It is checkable in about ten minutes if you know where to look.

Pick a recent restock. Find a product that sold out and came back in the last month, ideally one with a real subscriber list attached, not a test SKU.

Find the inventory update timestamp. In Shopify admin, check the inventory history for that variant, or check your fulfillment or purchase order timestamp if the restock was a manual stock update. This is the moment the item became available.

Find the actual send timestamp for individual subscribers. This is the harder part, and it is the real test. Your back in stock app should be able to show you, per subscriber, when their specific alert was queued and when it was actually sent, not just a general “campaign sent” timestamp for the whole batch. If your app only shows a single send time for the entire notification job, you cannot tell whether subscriber one thousand got the email six minutes after subscriber one, or six hours after.

Calculate the gap, on both ends. Compare the inventory timestamp to the first send and to the last send in that batch. The first number tells you about detection speed: how long between “back in stock” and “the app noticed.” The second tells you about pacing: how spread out the batch was, and whether the tail end of your list is getting notified so late that pacing has quietly become a synonym for slow.

Ask what happens at your actual volume. A ten-person waitlist and a five-thousand-person waitlist are different problems. Ask your provider directly what batch size triggers pacing, and how long a five-thousand-subscriber restock takes from first send to last. A specific, timestamped answer is a good sign. A vague one (“it goes out right away”) is not evidence either way, but it is worth a more specific follow-up.

A practical checklist

• Confirm your app logs a timestamp for inventory update and a separate timestamp for each individual send, not just one send time for the whole batch.
• Test one real restock end to end and measure the gap between “item available” and “first subscriber notified.”
• For list sizes in the thousands, ask what pacing mechanism exists and how long the full batch takes from first send to last.
• Check whether your sending domain has enough volume history that a restock-sized burst will not look anomalous to a receiving mail server.
• Review, at least once, one specific customer’s actual delivery record: queued, sent, delivered, opened. If you cannot produce that record on request, you cannot audit your own timing.
• Revisit this after any app migration. Sending infrastructure and detection logic both reset when you switch providers, and latency is one of the first things to quietly get worse.

Where Kelso fits

Kelso paces restock notifications in controlled batches rather than firing an entire subscriber list in one instant, and every send carries an audit log entry with the actual timestamps, from inventory update to individual delivery, so you can see your own latency instead of estimating it. That is the whole audit above, already logged, rather than something you have to reconstruct after the fact. See pricing for how that is packaged.

The short version

The email either arrives while the customer still wants the product, or it does not, and there is very little in between. Getting that right means treating detection speed and send pacing as two separate problems, not one, because fixing only one of them just trades a slow-alert problem for a spam-folder problem. Measure your own gap, on a real restock, before assuming either one is fine.