Home › Blog › Restaurant Table Management & Floor Plan POS: A Practical Guide for Dine-In

Restaurant Table Management & Floor Plan POS: A Practical Guide for Dine-In

5 Jul 2026 • 10 min read

Table management is the part of a restaurant POS that turns a room full of guests into an organised service. It is where dine-in lives: a floor plan you can seat from, covers you can track, bills you can split and merge, and a kitchen that gets the order the moment it's taken. Get it right and service feels calm; get it wrong and every busy night is a scramble. This guide explains what good table management looks like and how to use it.

The floor plan

It starts with a map of your actual room. A good POS lets you place round and square tables, a bar, an entrance and zones, label them (W1, 1–12, P4) and set seat counts. During service the same plan becomes your control panel: occupied tables are shaded, each shows its running bill, and you tap a table to work it. Because the layout mirrors your real room, anyone on shift can read it instantly.

Seating and covers

When you seat a table you record covers (pax) — how many guests. Covers matter for more than seating: they drive per-guest spend analytics, help pace the kitchen, and inform how you staff future services. A POS that captures covers at seating gives you data a counter-only till never will.

Table states: reading the room at a glance

Every table is in a state — free, seated, ordered, waiting too long, ready to pay. The floor plan should surface these visually. A subtle but powerful feature is an ageing indicator: a table whose oldest order the kitchen hasn't served yet turns amber, then red, so staff can chase it before the guest has to. That's the floor-plan equivalent of the KDS timer, and it prevents the quiet table that's been forgotten.

Cook-first: send to the kitchen, settle later

Dine-in is cook-first. You send the order to the kitchen when you take it — it appears on the Kitchen Display and on the table — and payment happens at the end of the meal. When it's time to pay, you pull the table's bill up and settle it. This is fundamentally different from quick-service pay-first, and table management is what makes it work.

Move, merge and split bills

Real tables don't behave. Table management has to handle the three things that always happen:

• Move — a party changes seats, or you re-seat them; the order moves with them, no re-keying.
• Merge — two tables become one party; their bills combine.
• Split — one table pays separately. The best systems split by item (each person's dishes onto their own bill) as well as evenly.

These happen at the most sensitive moment — payment — so they need to be a couple of taps, not a manual rebuild. Splitting by item in particular is where weaker systems fall apart.

QR ordering to the table

Table QR ordering lets guests scan a code at their table and add rounds themselves, straight to the kitchen and onto the table's bill. The important details:

• Per-table session — the QR is tied to that sitting, so it can't be reused after guests leave.
• One unified bill — guest QR orders and staff-taken orders land on the same table, so nothing is billed twice or missed.
• Kitchen gets it directly — the QR round appears on the KDS like any other order.

The result is fewer trips to the table and faster turns without adding staff — especially valuable at peak.

Service charge and takeaway, handled automatically

Dine-in tables should carry service charge; takeaway should not. Good table management ties this to whether an order is seated at a table, so service charge is applied automatically where it belongs and dropped when a table order is converted to takeaway. That removes a common source of receipt errors and awkward corrections.

Turning tables faster

Everything above compounds into table turns. Seating and covers set the pace; cook-first gets food moving immediately; QR ordering removes the wait to flag a server; the ageing indicator stops forgotten tables; and quick split/merge keeps payment fast. None of these is dramatic on its own, but together they add covers per night without adding stress.

Offline dine-in

Table management must survive a dropped connection. That means seating, sending to the kitchen and settling a table all have to work offline, then reconcile when the network returns — occupancy and bills held locally so a Wi‑Fi blip never freezes the floor. If a POS's table features are purely cloud, a two-minute outage becomes a service outage. See why offline matters.

How Shopways handles tables

Shopways includes a visual floor-plan designer, seating with covers, occupied-table shading with running bills, cook-first send-to-kitchen, move/merge/split (including split by item), per-table session QR ordering, and automatic service charge for dine-in — all on an iPad, all working offline, and feeding the same native KDS. It's designed for independent restaurants that want full dine-in without an enterprise system. For the wider picture, see the restaurant POS guide.

Frequently asked questions

Can guests order from the table by QR and still get one bill?

Yes. With a proper per-table session, guest QR orders and staff orders land on the same table bill, so you settle once at the end.

Does splitting a bill by item work, or only evenly?

Good systems do both. Shopways splits by item — moving selected dishes to a new bill — as well as splitting evenly.

Is service charge added automatically for dine-in?

Yes. Shopways ties service charge to a table being assigned, so dine-in carries it and takeaway doesn't, automatically.

← Back to all articles