Restock Bell

A sold-out product page is the most expensive dead end in a store. The shopper found the product, picked the variant, and decided to buy it. Everything the store paid to bring them there worked, and the page has nothing left to offer but a greyed-out button.

The problem this solves

Most of that demand is not lost because the shopper changed their mind. It is lost because nobody wrote it down. They leave, the variant comes back on Thursday, and nothing connects the two events. By the time they remember the product, they have bought something else.

A back-in-stock alert is the smallest piece of software that keeps that demand: ask for an email, remember which variant it was for, and send one message when it can be bought again. The idea is simple. The edges are where most implementations go wrong, and they are what this page is mostly about.

What the first release does

The merchant adds a “Notify me” block to the product template in the theme editor. The block watches the variant the shopper has selected. While that variant is sold out, it shows an email field and a button; when the shopper switches to a variant that is in stock, the form disappears. There is nothing to configure per product.

The form posts through Shopify’s app proxy, and the app refuses any request that does not carry Shopify’s proxy signature. It stores the email address, lowercased, against the specific variant, with the product and variant titles so the eventual email can say what came back.

When stock changes, Shopify sends an inventory_levels/update webhook. The app looks up the variant behind that inventory item and asks one more question before emailing anyone: is the variant actually sellable online? A warehouse can receive stock that the online store still shows as sold out. Emailing someone to come and buy a product they still cannot buy is worse than not emailing them at all, so the app waits until Shopify says yes.

Then it emails every shopper waiting for that variant, with a link straight to it.

Requests are per variant, and repeats merge

A shopper who wants the medium in green does not want an email about the small in blue. Requests are stored per variant, and the link in the email opens the product page with that variant selected.

Shoppers also press buttons more than once. The app holds one pending request per store, email address and variant, enforced by a unique key in the database. A second submission is accepted politely and merged into the first, so the shopper sees the same confirmation and the merchant’s list does not fill with duplicates.

Why each email is claimed before it is sent

Shopify delivers webhooks at least once, which means sometimes twice. A restock that arrives twice must not send two emails.

The app guards against this at three points. The background queue drops an event whose webhook ID it has already processed. Each request is switched from waiting to emailed in the database before its email goes out, so a second run finds nothing left to send. And within one run, an address receives one email even if it somehow appears twice.

If sending fails, the claim is released and the job retried, so a temporary email outage delays the alert rather than losing it. The trade-off is stated plainly in the app’s own design notes: if the process stops in the narrow moment after the claim and before the send, that one email is not retried. Sending a duplicate was judged the worse failure.

Knowing whether it worked

An alert that nobody measures is a guess. When a new order arrives, the app checks its email address and its items against the requests it has emailed in the last 30 days. A match marks the request as bought and records the order ID.

The dashboard shows the result as four figures: requests waiting, requests emailed, requests bought, and the conversion rate from emailed to bought. The stock requests list shows every request with its status, so a merchant can see which products people are waiting for before the stock arrives — which is useful information about what to reorder, quite apart from the emails.

The match is deliberately narrow. It counts a purchase only when it is the same email address buying the same variant after being told it was back. That undercounts — a shopper who checks out with a different address is missed — but an undercount is the honest direction for a number that is meant to justify keeping the app installed.

What it does not do yet

• The restock email is written in English only, whatever language the store sells in. It is the one email the shopper asked for, and its footer says so; there is nothing left to unsubscribe from once it is sent.
• Every waiting shopper is emailed at once, however few units came back. A restock of two units with forty people waiting will disappoint most of them; pacing alerts to stock is not built.
• There is no rate limit and no CAPTCHA on the form. The proxy signature stops requests that did not come through the store, and repeats merge, but a determined script on the storefront could still add addresses.
• The settings page has toggles for email notifications and a digest. Neither sends anything yet.
• It has been built and tested against a simulated Shopify, not yet against a live store, and it is not listed on the App Store.

How to judge a back-in-stock app

Five questions are worth asking of any app in this category:

1. Does it email when the stock arrives, or when the product can actually be bought online? Those are different moments, and only one of them is useful to the shopper.
2. Can a repeated webhook send a second email? Ask how it knows it has already sent one.
3. Is a request tied to the variant, or only to the product?
4. How does it decide that an alert led to a sale? A generous match makes a better-looking dashboard and a worse decision.
5. What does it keep about the shopper, and when does it delete it? An email address and a variant are all the job needs.