The floor plan, the waiter app and the four states a table can be in

Every busy dining room runs on one shared question: which tables need something right now? Answering it out loud, across a room, is how service gets loud and slow.

A floor plan on a screen answers it silently.

Four states, and why the fourth matters

A table is in exactly one of these:

The fourth one is the one most systems skip, and it is the one that costs money. A table waiting for the bill is not “occupied” in any useful sense — it is a table you could turn in four minutes if someone noticed. Giving it its own colour on the plan turns a vague obligation into a visible task.

The plan itself is a grid, so it can be laid out to look like your actual room. That sounds cosmetic and is not: staff navigate by memory of the space, not by table numbers in a list.

Assignment is what creates responsibility

Each table can be assigned to a waiter, whose name shows on the plan. This is not about control. It is about the difference between “someone will get to table nine” and “table nine is yours” — and about the guest who can tell you who served them when they compliment or complain.

It also feeds the waiter app: a member of floor staff opens their app and sees their own tables, their own orders and nothing else. Fewer decisions, fewer mistakes, less scrolling on a Friday.

Merging, moving and splitting

Real service does not respect a seating chart:

• Merging. Two tables become one party. The orders join, and the system remembers where the merged party came from so the report does not lose a table’s history.
• Moving. A party changes tables mid-meal. The order goes with them; nobody re-keys anything.
• Splitting a bill. The order is divided into parts, each with its own amount and status, and each part can be paid by a different method. One person pays by card, one in cash, and the till knows both landed against the same order.

That last one deserves emphasis, because splitting on a calculator and then ringing two separate sales is how a night’s takings stop reconciling with its orders.

Reservations, and the no-show problem

A booking has a status that moves through its life: pending, confirmed, seated, completed — or cancelled and no-show. That final pair is the point.

A no-show is not a neutral event; it is a table you held and could have sold. If nothing in your system marks it, you never learn which nights, which party sizes or which sources produce them. When confirmed bookings that never arrive are flagged automatically after their start time has passed, you get an actual number instead of a grudge.

What you do with that number is a policy decision: a confirmation message the day before, a deposit for large parties, or a shorter hold. All three work. None of them works without the data.

A practical setup

• Lay the plan out like the room, including the terrace, and number tables the way your staff already call them.
• Turn on waiter assignment from day one. It costs nothing and settles most service disputes.
• Use “waiting for bill” honestly, and watch how much faster tables turn on a Saturday.
• Review no-shows monthly, not emotionally.

None of this is complicated. It is just the difference between a room your team reads and a room your team remembers.