Back In Stock Statamic Laravel Package

Product Decisions This Supports

• Demand capture on out-of-stock SKUs. The package turns "sold out" dead-ends into a waitlist, letting you decide per product whether to notify everyone waiting or only as many as came back. That choice is a genuine merchandising/finance decision: broad demand signal vs. inventory-accurate, first-come-first-served fulfillment.
• Revenue recovery prioritization. Restock notifications are one of the cheapest conversion levers in a catalog. This package makes the metric measurable per product (waitlist size, units committed to waiters, last restock), which is exactly the input needed to argue for reorder budget or supplier expediting on high-waitlist SKUs.
• Build vs. buy. A competent Laravel team can build a waitlist in a sprint, but not the boring correctness parts: double opt-in confirmation, one-email-per-address deduplication under concurrent submits, FIFO queueing against actual restocked quantity, notification delivery that survives a restock happening while emails are sending, and an admin view that doesn't N+1. Buying is defensible if your differentiation is product, not notification plumbing.
• Roadmap sequencing. The package covers email only. If your roadmap includes SMS/push restock alerts, multi-channel preferences, or demand forecasting, treat this as a v1 foundation you may outgrow rather than the end state.
• Operational/CRM decisions. The one-year restock history retention is a support and merchandising asset ("what restocked when, who was told"), but it's also a data-retention decision you must reconcile with your privacy policy and consent records.
• Use cases: limited drops and small-batch restocks where quantity matters, made-to-order-ish catalogs with long stockouts, high-SKU-count stores where per-product waitlist tracking beats manual mailing lists, and any flow where "notify me" currently costs support tickets.

When to Consider This Package

Adopt when:

• You run a Laravel storefront with real stock-out events and a catalog large enough that manual "we're back" emails aren't viable.
• Quantity-aware restock matters — you sell limited units and need "3 came back, 3 longest-waiting people get emailed," not a blast to everyone.
• You want double opt-in confirmations by default; the release notes confirm deduplication (one email per address, concurrent submits collapse to one request) and correct behavior when someone confirms while the item is already in stock.
• You're willing to ship a schema migration (back_in_stock_items gains a column; php artisan migrate required) and accept the package's admin Control Panel as your operations surface.
• Queue infrastructure is optional in your environment — the package sends inline after the product save if no queue is configured, which is convenient early and a scaling consideration later.
• You value the concurrency fixes in v1.0.1 specifically: no lost notifications during an in-flight send, no over-promising inventory, and restock state re-baselined when a product is re-requested after a stock change.

Look elsewhere when:

• You need multi-channel delivery (SMS, push, WhatsApp) or audience segmentation beyond a per-product waitlist.
• Your frontend is decoupled/headless and you require a first-class JSON API rather than Blade forms and an admin panel.
• You need backorder management, pre-orders, or partial-fulfillment allocation logic — this is notification, not order orchestration.
• Your consent or retention model can't accommodate a fixed one-year restock history, or you need configurable/regional retention.
• You're on a non-Laravel PHP stack, or you already own an ESP with native back-in-stock automations and don't need inventory-quantity semantics.
• You need hard throughput guarantees on very large waitlists; without a queue, dispatch is tied to the save request, so validate volume before committing.

Caveats to plan for: v1.0.1 is a correctness-heavy patch on a young 1.x package — the fixes describe real edge cases (double submits, mid-send restocks, stale stock baselines) that were previously wrong. Pin the version, run the migration in staging, and re-test your confirmation and restock flows before rollout.

How to Pitch It (Stakeholders)

To executives: We lose sales every time a popular item sells out and a customer leaves. This package converts that traffic into a permissioned waitlist and automatically emails the right people when stock returns — and "the right people" is now inventory-accurate: if five units come back, we email five waiters, not five hundred. It's a small, low-risk addition to the existing Laravel app rather than a new SaaS contract or a custom build, and it gives us per-product demand data to justify reorder and supplier decisions. Expected value is recovered revenue on our highest-waitlist SKUs plus a measurable drop in "when will this be back?" support contacts.

To engineering: Scoped, in-app, one migration. The release tightens the hard parts: deduplicated requests and a single confirmation per address under concurrent submits, notification dispatch that doesn't drop sends when a restock lands mid-send, correct FIFO allocation against actual restocked quantity, stock baselines refreshed on re-request, and an admin list that loads each product's last restock in a single query. Queue support is optional — without it, sending begins after the product save completes, so evaluate that path under load. Action items: run php artisan migrate, verify confirmation and restock flows end-to-end, and confirm retention behavior (one-year history) against our privacy posture.

To support/ops: Fewer manual restock emails and a Control Panel that shows waitlist and last-restock state per product without needing a developer.