Back-in-Stock Alerts

An out-of-stock page is the most honest demand signal a retailer ever receives. Somebody wanted the thing badly enough to find it, pick a size, and get all the way to the point of buying. Then the page said no, and almost every retailer responds by doing nothing with that information. The visitor leaves, buys it somewhere else or forgets about it, and the retailer never learns that twelve people wanted that line in that size last month. The demand existed, was measured by nobody, and vanished.

Where a notify-me box does exist, it is usually a dead end: an email address dropped into a list, a single notification sent whenever someone eventually remembers to trigger it, and no sense of urgency in the message. By the time the alert goes out, the restock has often already sold through to walk-in traffic or to customers browsing the site that morning, so the person who asked first gets told last. That is worse than not having a waitlist, because you have now promised something and failed to deliver it. The second failure is volume blindness: with no record of how many people are waiting per variant, buying decisions get made on gut feel. You reorder what the buyer likes rather than what the waitlist proves people are asking for.

There is also a margin opportunity sitting unused. A back-in-stock alert is one of the highest-intent messages in retail - the recipient has already decided to buy - and it almost never needs a discount to convert. Yet many retailers either send it late, send it to everyone at once so the fastest clicker wins and everyone else gets a second disappointment, or bundle it into a general newsletter where it competes with nine other things. This build turns the out-of-stock moment into a captured, scored, queued and converted demand pipeline, with alerts that go out in priority order within minutes of stock landing, and a reservation window that means the person who waited actually gets the item.

Pipeline and stages

One pipeline, Stock Waitlist, with one opportunity per waitlist request - not per contact, because the same person may be waiting on three different variants and each needs its own state.

• Waiting - No ETA - request captured, no restock date known. The default and usually the largest stage.
• Waiting - ETA Known - a confirmed delivery date exists and has been communicated.
• Restocked - Alert Sent - stock has landed and the alert has gone out.
• Reserved - the customer clicked through and a hold has been placed for the reservation window.
• Converted - purchased. Closed won.
• Alerted - No Action - the alert went out, the window expired, nothing happened. Closed lost, but worth a different follow-up to the never-alerted.
• Discontinued - Alternative Offered - the line is not coming back and the customer has been told honestly, with substitutes.
• Withdrawn - the customer canceled the request or bought elsewhere.

Calendars

• Expected Delivery Dates - an internal calendar of inbound deliveries by supplier, used to populate ETAs and to schedule the pre-arrival warm-up messages.
• In-store Reservation Hold - where the reservation is physical, a calendar holding the collection window so the shop floor knows how long to keep the item aside.
• Drop Event Slots - for limited restocks of high-demand lines, bookable collection or shopping slots that remove the first-click-wins scramble entirely.

Custom fields

These sit on the opportunity, not the contact, because the unit of this build is a request for a variant.

• Requested SKU - the variant identifier, exact. This is the join key for the whole build and the one field you cannot afford to be loose about.
• Requested Product Name - the human-readable version for message copy.
• Requested Size and Requested Color - separated out so demand reporting can show that it is the size 10 that keeps selling out, not the line.
• Request Date - the queue position basis.
• Queue Position - calculated, and used in copy where you are confident in it.
• Intent Score - a number built from how the request arrived, prior purchase history, and whether the contact re-checked the page. Determines alert wave.
• Preferred Alert Channel - SMS, email or both. Asked for explicitly on the form, because this is the one message people genuinely want texted.
• Expected Restock Date - populated when known, cleared when it slips.
• Restock Quantity - how many units landed, which drives how many people get alerted in wave one.
• Alert Sent Timestamp and Alert Count.
• Reservation Expiry - the end of the hold window, usually measured in hours not days.
• Substitute SKU Offered - what was suggested if the line died.
• Waitlist Source - product page, BO conversation, in-store staff entry, or social inquiry.

Tags

• bis-waiting - active request. Removed on every terminal outcome.
• bis-alerted, bis-converted, bis-expired.
• bis-high-intent - Intent Score above threshold, alerted in wave one.
• bis-repeat-waiter - three or more waitlist requests ever. These are your most engaged customers and most retailers have no idea who they are.
• bis-sms-preferred, bis-email-only.
• bis-discontinued-notified - prevents a contact ever being alerted about a dead line twice.
• bis-sku-{identifier} - one per high-demand SKU, which makes a restock broadcast a one-click audience selection instead of a query.
• bis-never-converts - three alerts, no purchase. Deprioritised in future waves so genuine buyers are not behind them in the queue.

