How Notifications Work

When a product restocks, DemandLoop detects the inventory increase, selects a batch of waiting subscribers (Fair Queue), and sends notifications through the channels each customer opted into.

What you'll accomplish

• Understand the end-to-end notification lifecycle from subscription to delivery
• Learn how Fair Queue selects which subscribers get notified per restock
• Know where to configure each notification channel (email, web push, SMS)
• Diagnose common delivery issues using Notification History

Requirements

• Plan: Free plan or higher (email included on all plans; SMS requires Essentials)
• Access: DemandLoop dashboard access
• For SMS: A connected Twilio BYOT integration (see the Twilio SMS setup guide)

The notification lifecycle

1) A customer subscribes (and chooses channels)

Customers can subscribe using one or more channels:

• Email (standard)
• Web push (optional; requires browser permission)
• SMS (optional; requires explicit SMS consent and an active Twilio BYOT integration)

What success looks like

• The customer sees a confirmation message on your storefront
• The subscription appears in your subscriptions list

2) A restock is detected

When your commerce platform reports that inventory for a variant increased, DemandLoop:

• identifies the product/variant that restocked
• checks how many subscribers are waiting
• prepares notification send records for the next batch

3) Fair Queue selects who gets notified

Fair Queue helps prevent “inventory rush” by notifying a controlled number of subscribers per restock event.

Fair Queue selection takes into account:

• available inventory at the time of the restock
• how many subscribers are waiting
• cooldown rules that prevent repeatedly notifying the same subscribers too frequently

Configure Fair Queue in:

• Navigation path: Notifications → Fair Queue

4) Notifications are queued (and visible in Notification History)

DemandLoop tracks each notification attempt, including the channel and delivery status.

Find this in:

• Navigation path: Subscriptions → Notification History


What success looks like

• You can filter by channel (Email / Web push / SMS)
• You can see timestamps such as Queued, Accepted/Sent, and Delivered (when available)

5) Delivery happens independently per channel

Each channel sends independently. A failure in one channel does not block the others.

Email

• Sends to subscribers with an email address
• Includes an unsubscribe mechanism

Web push

• Sends only to customers who opted in to web push in their browser/device
• May be delayed for timing rules (for example, daytime delivery in the customer’s timezone)

Configure web push in:

• Navigation path: Notifications → Push Notifications

SMS (Twilio BYOT)

• Requires Twilio BYOT to be connected and enabled
• Sends only when the customer explicitly consented to SMS
• May be delayed during quiet hours to avoid late-night delivery
• Includes the required opt-out instruction (“Reply STOP to unsubscribe”)

Configure SMS in:

• Navigation path: Modules → SMS (Twilio) → Settings (connect Twilio)
• Navigation path: Notifications → SMS Notifications (enable SMS + template)

Where to configure notification settings


• Notifications → Email Settings (sender + templates)
• Notifications → Push Notifications (enablement + content)
• Notifications → SMS Notifications (enablement + template)
• Modules → SMS (Twilio) → Settings (Twilio connection)
• Notifications → Fair Queue (batching rules)
• Subscriptions → Notification History (monitor delivery)

Understanding delivery statuses

Notification History shows a delivery status per notification attempt. These statuses represent the system’s best available signal from the delivery channel/provider.

Common statuses you may see:

• Scheduled: queued for sending
• Accepted: handed off to the delivery provider (or sent, depending on channel)
• Delayed: postponed by timing rules
• Delivered: provider confirmed delivery (when the channel supports callbacks)
• Bounced: recipient address rejected (email)
• Failed: could not be delivered (after error/retry rules)
• Complaint / Suppressed: provider indicates the address should no longer be messaged
• Unknown: status could not be determined

If a customer says they didn’t get a notification

1. Check Subscriptions → Notification History

• Search by customer email and product/variant
• Confirm the channel and status

2. Confirm they were eligible for this restock batch

• With Fair Queue enabled, not every subscriber is notified on every restock
• Subscribers not selected remain waiting for the next restock

3. Confirm channel prerequisites

• Email: address is valid, and the customer didn’t unsubscribe
• Web push: customer opted in on the same browser/device and web push is enabled
• SMS: Twilio BYOT is active, SMS notifications are enabled, and the customer provided SMS consent

4. Check for timing-related delays

• Web push can be delayed by timing rules
• SMS can be delayed during quiet hours

FAQ

Q: Does DemandLoop retry failed notifications? Yes. Failed delivery attempts are retried according to the channel's retry rules. Check Notification History for the latest status.

Q: Can a customer receive notifications on multiple channels at once? Yes. If a customer opted into email and SMS, both channels send independently for the same restock event.

Q: How quickly are notifications sent after a restock? Notifications are queued within seconds of a restock event. Actual delivery timing depends on Fair Queue settings and channel-specific rules (such as quiet hours for SMS).

Next steps

• Fair Queue
• Email Templates
• Twilio SMS Setup Guide
• Emails Not Delivering