Restaurants
Reservations and ordering are different actions
For an agent, a table reservation and a food order are two separate actions with different inputs, different systems and different failure points. A reservation needs a date, a party size and a seating slot. An order needs a menu, item availability, a fulfillment method and payment. A restaurant can support one and not the other.
Two actions, two sets of inputs
In conversation, one word covers both. For a machine they share almost nothing: different fields, different confirmations and different definitions of success.
| Reservation | Date, time, party size, seating rules and waitlist behavior. |
|---|---|
| Order | Menu, item availability, fulfillment method, timing and payment. |
Usually two systems, sometimes three
A restaurant often runs reservations on one vendor and ordering on another, with a third behind the website. A homepage can link to one, both or neither, and a phone number can be the only route to a table.
The presence of an order button therefore says nothing about whether a time can be held.
Why merging them produces a false result
Collapsed into a single bookable flag, a delivery-only restaurant reads as ready and a reservation-only restaurant reads as broken. Both descriptions are wrong, and an agent acting on either fails in front of a customer.
How we keep them apart
Reservations and ordering are recorded as separate rows with their own states, and neither is ever exercised: no table is held and no order is placed.
A restaurant can come back as reservations observed and ordering unknown. That is more useful than one score covering both.
Sources
- Local record: bookability check specification
Restaurants are where we observe. The supported path today is appointment-based, on Square Appointments.