Service & kitchen
The service lifecycle (a party's meal)
The stages a seated party moves through from seated to departed, how staff advance them, and how course steps are configured per venue.
Updated Jul 23, 2026
Once a party is seated, TableStack follows their meal as a visit — a party physically at the venue, whether they walked in or arrived on a reservation. The visit moves forward one stage at a time, and every screen watching that venue updates the instant it does.
The stages
A visit progresses through this sequence:
| Stage | What it means |
|---|---|
| Seated | The party is at the table; service has begun. |
| Order taken | Their order is in. |
| Drinks served | Drinks are down. |
| First course | First course fired/delivered. |
| Second course | Second course. |
| Third course | Third course (off by default — see below). |
| Food delivered | Mains are down. |
| Cheque requested | The party has asked for the bill. |
| Cheque dropped | The bill is on the table. |
| Paid | Payment is settled. |
| Departed | The party has left. |
A visit only ever moves forward through the stages, and it can skip ahead — a quick lunch might jump straight from Seated to Paid. It cannot move backward through this flow (correcting a mistake is a separate undo action, not a normal transition).
Course steps are configured per venue
The full sequence above is the default menu of stages, but each venue turns steps on or off to match how it actually runs service. Two anchors are always kept — Seated (where service starts) and Departed (where it ends) — and everything between them is optional. Most venues run a two-course flow, so Third course ships turned off; a tasting-menu room can switch it on, and a bar can switch most course steps off entirely.
When a step is switched off, it simply drops out of the flow: the "advance" action skips straight to the next enabled stage. A visit that happens to be sitting on a step you later hide can still advance normally.
How a stage changes
Staff advance a visit from the floor or the kitchen display — one tap moves it to the next enabled stage. Behind the scenes every transition is validated (you can't skip to a stage that isn't next in your flow), written to the audit trail, and broadcast live so the floor, the kitchen screen, and any other open view all update at once. There's no manual refresh.
If your venue has an external POS connected, the POS can drive these course and payment stages instead of (or alongside) your staff — see that article for who holds authority.
Departing cascades
Marking a visit Departed does more than close the meal. It automatically:
- Sets the party's tables to Needs cleaning so a busser knows to clear them (see table statuses).
- Marks every party member as Completed.
- Marks the linked reservation, if any, as Completed.
Bussing the table afterward returns it to Available. This is the hand-off between the meal lifecycle (where is this party in their dinner?) and the table lifecycle (can I seat someone here?).
What this affects
- The floor — each stage change and the final Departed cascade update table, seat and party statuses live.
- The kitchen display — visits appear as cards in their course column and move across as they advance.
- Reservations — seating a reservation starts its visit, and departing completes the reservation. See the booking flow.
- Guest history — a completed visit (and any recorded spend) feeds the guest book.
What affects this
- Your venue's course sequence setting decides which stages exist.
- A connected POS may drive the course and payment stages and restrict what staff can tap.