Reservierungen & Tische

Waitlist

Capture walk-ins and overbooked guests, give them a realistic wait, and notify them automatically when a table is ready.

The waitlist sits next to the reservation list as a parallel queue for parties who want to dine but do not yet have a confirmed table. It applies to walk-ins, to guests who arrive too early, and to overflow when the dining room fills up.

Adding a guest to the waitlist

From the reservations view, click + Waitlist, enter the party size, and optionally a name and phone number. Onboard computes a starting estimate based on the average turn time of tables that match the party size and the current state of the floor.

Live estimates

The wait estimate updates whenever a table changes status. When a 4-top finishes and moves to Cleaning, the next compatible party in the queue sees its estimate drop in real time. Hosts can override the estimate manually if the model is being too optimistic on a busy Saturday.

Notifying the guest

When the party reaches the front of the queue and a suitable table opens up, the host promotes the entry and the guest is notified by email (there is no SMS channel — see the data-residency page). Guests using the mobile app additionally get a push notification. In practice most hosts simply call the waiting guest — the entry keeps the phone number front and center for exactly that.

No phone number?

Waitlist entries without a phone number stay in the queue and require the host to flag down the guest in person — useful for guests waiting at the bar.

Promotion to a reservation

Once a waitlist guest is seated, the entry is converted into a regular reservation and flows through the standard lifecycle. Channel is recorded as walk-in in reports.

Auto-promotion on cancellation

When a confirmed reservation flips to cancelled or no_show, an AFTER-UPDATE trigger fires the queue_waitlist_for_cancelled_reservationfunction which calls notify_waitlist_for_slot with the freed slot's date, time and party size. Matching pending entries are bumped to status='notified' and their notification_count is incremented — the host sees them at the top of the waitlist with a “Free slot matches!” hint.

Row shape

Name	Type	Required	Default	Description
status	'pending' \| 'notified' \| 'converted' \| 'cancelled' \| 'expired'	—	—	Pending = freshly added. Notified = a free slot matched, host is reaching out. Converted = a reservation was created from this row. Cancelled / expired terminal states.
preferred_date / preferred_from / preferred_to	date / HH:MM / HH:MM	—	—	Optional time-window. When set, the auto-promotion only fires for slots inside the window.
notification_count	integer	—	—	Incremented by each notify_waitlist_for_slot match. The dashboard surfaces "3× notified" so staff can tell when an entry is going stale.
last_notification_at	timestamptz	—	—	Stamp of the latest match. Used by the waitlist-notifications cron to dispatch emails or SMS for new matches.
expires_at	timestamptz	—	—	Optional cutoff. The waitlist-cleanup cron flips status to expired once this passes — keeps "yesterday's walk-in" from cluttering today's queue.
converted_reservation_id	uuid	—	—	Set when convertWaitlistToReservation creates the real booking. Lets the dashboard show a "→ reservation" pill that links across.

Cron helpers

Two service-role-only Postgres functions back the worker schedule:

match_waitlist_for_slot(...) is a dry-run that returns the entries that would match a slot, without mutating anything. Used by the host preview before deciding to promote manually.
expire_stale_waitlist_entries() is what the daily /api/cron/waitlist-cleanup calls. Flips pending / notified rows whose expires_at has passed to expired and returns the count.