Use waitlist signups to decide what to restock

Waitlist signups are a count of people who asked to be emailed when a sold-out variant returns. They are not orders, and they are not a forecast. In SK Back In Stock, use them as a buying signal beside your supplier minimums, your margin, and the units you can actually receive.

The catalog's recovered-sales figure has one definition. It sums the line-item value of signups that later match an order on the orders-create webhook, and the match is the same email and the same variant. Do not invent a second attribution rule, such as "anyone who opened the email" or "any order from that customer within 14 days." Those rules are not documented.

Signups are demand, not orders

A signup row stores the email, the product, the variant, an alert type, and a status of waiting, notified, purchased, or unsubscribed, plus a consent timestamp. Waiting means the person is still in the queue for a future crossing of your stock threshold. Notified means an alert was sent. Purchased is the later match described above. Unsubscribed means they left the list.

If 40 people are waiting on a navy size medium, you have 40 email requests for that variant. You do not have 40 sales. Some addresses will bounce or fail. Some people will buy elsewhere before you restock. Some will ignore the email. The dashboard's purchased count is the subset that later matches, not the signup total.

The App Store listing says merchants can review which sold-out products have the most signups and the sales attributed to restock alerts. Read "attributed" as the webhook rule above. A match can happen even if the person never opens the message. A purchase of a different size does not count, even if the email brought them back.

What you can see

The admin dashboard's top line shows total signups, alerts sent, and a purchased or recovered count. A configuration table lists each button setup by name, whether it is enabled, its signup count, and the date it was created. The product list shows email, variant, subscribed date, a status badge, and notified date. You can search and filter by status. Variant rows are aggregated up to the product for display, and the variant is still on the row.

  • Signup count: how many people asked for an alert, by configuration and by product or variant.
  • Alerts sent: how many restock emails the queue processed.
  • Delivery rate: sent compared with failed. A failed job retries up to five times, then stays failed.
  • 30-day signup growth: a percentage on the dashboard. It describes the recent change in signups, not next month's revenue.
  • Revenue recovered: the sum of matched line-item values, email plus variant, from orders created.

The catalog does not describe an emailed reorder report. You read these figures in the app. A test email to yourself previews the shopper template. It is not a buying summary. If the admin's theme check says the embed is off, signup counts from that period are not demand. Shoppers could not see the button.

What the match cannot prove

Attribution here is a join, not an experiment. There is no documented holdout group. You cannot claim from this screen alone that the email produced the order, or that a variant with zero signups has zero demand. People who never saw the button, people who will not give an email, and wholesale buyers who email your team directly are invisible to the waitlist.

The recovered value is the order line, not the price printed in the template. The app does not document a separate profit field.

Low-stock alerts use the same crossing idea in the other direction. Do not mix those rows into a back-in-stock reorder conversation without checking the alert type. A low-stock notice is a warning that quantity fell through the threshold. A back-in-stock notice is the upward cross, defaulting to a threshold of 1.

A reorder conversation

Bring the variant list, not a single product total. Sort the waiting rows. For each variant you might reorder, write four notes: signup count, how many alerts already failed, the matched purchased count if you have restocked it before, and the supplier constraint. The supplier constraint is yours. The app does not know the case pack, the lead time, or the cancel date.

An example, not store data: a boot in size 8 has 22 waiting signups, size 9 has 4, and size 11 has 1. Those are different buys even though they share a title. A full size-run minimum still does not mean you should order every size.

Use the 30-day growth figure to see whether requests are new or leftover. A large waiting list on a product you discontinued is not a reorder. It is a reason to unsubscribe those people with an honest note, or to leave the list until you decide. The app will email them if you later cross the threshold on that variant. Do not restock only to empty the queue.

After you do restock, wait until the worker has sent and until orders have had time to match. Then compare alerts sent, delivery failures, and the purchased sum. If almost every send failed, fix mail before you buy deeper. If sends succeeded and almost nobody bought that variant, the waitlist was interest, not a purchase order.

Do not lean on a review count

This article does not quote a public review score or a review count. A review figure is not a reason to trust the dashboard or to ignore it. The definitions above are the ones to use in a buying meeting. Popularity of the app is a separate check you make on the live App Store page the week you decide.

The App Store listing shows the price as Free and lists no paid plans. Neither the listing nor the catalog states a monthly email cap. A reorder process can still use the signup list. Check the live listing for any pricing change, and do not assume you can email every waiting address without a limit.

Questions for buyers

Are signup counts the same as customers?

No. Each row is an email tied to a variant. One person can join two sizes and appear twice. A signup is not a customer order.

Does the app email you a buying report?

The catalog documents an admin dashboard, not a scheduled report to the buyer. Open the signup list and the recovered total there.

Should I reorder the product with the most signups?

Reorder the variant you can receive, at a quantity you can sell, when the waiting list is real and the product is still in the line. The highest product total can hide one size that nobody asked for.

Open SK Back In Stock if you want the variant waitlist described here. Treat the signup list as a buying signal, and keep the revenue line tied to the email-and-variant match.

Work With Us

Have an Idea about project? Let's Connect!

Get In Touch
Let's Work Together