Customers & Automation
Storefront Push Notifications
Last updated 19 May 2026
Storefront Push Notifications
Customers opt into web push notifications after their first booking. The next time a relevant event happens (confirmation, reminder, change), they get a heads-up on their device. Web Push, not SMS — works on Chrome, Edge, Firefox, and iOS 16.4+ as a PWA.
Where customers see the opt-in: storefront booking confirmation screen. Where pushes arrive: their phone or desktop notification tray.
TL;DR
- Web Push opt-in surfaces automatically post-booking; no operator config.
- Works on Chrome (Android + desktop), Edge, Firefox, Safari macOS, and iOS 16.4+ (PWA install required for iOS).
- Booking confirmation push is the primary event; framework supports more.
- All plans. Free.
When the opt-in appears
After a customer completes a booking on your storefront, a card renders at the bottom of the confirmation screen:
Get a heads-up before your visit "Allow notifications to get a reminder on this device when your appointment's coming up." [Turn on notifications]
The card self-gates and only appears when:
- The customer's browser supports Web Push (
serviceWorker+PushManager) - The platform has VAPID keys configured (it does —
NEXT_PUBLIC_VAPID_PUBLIC_KEY) - The customer hasn't already subscribed (otherwise shows "Notifications are on")
Tap Turn on notifications → browser prompts for permission → if allowed, the service worker registers and the subscription is saved server-side.
What pushes the customer receives
Currently:
- Booking confirmed — Title: "Booking confirmed at {venue}". Body: "{service} with {staff} on {date} at {time}." Tag:
booking:{bookingId}(renotify on update).
Framework supports more (reminders, cancellations, change notices) using the same dispatcher. As more notification types are wired in, they'll appear without operator action.
Platform support
| Platform | Web Push works? | PWA install required? |
|---|---|---|
| Chrome (Android) | Yes | No |
| Chrome (desktop) | Yes | No |
| Edge (Windows/Mac) | Yes | No |
| Firefox | Yes | No |
| Safari (macOS 13+) | Yes | No |
| Safari (iOS 16.4+) | Yes | Yes — must Add to Home Screen first |
| Older iOS, older Safari | No | N/A |
| In-app browsers (Instagram, FB) | Usually no | N/A |
The opt-in card self-detects support and only shows when the browser can deliver Web Push. iOS users get the card too, but tapping it requires their browser to support permission requests (which means iOS 16.4+ Safari, ideally after PWA install).
iOS specifics
iOS 16.4 introduced Web Push, but only for sites installed as PWAs (Progressive Web Apps). A customer on an iPhone needs to:
- Open your storefront in Safari
- Tap the Share button
- Tap Add to Home Screen
- Open the app from the home-screen icon
- Now they can subscribe to push notifications
Without PWA install, iPhone customers can't subscribe even if they tap the opt-in. The card surfaces messaging accordingly.
This is an iOS restriction; we can't work around it. Most customers won't bother installing the PWA, so iPhone reach for storefront push is limited until Apple changes the policy.
Operator config
None required. Push is on by default for every venue. There's no settings page, no toggle, no per-event configuration today.
If you want to monitor adoption, the underlying customerPushSubscriptions table tracks active subscriptions per venue per customer. Reach out to support for analytics queries.
Security & privacy
- Subscription identity is validated server-side against the booking's HMAC token — a customer can't register against another customer's email by spoofing the request.
- Customer email/phone are pulled from the booking record, not from caller-supplied data, on the server.
- Subscriptions are pruned automatically when the browser returns 410 Gone (subscription expired or revoked).
- VAPID keys are platform-level (one keypair across all venues); standard Web Push security model applies.
The service worker
A minimal service worker at /storefront-sw.js handles:
- Install:
skipWaiting()so it activates immediately - Activate:
clients.claim()so it controls existing tabs - Push: displays notification with icon (
/icon-192.png) and badge (/badge-72.png);renotify: truewhen tagged so subsequent pushes with the same tag wake the device - Click: focuses an existing tab on this origin, or opens a new one to the URL in the push payload
Customer experience
When a push fires:
- The customer's device shows a notification with your venue name and the event detail
- Tapping opens the relevant URL (usually the booking detail / manage page)
- The push respects the device's Do Not Disturb / Focus settings
If the customer doesn't tap, the notification stays in their device's tray until cleared.
Renotification
Pushes for the same booking (e.g. confirmation, then a reschedule) use the same tag so each new push replaces the previous one — your customer's device shows the latest state, not 5 stacked notifications.
Customer-side opt-out
Customers can:
- Decline the initial prompt — no subscription created, no future pushes
- Disable in browser settings — Chrome / Safari settings → Notifications → block your domain
- Clear the subscription — visit their manage link and revoke (where supported)
We don't have a "remove me from push" button on the storefront UI today; browser-level revoke is the canonical opt-out.
Difference from operator push and SMS
| Channel | Audience | Transport | Doc |
|---|---|---|---|
| Storefront push (this doc) | Customers | Web Push (W3C) via service worker | This doc |
| Operator push | Staff using the mobile app | Expo native push (APNS / FCM) | Push Notifications |
| SMS | Customers | Twilio | Inbox, Automated notifications |
| Customers | Resend | Automated notifications |
Web Push is additive — it doesn't replace SMS or email; it stacks on top for customers who opt in.
Tier
All plans. No PRO requirement.
Common mistakes
| Problem | What to check |
|---|---|
| Opt-in card doesn't appear | Browser doesn't support Web Push, or customer is already subscribed. Both conditions are auto-detected and the card hides accordingly. |
| iPhone customer says they can't subscribe | iOS Web Push needs PWA install (Add to Home Screen). Without it, iOS won't allow the permission prompt. |
| Customer subscribed but isn't getting pushes | Check their browser's notification settings — they may have muted notifications system-wide or for your domain. |
| Want to push a custom message | Not supported via UI today. Pushes fire automatically for booking events. Manual broadcast push isn't in the operator surface. |
| Customer wants to unsubscribe | They can revoke at the browser level (Chrome Settings → Notifications). We don't have a "remove" button on the storefront. |
| Push fires twice for the same booking | Shouldn't happen — pushes use the booking ID as the tag so renotifies replace the previous. If you see duplicates, contact support with the booking ID. |
FAQ
When does the opt-in appear?
After a customer confirms a booking on your storefront, a 'Get a heads-up before your visit' card appears on the confirmation screen. They tap to allow browser notifications, and the next booking-related event pushes to their device.
Does it work on iPhone?
Yes, on iOS 16.4 and later — but only after the customer installs your storefront as a PWA (Add to Home Screen from Safari). Without PWA install, iOS doesn't allow web push from the browser. Android Chrome, Edge, Firefox, and desktop browsers work without PWA install.
What notifications do customers get?
Booking confirmation is the primary push (reinforces the email/SMS). The infrastructure supports reminders and changes too — those use the same web-push channel as they roll out.
Do I need to configure anything?
No. Storefront push is on by default for every venue. The opt-in appears automatically after every booking confirmation when the customer's browser supports push and they haven't already subscribed.
Why don't operator push notifications use Web Push?
Operators use the OpenChair mobile app, which is a native iOS/Android app — native push (APNS/FCM via Expo) is more reliable and richer than Web Push for those use cases. Web Push is reserved for customer-facing notifications because customers don't have a native app to install.
Will my customer get a duplicate notification (push + SMS + email)?
Yes — multiple channels are intentional so the customer doesn't miss critical events. If a customer opts in to push, they still get the SMS and email; push is the additional heads-up. They can mute SMS or push independently if they want fewer channels.