Use five core restaurant reservation statuses: booked, arrived, seated, canceled, and no-show. Add a separate way to record a party that arrived but left before seating, if the system supports one. If it does not, agree on a fallback status and a clear reason note. The aim is for every host to read the floor view and reach the same conclusion about what needs attention.
A status describes what happened to a guest party. It does not, by itself, prove that a physical table is free or occupied. Before choosing a restaurant reservation system, decide which events staff will record, who can change them, and how exceptions appear in the shift report.
Define the five core statuses
Booked means the reservation is expected but the party has not checked in. It may still be a future booking or a party whose reservation time has passed. A late booking should not automatically become a no-show just because the clock moved on; the restaurant needs an agreed cutoff and a person responsible for applying it.
Arrived means the party has checked in with the host but has not yet been seated. This status helps the team distinguish a party waiting at the door from one that has not appeared. Agree on whether one guest arriving is enough to check in the whole party or whether the host should wait for the complete group. If partial arrivals matter, ask how staff can record them without making the floor view misleading.
Seated means the party has actually been taken to a table. Marking a party seated when a table is merely being prepared makes the floor view unreliable. The host should update the booking at the handoff, not when the party is called from the waiting area.
Canceled means the booking will not be used. Record it when the guest cancels or the restaurant closes the booking for an agreed reason. A cancellation before arrival is different from a guest leaving after check-in, so use a reason or note when the software allows it. Decide whether cancellation releases any table assignment and confirm what the screen shows afterward.
No-show means the party did not arrive under the restaurant's stated policy. It is not a synonym for canceled, late, or left before seating. A host or manager should check for a late arrival, duplicate booking, or missed check-in before applying it. For more on the operational cost of missed bookings, see the no-show buying guide.
These labels work only if the team agrees on the event behind each one. Ask vendors whether statuses can be renamed or added, whether reason notes are visible to hosts, and whether changing a status affects a table assignment. A familiar label is less useful if its effect on the floor view is unclear.
Map transitions and assign responsibility
The normal path is booked to arrived to seated. The other paths handle exceptions: booked to canceled, booked to no-show, and arrived to a documented departure when a checked-in party leaves. A party may also be seated without a recorded arrival if a host misses the check-in step. Decide whether staff should correct that history or record a note, and whether the system preserves the original change.
Start with a simple division of work. Hosts can check parties in and mark them seated at the handoff. A host can record a guest's cancellation, while a shift lead reviews no-shows and unusual corrections. The right permissions depend on staffing: a small restaurant may have one person doing all of this, while a busy dining room may need a lead to resolve conflicting updates.
Use the following worksheet as a starting policy, not as a claim about any product's available settings.
| Event | Next status | Owner | Check before changing |
|---|---|---|---|
| Party checks in | Arrived | Host | Correct booking and party size; note a partial arrival if needed |
| Party reaches its table | Seated | Host seating the party | Confirm the actual table and handoff |
| Guest cancels before arrival | Canceled | Host | Record the reason and check the table assignment |
| Party has not arrived after the cutoff | No-show | Shift lead | Check for a missed check-in or duplicate |
| Checked-in party leaves before seating | Departure status, or agreed fallback | Host; lead reviews | Record that they arrived and were not seated |
The table separates an event from the decision that follows it. In particular, the last row needs a local rule: do not assume every system offers a departure status. Also decide who can reverse an incorrect change. Ask whether staff can see the time and person associated with an update, and whether a correction overwrites the earlier status or leaves a usable history.
Set a no-show cutoff that fits your service rather than relying on an unexplained default. Tell hosts where to find it, how to handle a call from a late guest, and who can make an exception. If the software changes statuses automatically, ask how that timing works and how staff can correct a mistake.
Work through an arrival that leaves
Hypothetical decision worksheet: A restaurant has six physical tables available for a service. A reservation for a party of three is booked for 7:00 p.m. The team marks a party arrived when at least one member checks in, but records whether the full party is present. The restaurant's policy calls for a lead to review a booking as a possible no-show 15 minutes after its reservation time. A status change does not itself confirm a table's physical condition.
At 7:02, all three guests check in. The host selects arrived. They are waiting; no table has been handed over to them. At 7:12, they tell the host they cannot wait and leave. The host records their departure and checks that any table assignment is released according to the restaurant's workflow. A table being released from an assignment does not necessarily mean it is clean and ready for another party.
Result: The party was neither a no-show nor seated. If the system offers an appropriate departure status, use it with a reason. If it does not, the restaurant can choose canceled as its fallback, provided the host adds a visible note such as “arrived; left before seating.” The lead should understand that the canceled total then includes this kind of departure and should check the reason notes before interpreting that total.
There is no need to invent a seventh physical table to accommodate the exception. The restaurant still has six physical tables; each table's actual readiness must be checked separately. The party of three is one guest party, not three tables. If a table was assigned on screen, the host verifies its assignment and physical condition before offering it to someone else.
This scenario also exposes an important buying question: can a host find the departure note during service, and can a manager distinguish these departures from pre-arrival cancellations in a report? If the answer is no, consider whether the team can maintain a simple separate exception log without slowing down the door. If it cannot, ask the vendor to show another workable method before buying.
Audit the shift and practice the workflow
A status policy needs a short end-of-shift check. The lead should look for bookings still marked arrived after service, seated parties with no clear table handoff, and no-shows that may actually have checked in. Compare the reservation list with host notes and the floor's actual use. Resolve obvious mistakes while the team remembers what happened; flag uncertain cases rather than guessing.
Review counts as categories, not as automatic measures of revenue or service quality. A canceled count may include departures if that is the agreed fallback. An arrived count at closing may represent parties still waiting, missed seating updates, or parties who left without a recorded departure. A no-show count is useful only when staff apply the same cutoff and check-in rule.
For a small hypothetical audit, suppose the report shows 20 bookings: 14 seated, two canceled, one no-show, and three still arrived. The lead checks the three arrived records and finds that two parties were seated but not updated and one left before seating. After correcting the records under the restaurant's policy, the counts are 16 seated, three canceled including one documented departure, and one no-show: still 20 bookings. This is a status reconciliation, not a sales or table-capacity calculation.
Before adopting the workflow, run a simulated check with fictional bookings. Ask the host to enter a normal arrival and seating, a cancellation, a possible no-show, and an arrival that leaves. Confirm what appears on the floor view and report, who can make corrections, and whether the history remains understandable. Use a safe practice environment or vendor demonstration that sends no real guest messages, takes no real payment, and triggers no courier dispatch.
A live service pilot is different: real staff use the agreed process for actual bookings, with a shift lead watching for missed updates and following the restaurant's normal guest communication practices. Start with a manageable service, compare the report with what the team observed, and revise the rules before wider use. Do not treat a successful simulation as proof that a busy shift will run perfectly.
Make a one-page version of your definitions and put it where hosts can find it. For setup questions, review the reservations documentation and ask the vendor to demonstrate your exception path. Then compare your requirements with Fleksa and request a demonstration of its reservation workflow, including check-in, seating, corrections, and reporting.
Frequently asked questions
When should a host mark a reservation arrived?
Mark it arrived when the party checks in under your restaurant's rule. Decide in advance whether one guest is enough and how to note that the rest of the party is still coming.
Is a guest who leaves before seating a no-show?
No. The guest arrived. Use a departure status if available, or an agreed fallback with a note that preserves the distinction from a pre-arrival cancellation.
Does seated mean the table is ready for the next party?
No. Seated records the guest party's handoff to a table. Table readiness is a separate physical check, including whether the previous party has left and the table is prepared.
