"When will this be back in stock?" is the most answerable question your support inbox receives and the one that consumes the most time, because the answer is usually "we don't know yet" and that answer has to be typed by a person. A back-in-stock widget removes most of that volume, but not all of it, and the part it leaves behind is worth understanding before you measure the result.
The four tickets a sold-out product generates
They look like one question and they are not:
- Will it come back at all? The customer wants to know whether to wait or to go elsewhere.
- When? They want a date, usually because they need it by a date.
- Can I reserve one? They do not trust that they will get one when it does return.
- Is there something else like it? They want the outcome, not that specific SKU.
A notify-me widget answers the first completely and the third mostly — the queue is the reservation, if you notify in order. It does not answer the second and it does not answer the fourth. Plan for those two to remain.
What the widget replaces
Before it exists, a customer who wants a restock has to find your contact page, write a message, and remember to come back. Most of them do not — they leave, and the ticket you never received is a sale you never made. The tickets you do receive are the persistent minority.
So the first effect of adding the widget is not only fewer tickets. It is that a much larger number of people who would have quietly left now stay on a list you can act on. The support saving is real; the demand capture is the larger number and the easier one to justify internally.
Making the widget answer more than "we'll tell you"
A bare email field answers the weakest version of the question. Three additions do most of the remaining work:
Say what happens next, on the widget
"We'll email you the moment this is back, and you'll have first claim in the order you joined" answers "will it come back" and "can I reserve one" in a single sentence, at the exact moment the customer was about to open a support chat. If you notify in waves rather than all at once, say so — the sentence is still short and it stops the follow-up.
Show an expected date when you genuinely have one
If a purchase order has a confirmed arrival, put the month on the page. If it does not, do not invent one. A wrong restock date does not reduce tickets; it moves them to a week later and adds a complaint, because someone planned around it.
"We don't have a date yet — join the list and you'll know the same day we do" is a better answer than a guess, and it is one customers accept.
Show the waitlist size where it helps
"84 people waiting" answers the reservation question honestly, tells the customer the product is worth waiting for, and quietly sets expectations about a scramble. It backfires on slow products where the number is 2, so make it appear only above a threshold.
The tickets you still get, and how to make them cheap
Date requests and substitution requests survive. Both are worth a saved reply rather than a fresh answer each time.
For dates: one macro that says what you know, what you do not, and points at the widget. For substitutions: a macro per product family, with two or three named alternatives. That second one is the higher-value macro, because a customer asking for an alternative is ready to buy today.
Tag both categories in your helpdesk. You need the tags for the measurement below and they cost nothing to add.
The restock itself creates tickets if you get it wrong
Two patterns reliably generate a fresh wave of contacts on the day stock lands:
Notifying everyone about a small restock. If four hundred people are told and thirty units exist, the three hundred and seventy who arrive at a sold-out page write to you, and they write annoyed, because you invited them. This single decision can produce more tickets in a morning than the widget saved in a month. Size the notification to the stock.
Restocking without notifying. Inventory goes up, the product quietly becomes available, the list is never told, and then someone on it notices in a collection page and asks why they did not hear. Whatever tool you use should fire on the inventory change itself rather than on someone remembering to press a button.
Where the widget has to be for any of this to work
A notify-me form that only exists on the product page misses the customers who never reach one. Someone scanning a collection page sees a greyed-out tile, forms the question, and leaves without ever loading the product. If your app can put the trigger on collection tiles and in search results, that is where a meaningful share of the signups come from.
The other placement worth checking is the variant level. A product page that is "in stock" because three of five sizes are available will not show a sold-out state at all, and the customer who wants the size that is gone has nowhere to leave an address. That customer writes to support instead, and they are the most frustrated version of this ticket, because from the outside it looks like you are simply ignoring one size.
Measuring it without fooling yourself
Ticket volume moves for a dozen reasons — seasonality, a campaign, a shipping delay. To see this effect specifically:
- Tag restock tickets for a month before you install anything. Without a baseline you will be comparing a number to a feeling.
- Count as a share of orders, not in absolute terms. Tickets per hundred orders removes growth from the comparison.
- Split the tag into "will it return / when" and "alternatives". The first should fall sharply. The second should not fall much, and if you treat them as one number you will conclude the widget underperformed.
- Watch the day after each restock. A spike there is a send-sizing problem, not a widget problem, and it is fixable.
- Count what the list captured. Subscribers per sold-out product per month is the number that justifies the tool; the ticket reduction is the one that pays for the support team's attention.
What automation does not fix
A customer who needs the item by Friday for a specific reason is not helped by joining a queue, and sending them into one reads as a brush-off. That conversation needs a person — to check another location's stock, to suggest the closest alternative, or to say plainly that it will not arrive in time so they can go elsewhere without wasting three more days.
The point of removing the repetitive question is that those conversations get answered properly, by someone who is not working through forty identical messages first.
Where to go next
Stok fires on the inventory change rather than on a manual send, and supports notifying in waves so a small restock does not create the ticket spike described above. For sizing that send, see more people waiting than stock. If your restock dates are genuinely unknown, alerts or preorders covers which instrument fits.