Forms

• Notify Me - the core capture, embedded on the out-of-stock product page. Four fields only: email, mobile, Preferred Alert Channel, and a one-tap urgency question ("need it soon" or "just curious"). The urgency answer feeds Intent Score and costs the customer nothing.
• Size and Alternative Capture - a second step offering a notification on an adjacent size or color too, which frequently converts the request into an immediate sale of something already in stock.
• Still Interested? - sent at 30 and 60 days of waiting. One tap, yes or no. The single best tool for keeping a waitlist honest.
• In-store Waitlist Entry - staff-facing form so a request taken at the counter enters the same pipeline as a web request. Without this, half your demand data is missing.
• Reservation Confirmation - how a customer claims a hold from the alert, writing Reservation Expiry and creating the shop floor task.

BO's role and guardrails

• In scope: taking a waitlist request conversationally from chat, SMS or social DM when a customer asks about something unavailable; stating the Expected Restock Date only when the field is populated; confirming queue position where you have chosen to expose it; offering in-stock alternatives from the same category; and canceling a request on request.
• Out of scope and escalated: committing to a restock date that is not in the field, holding stock outside the reservation workflow, price questions on unreleased or restocked lines, and bulk or trade quantities, which belong in the wholesale route.
• Guardrails: BO never says "soon", "shortly" or "next week" about stock. If Expected Restock Date is empty, BO says plainly: "I do not have a date for that one yet - I will make sure you are alerted the moment it lands." BO never promises a unit to a specific person, never states remaining stock counts, and never offers a discount for waiting.

Numbers and channels

• SMS is the primary alert channel, and this is the build where it genuinely outperforms email - a restock alert is time-critical and SMS is read in minutes. Provision a number with the volume headroom for burst sending, because a restock on a popular line fires hundreds of messages in one window.
• Email as the secondary and as the detail carrier, with the product image, the size, and the reservation link.
• The product page widget as the main capture surface, plus the chat widget so BO can take requests from people who ask rather than scroll.
• Social DM inbound routed to the same conversation thread, since "when is this back?" is one of the most common messages any retail social account receives.
• Internal Slack or channel notification to the buying team when a SKU crosses a waitlist volume threshold - the whole reason the demand data is worth capturing.

1. A shopper lands on a product page for a jacket in size medium. It is out of stock. Instead of a greyed-out button she sees a Notify Me block: email, mobile, channel preference, and one tap for "need it soon" or "just curious". She picks SMS and "need it soon".
2. On submission the platform creates or matches the contact and creates an opportunity in Stock Waitlist at Waiting - No ETA, writing Requested SKU, Requested Product Name, Requested Size, Request Date, Preferred Alert Channel and Waitlist Source as product page. Tags bis-waiting, bis-sms-preferred and bis-sku-jacket-m are applied.
3. The scoring step runs immediately. "Need it soon" plus a prior purchase history gives a high Intent Score, so bis-high-intent is applied. She is now in wave one for this SKU.
4. She gets an instant confirmation SMS: "{{Business name}}: you are on the list for {{Requested Product Name}} in {{Requested Size}}. We will text you the moment it lands - usually within minutes of it hitting the system." Setting the expectation that the alert is fast is what stops her signing up at three competitors.
5. The follow-up step offers alternatives: an email with the same jacket in the two adjacent sizes and the other colourway, both in stock. This is the quiet revenue step - a meaningful share of waitlist requests are satisfied by something you already have, if you bother to show it.
6. Three weeks pass with no delivery date. At day 30 the Still Interested? form goes out - one tap. She taps yes, which refreshes Request Date relevance and keeps her in the queue. Had she tapped no, or not responded by day 45, the request would move to Withdrawn and stop distorting the demand numbers.
7. The buyer places a reorder. The Expected Delivery Dates calendar is updated and Expected Restock Date is populated on every open opportunity for that SKU. All of them move to Waiting - ETA Known and get a short message: "Good news - {{Requested Product Name}} in {{Requested Size}} is due back around {{Expected Restock Date}}. You are on the list."
8. Two days before the expected date, the warm-up message goes out: "Arriving Thursday. We will text you the moment it is live, and you will have a few hours' head start before we announce it." Priority framing, no discount, no exaggeration.
9. Stock lands. The inventory webhook fires with the SKU and quantity. Restock Quantity is written to every matching opportunity, and the alert workflow calculates wave sizes: if 20 units landed and 60 people are waiting, wave one goes to the top 20 by Intent Score and Request Date, not to all 60 at once.
10. Within minutes she receives the alert SMS with a direct add-to-basket link and the reservation offer. She taps it, which submits Reservation Confirmation, moves the opportunity to Reserved, sets Reservation Expiry for the agreed hold window, and - for an in-store hold - creates the shop floor task to put the item aside.
11. She checks out 40 minutes later. The order webhook matches the SKU to her reserved opportunity, moves it to Converted, applies bis-converted, removes bis-waiting, and cancels every remaining step in the alert sequence so she is never texted about a jacket she now owns.
12. Her reservation and purchase free up the queue math. The wave-two workflow fires 90 minutes after wave one for the next tranche, sized by unsold remaining stock. Everyone in waves two and three gets a real chance rather than a race they already lost.
13. Three people in wave three do not act before Reservation Expiry. Their holds release, their opportunities move to Alerted - No Action, and they receive one honest closing message rather than silence. Any contact now carrying three alerts with no purchase gets bis-never-converts and drops to the back of future waves.
14. A different line is discontinued. The discontinuation workflow moves every open opportunity for that SKU to Discontinued - Alternative Offered, sends a straight message saying it is not coming back, offers two named substitutes written into Substitute SKU Offered, and applies bis-discontinued-notified so nobody is ever strung along on a dead SKU again.
15. Every Monday the buying team gets the waitlist demand report: open requests by SKU, by size and by color, requests that converted when restocked, and requests that aged out. Any SKU crossing the volume threshold also fires a real-time Slack alert during the week. Buying decisions start referencing the waitlist, which is where this build pays for itself twice.

