Restaurant Table Management: Plans and Timers

Most till software sells, deducts and prints a receipt. That serves a store completely, and leaves a restaurant with half of what it needs.

The second row matters most in the accounts: an open order is not a sale. It posts no entry and moves no stock until it is paid. A restaurant with twenty open tables at eight in the evening has not sold twenty times yet — counting them as sales the moment they open would show revenue nobody collected, and would draw stock that might still be cancelled.

This is not a technical detail. It is the difference between a sales report you trust and one you re-check every night.

Most restaurants carry their floor plan in the manager's head or on a sheet in a drawer. When a new waiter starts, they learn it by asking.

A plan on the screen does three things:

1. It settles the numbering. Table 7 is the same table for everyone on shift, on the receipt, and on the kitchen ticket. 2. It makes state visible. Nobody asks who is sitting where — the room is in front of them. 3. It stays identical across devices. A plan you draw on a wide screen lands the same on a ten-inch till, because table positions are stored in grid units rather than pixels.

What is worth attention while drawing:

• Draw what exists, not what you hope for. The plan is an operating tool, not an expansion proposal.
• Let shapes match reality. Round, square, bar and counter: a waiter recognises a shape faster than a number.
• Separate rooms properly. Indoor, terrace and family sections carry different seating limits, and mixing them into one plan costs each of them its limit.

A plan is not a one-time job either. Rooms change with the season, and a Ramadan layout is not a summer layout. Keep it something edited in minutes rather than rebuilt as a project.

A table's colour on screen is the fastest piece of information in the whole restaurant.

One rule prevents the best known fault here: the state is derived, never stored. "Occupied" means an open order exists, not a flag an employee sets.

Why that matters to someone who is not a programmer: a stored state means a table stays "occupied" after its bill is closed and nobody can free it without intervention. That fault surfaces on the busiest night precisely, when nobody has time to intervene. When the state is derived, closing the bill is freeing the table.

The host at the door benefits first. Their only question is which table frees up now, and the screen answers in a colour before anyone opens a report.

Table turnover is how many times a table is used within one service period. It is the most important number in a restaurant with a fixed number of seats, because it multiplies revenue with no extra seat and no advertising.

A timer makes it visible as it happens: every occupied table shows how many minutes its guests have sat, and shifts to an alert colour past the limit set for its room.

Three notes on using it:

1. The limit differs by room. A quick lunch sitting is not a family dinner, and one limit for both turns the alert into noise people ignore. 2. An alert is information, not an instruction. It does not mean rushing a guest. It means the host knows the waiting list will move late, and can give anyone waiting a realistic time. 3. The timer runs on the server, not the device. Three devices with three unsynced clocks give three answers to one question, and the argument then is about the clock rather than the table.

What the timer measures across a month matters more than what it shows in the moment: average sitting time per room, per day, per waiter. If one room turns twice and another four times on the same evening, the question is what separates them — and it may be distance from the kitchen or how rarely anyone passes it, rather than anything about the guests.

Two situations anyone who has worked a dining room knows, and which an ordinary till only solves by voiding the bill and re-entering it.

First: the guest moved. A party sat near the door then asked for a table further in. The bill is not voided and not rebuilt — it is moved. What was ordered stays as it is, and the table number updates on any order that has not reached the kitchen yet.

Second: two tables were pushed together. A group grew, two tables were joined, and the party wants one bill. Merging brings the two bills into one.

One small detail carries a kitchen error behind it: on merging, rounds are renumbered. If each bill carried its own "round one" and the two were merged, a single ticket would hold two rounds with the same number — and the cook reads one number for two different orders. Renumbering prevents that before it happens.

When two devices work on the same table, which happens as soon as the waiter opens the order on their device and the cashier opens it on another, the second edit is refused and reloaded onto the first one's version. The practical effect: neither silently erases the other's order.

Those three situations together are what separate software built for restaurants from software that had the word "table" added to it.