Back to Blog

Many Back-in-Stock Requests, Few Sales: Which Points Should You Check?

Back-in-stock requests not turning into orders? Check variants that never return, waiting time, units versus waitlist, price changes and the product page.

Pushouse14 min read
Three chat bubbles with bell, product box and shopping cart icons
Contents

If your “notify me” requests are not turning into orders, check five points before you touch the message text: whether the size or color customers are waiting for actually comes back, how long they wait for the restock, whether the units that arrive cover the people waiting, whether the price has changed since the request, and which page the link in the notification opens. Each one can be tested with a single check. Count separately the customers who add the product to the cart and then leave; their loss starts in the cart or at checkout.

After working through the checks, you can decide which products to restock first, what to do with requests collected for sizes that will not come back, and what to tell people waiting for a product whose price has changed. When your reports suggest that back-in-stock notifications are not turning into sales, you will also have the measure that shows the real loss: per product and variant, the share of notified customers who order within the next seven days.

Will the size or color customers are waiting for come back?

In Pushouse’s WhatsApp back-in-stock alerts module, a “Notify Me When Available” button appears on the page of a sold-out product. The customer marks the size or color they want and enters a phone number; no membership is required, and they hear back only when that variant is back in stock. Because the request is tied to a variant, the first question is whether that variant will really return. A request left for a discontinued color, a size the supplier will not send again or a one-off seasonal model can never become an order. Unless you separate such requests, the success of your notifications is calculated lower than it really is.

Put every variant with open requests into one of three groups: a known return date, uncertain, and not coming back. Take requests in the third group out of the figure you use to judge notification performance, and keep them on a separate line as demand you cannot meet. If the uncertain group is large, ask your purchasing team the same question for each variant: when will this size or color come back, and under which product record?

The second half of that question matters more than it seems. If you plan to list the same model as a separate product next season, check in your notification tool beforehand whether customers waiting on the old product will hear about the new batch. Where possible, add the new batch as stock to the same variant of the existing product; if you have to create a new product, put a link to it on the old page so that customers who come back on their own can find their way.

Stop collecting requests for a variant that will not return. Remove that size or color from sale on your e-commerce platform, or state on the product page that it will not be produced again; otherwise every new request joins the list as a promise you cannot keep. Offering waiting customers a different product instead turns the notification into a campaign message. Because the Ticari İletişim ve Ticari Elektronik İletiler Hakkında Yönetmelik (Türkiye’s Regulation on Commercial Communication and Commercial Electronic Messages) requires the content of a commercial message to match the consent the customer gave, send such a suggestion only to customers who have given campaign consent, in a separate message.

Measure the time between the request and the restock

On the day they left the request, the customer was ready to buy. The longer the restock takes, the weaker that readiness gets: the day they needed a gift may pass, they may buy the product from another site, or the need may simply go away.

For your own store, put the date each request was left next to the date the requested variant came back in stock. Split requests into three groups by waiting time: under a week, one to four weeks, and over four weeks. In each group, check how many notified customers placed an order. If most requests sit in the longest-waiting group and that group orders clearly less than the others, the loss comes from restocking time, and rewriting the message is unlikely to recover it.

Prioritize restocks by the number waiting and the calendar

To shorten the wait, set your reorder sequence by the number of people waiting. If you can see requests by product and variant, rank sold-out variants by the number waiting and place your first supplier order for those at the top of the list. If you cannot see that number, look at how often sold-out products are searched for on your site; our guide to understanding customer behavior treats those searches as a demand signal.

Take the calendar into account too. Some of the people waiting for sizes that sold out during the 11.11 sales or the late-November sales may be looking for a New Year’s gift. If that size arrives too late for the gift, the list still looks long, but for the gift buyers the moment has already passed. For these products, work backwards from the day the gift will be given to find the latest date the new batch must be on the shelf: subtract the shipping time and a few days for the customer to decide.

Reorder high-demand variants before they sell out

To shorten the wait from the start, reorder high-demand variants before they sell out. Pushouse Inventory Alerts notifies your store team when a product’s stock falls below the threshold you set. Set the threshold slightly above the number of units you expect to sell during your supplier’s lead time. For example, if you sell an average of four units of a product a day and your supplier delivers in ten days, a threshold of fifty units leaves a few days’ margin for the new batch to arrive before the shelf is empty.

Compare the units received with the number of people waiting

If the request list is long and the new batch is small, sales will inevitably look low. With Pushouse, notifications match the available stock: if five units arrive, a message is not sent to all one hundred people waiting. After such a restock, your report will make it look as if back-in-stock notifications are not turning into sales, while the only problem may be the division you are doing.

A hypothetical example: 150 people are waiting for size L of a coat, 12 units arrive at the warehouse and all twelve sell within two days. Orders per request come out at 8%, yet the entire restock has sold. In this example the loss lies in the quantity ordered; changing the message or the page would not bring a single extra order.

Bring the next order quantity closer to the number waiting

For every restock, write two numbers side by side: the units received and the number of people waiting for that variant. Then check how much of the delivery sold in the first days after the notification. If the stock ran out quickly, bring the next purchase quantity closer to the number waiting; we touched on turning a waiting list into order quantities, with an example, in our guide to increasing e-commerce sales. If stock remains and notified customers still do not order, set quantity aside and move on to price and the product page.

Has the price changed since the request?