1. Waitlist capture and intent scoring

Trigger: Notify Me form submitted, In-store Waitlist Entry submitted, or BO captures a request in conversation.

Conditions: Requested SKU must be present and must match a known variant. If it does not match, create an internal task for the merchandising team and still capture the contact - a mismatched SKU is a data problem, not a reason to lose the demand.

• Create or match the contact on email then mobile. Create the opportunity in Stock Waitlist at Waiting - No ETA.
• Write Requested SKU, Requested Product Name, Requested Size, Requested Color, Request Date, Preferred Alert Channel and Waitlist Source. Apply bis-waiting and bis-sku-{identifier}.
• Score intent: urgency answer of "need it soon" scores highest, prior purchase of the same category adds, prior purchase of the exact line adds more, a repeat visit to the same out-of-stock page adds, and an existing bis-never-converts tag subtracts. Write Intent Score and apply bis-high-intent above threshold.
• De-duplicate: if an open opportunity already exists for this contact and SKU, do not create a second one. Refresh Request Date relevance, raise Intent Score for the repeat ask, and exit.
• Send confirmation on the preferred channel within 60 seconds. SMS: "{{Business name}}: you are on the list for {{Requested Product Name}}, {{Requested Size}}. We will text you the moment it lands. Reply STOP to leave the list."
• Count the contact's lifetime waitlist requests; at three apply bis-repeat-waiter.
• If open requests for this SKU cross the volume threshold, post to the buying team's Slack channel: "{{open count}} people now waiting on {{Requested SKU}}."

Stop conditions: duplicate request exits early; a contact carrying a global opt-out is captured on email only, never SMS.

2. Alternatives offer - convert the demand you can satisfy now

Trigger: opportunity created in Waiting - No ETA.

Conditions: at least one in-stock variant exists in the adjacent size or another color of the same line. If nothing comparable is in stock, skip this workflow entirely rather than sending an empty email.

• Wait 20 minutes - long enough not to feel like an upsell reflex, short enough to catch the same browsing session.
• Send email: "While you wait - {{Requested Product Name}} in stock now". Show the adjacent sizes and alternate colourways with images, prices pulled from the product feed, and a line that is honest about what it is: "Not quite what you asked for, but these are available today. Your alert for {{Requested Size}} stays active either way."
• Offer a second waitlist opt-in for the alternate colourway in one tap, via Size and Alternative Capture.
• Wait 48 hours. If the email was opened but nothing clicked, and the contact prefers SMS, send one message only: "{{Business name}}: the {{alternate color}} is in stock in your size if you do not want to wait: {{link}}"

Stop conditions: purchase of any variant of the line; request withdrawn; Expected Restock Date populated inside 48 hours, in which case the ETA message is the better next touch.

3. ETA known and pre-arrival warm-up

Trigger: Expected Restock Date populated or changed on a SKU.

