Before, during and after service
Floor team guide
How to read service, move a booking and preserve the context the next shift needs.
- This guide is for
- Hosts, bookings, maître d’ and floor team
- Expected outcome
- The team knows what it can change, what it must record and when to escalate an incident.
Prepare service
The daily view must match reality before doors open.
- 1.1
Review bookings, waitlist, groups, allergies, menus and floor notes.
- 1.2
Confirm that tables blocked by an event or private hire are not offered.
- 1.3
Assign one person responsible for changes and exceptions during the shift.
Operate with traceability
Every change must leave a cause the rest of the team can understand.
- 2.1
Move states only when the action happened: confirmed, seated, finished or no-show.
- 2.2
Record source, table, menu and relevant notes without duplicating unnecessary data.
- 2.3
Treat demo notifications, deposits and automation as simulations, not real messages or charges.
Incidents and support
An operational incident needs a known fallback even when the system does not respond.
- 3.1
Keep the agreed fallback channel and do not promise confirmations the system has not issued.
- 3.2
Record time, user, affected booking and expected result before contacting support.
- 3.3
Escalate sensitive data only through the approved channel with the minimum necessary content.
Working rule
The restaurant owns business decisions and approvals. Logic2B owns only the implementation and service explicitly agreed in the proposal.
Proposal-dependent