A customer who left a request may still have the price they saw that day in mind. If a product sold out at a discounted price during a campaign and came back at its normal price after the campaign ended, the waiting customer meets a higher figure on the product page than they expected. The effect is the same if you raised the price because the new batch cost more.

For every variant that comes back in stock, note two prices: the price on the day of the request and on the day the notification went out. Split variants into three groups (price unchanged, increased and decreased) and compare the orders that followed the notification. If the group with higher prices orders clearly less than the others, price explains the loss.

State the current price clearly in the notification

Which price you charge is a commercial decision; this check only shows how that decision affects the people waiting. If you decide before a campaign ends at what price the products that sold out during the sale week will return, you will also know in advance what to tell the people waiting. If you keep the new price, do not let customers see it for the first time on the product page; state the current price in the notification as well.

If the price has dropped, do not turn the notification into a discount announcement. The customer left their number to hear that the product is back; stating the current price is enough. You will find a sample message for a product whose price has changed, and the information a notification that mentions a discount must legally include, in our guide to back-in-stock message text.

A customer who asked for the news may tap the link as soon as they see the notification. If something is wrong with the page in the first few hours, the customers most ready to buy are the ones who run into it. On the day the notification goes out, open the link yourself on a phone and check the following:

  • The link opens the product page directly. If the product was unpublished while it was sold out or its address changed, customers must not land on the home page or an error page.
  • The size or color customers were waiting for can be selected and shows as in stock. If an old version of the page is still cached, customers may see “sold out” even though the stock has arrived.
  • The price on the page matches the price in the notification.
  • The product page shows an estimated delivery date.

Do not leave delivery information as a duration such as “2–4 business days”; turn it into a date. In Baymard Institute’s checkout testing, participants who saw only the shipping speed stopped to work out when their order would arrive; when timing mattered most, this often led to hesitation and even cart abandonment. Baymard recommends showing the estimated delivery date on the product page as well, where possible. For a customer trying to get a New Year’s gift in time, a single line reading “Estimated delivery: 19–21 December” answers the most important question right on the product page.

Base the delivery date on the real dispatch day

Participants read the date a site gave them as a promise, so do not make it optimistic. We explain how to bring your preparation time in line with reality during busy periods, and how to let customers know when a promised day slips, in our guide to keeping customers informed about shipping delays.

Another trap is entering stock into the system before the product can actually be shipped. When a batch that has only just left the supplier is added to stock, the notification goes out, the customer orders, and the parcel leaves days later. Enter stock once the product has reached your warehouse and is ready to ship; if you have to enter it earlier, base the delivery date on the page on the real dispatch day.

Read the notification text on the same phone

Read the message that comes before the link on the same phone. It should contain the store name, the product name, the awaited variant, a single product link and an opt-out line. We explain how to add whatever is missing, with examples, in our guide to writing back-in-stock messages.

Count customers who add to cart and leave as a separate group

A customer who adds the product to the cart shows that the notification and the product page did their job. If they left without completing the order, look first at the cart and checkout for whatever stopped them, and do not count them on the same line as people who never came to the site after the notification. If you can add a source tag (UTM) to the notification link, track the add-to-cart and checkout steps of these visits separately in your analytics tool.

Compare the cart-to-order rate of visitors who came from notifications with the overall rate for your site. If the two are close, there is no problem specific to notified customers; removing general obstacles in the cart and at checkout will help them too, such as an unexpected shipping fee, a total that only appears at the last step or a missing payment option. If the rate is clearly lower for notified visitors, look for a reason specific to these products; the delivery date and price shown in the cart are the first places to look. If the customer has agreed to cart reminders and you have them set up, they take over the unfinished purchase.

Measure every fix with post-notification orders

If you can export your request records, you can run all of these checks from a single spreadsheet. Make each row one request, with the following information:

  • The date of the request, the product, the variant and the price on that day.
  • The date the variant came back in stock and the units received, or a note that it will not come back.
  • Whether the customer was notified, and the price on the day of the notification.
  • Whether the customer ordered the same product within seven days of the notification.

A seven-day window is a reasonable starting point for most stores. A longer window starts counting orders that have nothing to do with the notification; we explain in detail how the counting period changes the result in our guide to reading send, click and sales reports.

Match orders to requests and use the right denominator

Link orders to requests by phone number. A customer who left a request may not have an account and may order with a different email address; the phone number, however, is usually in both records. Before matching, put the numbers into the same format. If a leading 0, a +90 prefix or spaces are not removed, an order from the same person may not match their request.

Once the spreadsheet is filled in, each check becomes a filter. You calculate the same rate in groups split by waiting time, by units received and by price change: the share of notified customers who ordered within seven days. Put only notified customers in the denominator. If requests for variants that will not return and customers still waiting for stock end up in the denominator, the rate does not reflect reality and you will look for the fix in the wrong place.

Test fixes one at a time and revisit the sheet after the season

When you roll out a fix, for example adding a delivery date to the pages of restocked products, compare restocks in the four weeks before and after the fix using this rate. Introduce fixes one at a time; if you change the price and the page in the same week, you cannot tell which one worked. Weeks with November campaigns and New Year shopping behave differently from other weeks; compare them with the same weeks of the previous year, if you have that data.

When the New Year season is over, open the spreadsheet again and see in which group most requests were lost. Start next season’s restocking calendar and product page fixes with that group. Reach us through the contact form if you are thinking of setting up back-in-stock alerts in your own store or finding the spreadsheet’s results hard to read.

Back to Blog