Conditions: applies to every open opportunity for that SKU in Waiting - No ETA or Waiting - ETA Known.

• Move matching opportunities to Waiting - ETA Known.
• Send one message on the preferred channel: "Good news - {{Requested Product Name}} in {{Requested Size}} is due back around {{Expected Restock Date}}. You are on the list and we will alert you the moment it is live." Use "around" deliberately; a date given as a promise becomes a complaint when the delivery slips.
• Wait until 2 days before Expected Restock Date, then send the warm-up: "Arriving {{day}}. You will hear from us before we announce it publicly."
• Date slip branch: if Expected Restock Date moves later by more than 3 days, send a single honest update - "Our delivery has moved to {{new date}}. Sorry - you are still first in line." - and reset the warm-up timer. Do not send a slip notice more than twice for the same request; after that, go quiet until stock actually lands.
• Date cleared branch: if the date is cleared with no new one, move back to Waiting - No ETA and send nothing. Silence is better than a third apology.

Stop conditions: restock event fires, which hands over to workflow 4; request withdrawn; line discontinued, which hands to workflow 7.

4. Restock alert - wave one

Trigger: inventory webhook reports available quantity for a SKU moving from zero to above your buffer threshold.

Conditions: open opportunities exist for the SKU. Compute wave one size as the lesser of Restock Quantity and the count of waiting requests. Order the queue by Intent Score descending, then Request Date ascending, with bis-never-converts contacts placed last regardless of score.

• Write Restock Quantity and Alert Sent Timestamp to the selected opportunities. Move them to Restocked - Alert Sent. Apply bis-alerted and increment Alert Count.
• Quiet hours check first: if the restock lands outside the sending window, hold the whole wave until the window opens. A 05:00 alert wins no sales and loses subscribers.
• Send SMS to SMS-preferred contacts: "{{Business name}}: {{Requested Product Name}} in {{Requested Size}} is back. Yours to claim for the next {{hold window}}: {{direct basket link}}"
• Send email in parallel to all alerted contacts, carrying the product image, the exact variant, the reservation link and the expiry time stated plainly.
• Set Reservation Expiry on each alerted opportunity at the end of the hold window.
• Notify the shop floor channel with the count alerted and the hold window, so counter staff know a rush is coming and why.

Stop conditions: stock sells out before the wave completes, which halts remaining sends and routes those contacts back to Waiting - No ETA with no message - being re-queued silently is better than being alerted about nothing; contact opted out; request withdrawn.

5. Waves two and three, and queue release

Trigger: 90 minutes after wave one completes.

Conditions: remaining available quantity is above the buffer and unalerted open requests exist for the SKU.

• Recompute available stock from the live inventory field, not from the figure captured at wave one. This recomputation is the step that prevents overselling a hold.
• Select wave two by the same ordering, sized to current availability. Send the same alert copy.
• Wait 4 hours, recompute, and run wave three if stock remains.
• After wave three, if stock still remains, release the SKU to general availability: notify the marketing team that the waitlist is cleared and the line can be promoted publicly. Never promote publicly while people are still waiting on an alert - that is the failure the whole build exists to prevent.
• Reservation expiry sweep, running every 15 minutes: any opportunity in Reserved past Reservation Expiry releases the hold, moves to Alerted - No Action, closes the shop floor task, and returns the unit to available stock, which can itself trigger a further wave.

Stop conditions: stock exhausted; all open requests alerted; SKU marked discontinued mid-sequence.

6. Reservation claim and conversion

Trigger: Reservation Confirmation submitted, or the alert link is clicked through to basket.

Conditions: the opportunity is in Restocked - Alert Sent and Reservation Expiry has not passed.

• Move to Reserved. Confirm by the preferred channel: "Held for you until {{Reservation Expiry}}. {{collection or checkout instruction}}"
• For an in-store hold, create the shop floor task with the SKU, size, customer name and expiry, and add the hold to the In-store Reservation Hold calendar.
• Wait until 2 hours before Reservation Expiry. If no purchase, send one reminder: "Your {{Requested Product Name}} is held for another 2 hours." One reminder only.
• On order webhook matching contact and SKU: move to Converted, apply bis-converted, remove bis-waiting and bis-alerted, and cancel every pending step in workflows 2 through 5 for this opportunity.
• Wait 3 days after fulfillment, then send one short message asking whether the item was worth the wait, with a review link, subject to marketing consent.
• Clear bis-never-converts from the contact on a successful conversion.

