# Restaurant Table Management: Plans and Timers
*How a dining room is run day to day, from drawing the floor plan to seating timers, moving an order and merging two tables*

> **In short:** A practical guide to restaurant table management: drawing the floor plan, table states, seating timers and turnover, moving orders and merging tables.

- **URL:** https://www.snad.io/en/blog/idarat-tawilat-almataam-dalil
- **Arabic original:** https://www.snad.io/blog/idarat-tawilat-almataam-dalil
- **Category:** Industry — Restaurants & Cafés
- **Tags:** Restaurants, Cafes, point of sale, POS
- **Published:** 2026-09-06
- **Updated:** 2026-09-06
- **Publisher:** Snad (snad.io)

The difference between a shop till and a restaurant till is not selling speed. It is that the order **stays open**.

In a shop the sale opens and closes in the same instant. In a restaurant the guest sits, orders, adds more, then asks to pay — and through all of it there is a bill held against one particular table, and a waiter who knows where the plate goes.

This article is about the unit all of that turns around: **the table**. How it is drawn, how its state is read, how the time it spends occupied is measured, and what happens when a guest moves or two tables are pushed together.

## Why a shop till falls short in a restaurant

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

| Aspect | Shop till | Table service till |
|---|---|---|
| The order | Opened and closed in one moment | A live bill that grows in rounds |
| Stock | Deducted at the sale | Deducted at payment |
| The document | One receipt for the guest | A guest receipt and a kitchen ticket |
| Capacity | A queue at the till | Halls, tables and a timer on each |
| The staff | A cashier running the sale | A waiter running tables, measured by them |

**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.

## The plan: from the manager's paper to the till screen

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.

## Table states and what each one tells whom

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

| State | What it means | Who reads it |
|---|---|---|
| Available | No open order | The host at the door |
| Occupied | Guests seated, bill open | Waiter and host |
| Over time | Past the seating limit set | The manager |
| Reserved | Held under a name and time | The host |
| Out of service | Kept out of seating | Everyone |

**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.

## Seating timers and table turnover

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.

## Moving and merging: two nightly situations

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.

## Frequently asked questions

### What is the difference between an ordinary till and table management?

An ordinary till opens and closes the sale in one moment. Table management keeps the bill open on the table and grows it in rounds until the guest asks to pay.

### Does an open table order count as a sale?

No. An open order posts no accounting entry and deducts no stock. It becomes a sale on payment alone, so sales reports match what was actually collected.

### How does a table free up after guests leave?

By closing its bill. Table state is derived from an open order rather than stored, so payment frees the table with no second manual step.

### What seating limit suits my restaurant?

It differs by room and by meal type. Set a limit per room, then review the measured average sitting time after a month and set it against reality rather than an estimate.

---
## About the publisher
**Snad (سند)** — a private Saudi software company
based in Riyadh, founded 2025. Legal form: Sole proprietorship.
Commercial registration: 7038154642
VAT number: 310959226500003
Only official domain: snad.io
> Snad is a private commercial business-management platform. It is not a
> government body, not a bank, and not a government services portal, and it
> is not affiliated with any government entity. Any site or app with a
> similar name is unrelated to Snad.