Waitlist Management (Restaurants)

Paid pluginsize Mplanned, not built

Indicative price, not an offer: €24/mo; SMS notifications, wait-time estimates, no-show management

Generated from docs/plan/paid/waitlist-management/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Waitlist system for restaurants capturing walk-in parties and providing wait-time estimates. When table ready, staff clicks ‘call’ button; guest receives SMS notification. Guest can provide phone number to join waitlist; position is transparent. Analytics track no-show rate, average wait, peak times.

The problem

No tables now, walk-ins leave. Restaurant loses revenue. Toast has this built-in, but custom implementations fail at multi-channel notifications (SMS, callback, position updates). Need to capture walk-in demand, forecast wait times, and notify when seated.

What it does

• Walk-in entry (guest name, party size, phone number)
• Online waitlist signup (pre-book wait slot)
• Wait time estimate (based on current turn times + queue depth)
• Waitlist position (guest can see where they are: ‘#3 of 7’)
• SMS notification when called (guest receives ‘Your table is ready’)
• No-show tracking (guest doesn’t arrive after 10 min)
• Manual reordering (bump VIP to front)
• Waitlist analytics (avg wait, no-show %, peak times)
• Call button (staff marks table ready, SMS sent automatically)
• Cancellation (guest can cancel via SMS or online)

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Pager devices — hardware, lost device liability. Reason: hardware complexity.
• Text-to-speech callers — vendor lock-in. Reason: no standard API.
• Walk-in reservations (different from waitlist) — scope boundary. Reason: different booking flow.

Data model

New table: waitlist_entries (entryId, partySize, guestName, phone, email, status (waiting/called/seated/no_show/cancelled), position, joined_at, estimated_ready_at, actually_ready_at, sms_sent_at, sms_delivery_status). Reservation schema: add from_waitlist (boolean), waitlist_entry_id (fk). Audit: all waitlist adds, calls, cancellations. Migration: add table + indexes on status + joined_at.

API

• POST /api/waitlist
• GET /api/waitlist
• PUT /api/waitlist/{entryId}/cancel
• POST /api/admin/waitlist
• PUT /api/admin/waitlist/{entryId}/call
• PUT /api/admin/waitlist/{entryId}/reorder
• GET /api/admin/waitlist-report
• POST /api/webhooks/twilio/sms-delivery

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Waitlist dashboard (live list, position, estimated time). Add walk-in form. Call button (mark ready, send SMS). Reorder UI (drag to prioritize). No-show tracker. Wait-times analytics (by day, time, party size).

The seam — why this is paid

Core owns: waitlist data model, position tracking, status flow. Paid pack owns: SMS notification system, wait-time forecasting, no-show analytics.

Support commitment: SMS delivery SLA, wait-time forecasting, guest tracking

Dependencies

• Reservation system
• SMS provider (Twilio)
• Turn-time data (from party-size-seating)
• Webhook system

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• Walk-in adds to waitlist; told ‘You are #3, estimated wait 40 minutes’
• Staff clicks ‘Call’; SMS sent ‘Your table is ready! Please come to host stand’
• SMS delivery confirmed via Twilio callback; entry marked called
• Guest doesn’t arrive after 10 min; staff marks no-show
• No-show rate dashboard shows 15% calculated from last 30 days
• Admin manually reorders to VIP on top; position numbers auto-update
• Wait-time estimate based on current turn times + queue depth (accurate ±15%)
• Guest cancels via SMS or online; position removed, others shift up
• Waitlist position transparent (guest can text ‘my position?’ → responds)
• Peak-times report shows Friday 7-9pm has longest waits (90 min avg)

Risks

SMS delayed 5 min: guest already left, no-show recorded wrongly. Wait-time estimate assumes fixed turn time (but varies by party size). No-show rate includes canceled-but-not-removed guests (false positive). Reorder not saved (UI drag/drop, but revert on refresh). Position calculation off-by-one (says #3, actually #2).

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.