Stop conditions: purchase completes the workflow; expiry hands to the sweep in workflow 5; customer cancels, which releases the hold immediately.

7. Discontinued line - honest closure with substitutes

Trigger: SKU marked discontinued in the product feed, or a manual discontinuation action.

Conditions: open opportunities exist for the SKU. Requires at least one named substitute - if merchandising has not supplied one, create a task and hold rather than sending a bare apology.

• Move all open opportunities to Discontinued - Alternative Offered. Write Substitute SKU Offered. Apply bis-discontinued-notified and remove bis-waiting.
• Send email: "{{Requested Product Name}} is not coming back - sorry. Rather than leave you waiting, here are the two closest things we have: {{substitute 1}}, {{substitute 2}}. If neither works, reply and tell me what you were after and I will look properly." The reply invitation routes to BO, then to a human.
• Wait 5 days. If the substitutes email was opened and a substitute page was visited but nothing bought, create a task for a staff member to follow up personally on lines above your value threshold.
• Add the contact to a low-frequency "similar new arrivals" segment for that category, with consent.

Stop conditions: substitute purchased; contact unsubscribes; bis-discontinued-notified blocks any repeat notification for the same SKU forever.

8. Waitlist hygiene and still-interested checks

Trigger: opportunity has been in a Waiting stage for 30 days.

Conditions: no restock event in that period. Skip contacts alerted in the last 14 days.

• Send Still Interested? - one question, two buttons. "Still want {{Requested Product Name}} in {{Requested Size}}? Yes, keep me on the list / No, remove me."
• Yes branch: refresh Request Date relevance, add a small Intent Score increment for confirmed patience, and re-enter the 30-day timer.
• No branch: move to Withdrawn, remove bis-waiting, and confirm in one line. Do not attempt to retain them.
• No response branch: wait 15 days, send one reminder, then at day 60 total move to Withdrawn with a note recording "aged out, unconfirmed". Keep aged-out requests separate from active ones in all demand reporting, or you will reorder against demand that no longer exists.
• Weekly, compile the buying report: open requests by SKU, size and color; confirmed versus unconfirmed; conversion rate of previously restocked SKUs; and requests aged out without a restock. Send it to the buying team and the owner every Monday morning.

Stop conditions: restock event takes precedence over any hygiene step in flight; purchase of the SKU through any channel closes the request as Converted.

9. BO stock inquiry handler

Trigger: inbound chat, SMS or social DM containing an availability intent - "do you have", "when is this back", "is this in stock".

Branches:

• Item is in stock: BO confirms and sends the product link. No waitlist created.
• Item is out of stock, no ETA: BO offers the waitlist, takes size and channel preference conversationally, and creates the request through workflow 1 with Waitlist Source set to BO conversation. BO says "I do not have a date for that one yet" and nothing more optimistic.
• Item is out of stock, ETA known: BO states the date from Expected Restock Date with the word "around", then offers the waitlist.
• Already on the list: BO confirms the existing request and, where you have chosen to expose it, the queue position. BO does not create a duplicate.
• Discontinued: BO says so plainly and offers the substitutes from the product data.
• Asks to be held a unit, asks for a discount for waiting, or asks for trade quantities: escalate. BO replies "Let me get someone to confirm that for you" and assigns the conversation.

Stop conditions: BO stands down once a human replies; BO never sends a second unprompted message in the same thread about the same SKU.

Before this build, an out-of-stock page is a dead end and the demand behind it is invisible. After it, the out-of-stock page is a capture surface, the demand is counted per variant, and the restock is a sequenced, priority-ordered conversion event rather than a free-for-all. The person who asked first actually gets the item, which is the whole promise of a waitlist and the part most retailers break.

Two things change commercially. First, revenue that used to leak to competitors is recovered at full margin, because a restock alert converts on intent rather than on discount. Second, the buying team gets a demand signal they have never had: not what sold, which only tells you what you had, but what people asked for and could not get. That changes reorder quantities, size curves and range decisions, and it is usually the finding that surprises the client most.

Measure these weekly, by SKU and in aggregate:

• Waitlist capture rate - Notify Me submissions as a share of out-of-stock product page views. If this is low, the widget is badly placed, not the demand absent.
• Alert-to-conversion rate, split by wave. Wave one should convert hardest; if it does not, your Intent Score is scoring the wrong things.
• Time from restock webhook to first alert sent - target minutes. Every hour of delay transfers the sale to whoever is faster.
• Reservation claim rate and expiry rate - how many holds are claimed versus released. A high expiry rate means the window is too long or the alert is reaching people who were only browsing.
• Open requests by SKU, size and color - the buying report. The size curve this reveals is frequently different from the sales-based one.
• Alternative conversion - revenue from the adjacent-size and other-color follow-up. Pure upside that did not exist before.
• Waitlist age and withdrawal rate - how long requests sit and how many are cleaned out by the Still Interested check. An unpruned waitlist produces confident, wrong buying decisions.
• Repeat waiter count - contacts carrying bis-repeat-waiter, a high-intent audience worth its own treatment.
• Discontinued notification follow-through - substitute acceptance rate, which tells you whether your substitutions are credible.

Inventory data - the make-or-break prerequisite

• A live inventory feed at variant level, not product level, pushing stock changes into the platform by webhook. Shopify, WooCommerce, BigCommerce and most modern commerce platforms emit inventory events; older EPOS systems often need Zapier, Make or a middleware layer. Polling on a schedule works but adds latency, and in this build latency is the whole problem.
• SKU consistency between the website, the stock system and anything staff type in store. A waitlist keyed on a SKU that does not match the inventory event never fires. Audit this before you build anything else - it is the single most common failure point.
• Agreement on what "in stock" means. Stock allocated to another channel, or physically in a delivery not yet goods-received, will fire premature alerts and burn customer trust. Define the threshold and the buffer explicitly.
• A decision on reservation mechanics. Can you actually hold a unit, for how long, and who enforces it? A reservation you cannot honor is worse than no reservation at all.
• A discontinuation feed or at least a manual process, so dead lines are closed rather than left waiting forever.

Integrations

• Commerce platform or EPOS for inventory and order events.
• Product data for images, names and variant attributes used in message copy.
• Slack or an equivalent channel for buyer alerts on volume thresholds.
• Google Calendar or similar for the expected-delivery and reservation calendars.
• Zapier or Make where a direct webhook is not available.

Numbers and messaging compliance

• Provision SMS with real burst capacity. A restock on a popular line can fire several hundred messages inside a few minutes, and a throttled number delays exactly the message that cannot afford delay. Discuss expected peak volume with your provider before launch.
• Complete A2P 10DLC registration in the United States before launch, and register the use case accurately. A back-in-stock alert is arguably transactional in intent but carriers often treat it as marketing, so register conservatively and expect scrutiny. Confirm equivalent requirements in other markets.
• Collect explicit consent for the alert channel on the Notify Me form, with clear wording that the number will be used to send a stock alert. Keep that consent distinct from general marketing consent - a customer who wants one text about a jacket has not signed up for your newsletter, and treating the waitlist as a list-building exercise is the fastest way to destroy its performance.
• Opt-out handling on every message: STOP, UNSUBSCRIBE and STOPALL honoured immediately and globally. A waitlist opt-out should cancel the open requests too, not just suppress the sending, so you are not holding stock for someone who has left.
• Quiet hours require a deliberate decision here, because stock often lands overnight and the commercial temptation is to alert at 04:00. Hold alerts to a sending window, and if a restock is genuinely scarce, use Drop Event Slots and announce the window in advance rather than texting people in the middle of the night.
• Cap Alert Count per request. Two alerts and one closing message is enough; more reads as nagging about something the customer may no longer want.

Data protection

• You are collecting a cell number for a single stated purpose. Use it for that purpose. Repurposing waitlist numbers for promotional campaigns without separate consent is both a compliance exposure and a reputational one.
• Set a retention period for closed waitlist requests. Converted and withdrawn requests have analytical value in aggregate; the identifiable record does not need to live forever.
• Requested sizes can be personal information in context. Keep the field for operational use and out of anything customer-facing beyond the person's own messages.
• These are operational pointers, not legal advice. Confirm consent wording, lawful basis and retention periods with the client's own counsel or data protection adviser before launch.

People and sequencing

• Someone must own Expected Restock Date. An empty field is honest and workable; a stale wrong one is corrosive, because every message built on it is a broken promise.
• Brief the shop floor on the in-store waitlist form and on honouring reservations. A hold the system promised and the counter ignores is the worst possible outcome.
• Build in this order: capture form, confirmation message, inventory webhook and alert, then waves, then reservations, then the demand report. Resist building the reporting first - it is the most interesting part and the least useful until the data is flowing.
• Inventory architecture and reservation policy vary enormously between retailers and are where scoping effort belongs. Book a call at bookings.appbo.io to work through yours.