Reservations overview
The reservation lifecycle, status flow, and how the moving parts fit together.
Reservations are the central entity in DineOS. Every other module — floor plan, guest CRM, reports, AI assistant — observes or mutates a reservation in some way. A reservation captures who is coming, when, how many guests, which table, who took the booking, and what notes the host should know about.
Lifecycle
Every reservation moves through a fixed state machine:
Pending → Confirmed → Seated → Completed, or Pending → No-show, or Pending → Cancelled. Transitions can be triggered manually or automatically by widget submissions, time-based rules, and POS events.
Status reference
| Name | Type | Required | Default | Description |
|---|---|---|---|---|
| Pending | status | — | — | Booked but not yet confirmed. Used when a request requires manual approval (e.g. parties over 8). |
| Confirmed | status | — | — | The reservation is locked in. Confirmation email and SMS go out at this point. |
| Seated | status | — | — | Guests have arrived and been seated. The assigned table turns green on the floor plan. |
| Completed | status | — | — | Guests have left and the table is being reset. POS revenue, if linked, is attributed to the reservation here. |
| No-show | status | — | — | Guests did not arrive within the grace window. Counts toward no-show rate metrics and trains the prediction model. |
| Cancelled | status | — | — | Cancelled by the guest or by a host. Does not count as a no-show and does not affect the prediction model. |
Channels
Reservations can originate from four channels: the embeddable widget, the custom booking page, a phone call entered by a host, or a walk-in promoted from the waitlist. Channel is recorded on every booking and is available as a filter in reports.