Service floor
Live table-service workflow for running the dining room.
The POS opens checks. The service floor at /dashboard/platform/service-floor runs them. It shows table states and active checks, and handles items, courses, splits, voids, and closing in one place. It refreshes every 10 seconds.
What the service floor covers
- table states:
available,occupied,reserved,cleaning - open a table and see its active check
- add items to a table with course, seat number, modifiers, and notes (
addServiceFloorItem); this opens a new check if the table has none - edit an item's quantity, course, seat, or notes (
updateServiceFloorItem) - send pending courses to the kitchen, mark served, or close the check (
updateServiceFloorCheckStatus) - fire a pending course or hold it back (
fireCourse,recallCourse) - split by selected items (
splitCheckByItem) - create equal checks for a number of guests (
splitCheckByGuest) or split by assigned seat (splitCheckBySeat), and undo equal splits (recombineEqualChecks) - merge another check into this one (
mergeChecks) - combine tables onto one check (
combineTables) - void an item or the whole check with manager approval
- go to the payment screen
Moving a check to another table is done on the floor map at /dashboard/platform/pos/tables (transferTable).
How the workflow plays out
Open the table
Tap a table to see its active check. Adding an item to an empty table opens a new dine-in check and marks the table occupied.
Add items during service
New items go into a pending course. Items cannot be added to a course that has already been fired.
Control course timing
Fire a pending course when the table is ready. Hold a fired course to move it back to pending. "Send to kitchen" fires every pending course that is not on hold.
Handle check changes
Combine tables, merge checks, or split by item, guest count, or seat. Equal splits create independent checks that each owe a share of the original.
Close the table
Take payment on the payment screen. "Close check" only works when the check is served and nothing is left to pay. Closing moves the order to completed, then the app moves its tables to cleaning unless another active check or seated party still uses them.
Rules the server enforces
- A check cannot move to
serveduntil every active item has a ready or served kitchen ticket, and no course is pending or on hold. - A check cannot be
completeduntil all kitchen tickets are served, paid amounts cover the total, and no tender is in an uncertain state. - A table cannot be set to anything other than
occupiedwhile it has an active check or a seated reservation or waitlist party. - Cancelling a check here is refused. Use the void workflow with a reason and manager approval.
Voids, comps, and approvals
Voids and refunds need a ManagerApproval. A staff member requests approval with a reason (requestManagerApproval). A different user with staff management permission approves it (approveManagerApproval). The requester cannot approve their own request. The approved request is then used once by voidOrderItem, voidOrder, or refundPayment. The pending approval queue is shown on the service floor and payment screens.
compOrderItem exists in the API with the same approval flow, but the service floor has no comp button.
Current limitations
- Reservations are handled on their own page, not on the service floor.
- There is no visual floor-plan editor here. Table positions are dragged on the floor map, and tables are created on Tables & Sections.
- Updates come from polling every 10 seconds, not live push.
The screen reads its data with the GetServiceFloor GraphQL query. There is no separate REST route for it.