Table management for a cafe: a floor plan that survives a rush

Walk into a cafe at 8pm and the floor is a set of promises: table 3 is waiting for two mains, table 7 has asked for the bill, the party of six outside has grown to eight and wants to move inside. None of that is on the menu. All of it is table management.

Most POS demos show a pretty floor plan and stop there. The diagram is the easy part. The useful question is what happens when the room stops matching the diagram — which is most of service.

The short version

A floor plan is only useful if every table is in exactly one state: free, seated, ordered, served, billed or paid.
Model the room as it is, using the names staff already use, and mark which tables can merge.
Test move, merge and split before service — each must preserve items, tax, discounts and the table state.
Handle the edge cases: walkouts, comps, item transfers, re-opened bills and reservation no-shows.
The test is simple: does the screen still match the room at the end of a busy Saturday?

Model the room, not the software’s idea of a room

Start with the floor as it actually is. Not the layout you wish you had, and not a generic grid of squares. Include:

The awkward two-top by the door that everyone avoids
The long communal table that can seat four or eight
The outdoor section, even if it is three tables
The counter seats, if people order and eat there
Any table that is regularly pushed together with another

Give each table a short name staff already use — “window”, “back-left”, “patio 2” — not an abstract number the software assigned. The floor plan is a shared language; if staff have to translate, they will stop using it.

Then decide which tables are mergeable and which are not. A four-top that splits into two two-tops is a different object from a fixed four. If the POS treats every table as an isolated square, staff will create workarounds for the most common seating change in the room.

The states that matter

A table is always in exactly one state. Keep the list short enough that staff can read it at a glance:

Free — clean and available
Seated — guests are there, no order yet
Ordered — at least one item is with the kitchen
Served — food is out, tab still open
Billed — bill printed or presented, payment pending
Paid — settled, table can be cleared

Some cafes add reserved and cleaning. That is fine if the staff will actually maintain them. A state nobody updates is worse than no state, because it looks authoritative while being wrong.

The value of explicit states is not reporting. It is that the counter can answer “which tables need attention?” without walking the room. That matters most when one person is doing three jobs.

Moving, merging, splitting

These three actions cover almost every real floor change. Each one has a failure mode worth testing before service.

Moving a tab

A guest moves from table 2 to the patio. The whole tab should move in one action — items, guest count, discounts, notes, the lot. If the POS instead asks staff to close the tab and open a new one, the stock movement and the bill number get duplicated, and the day’s reconciliation drifts.

Test: open a tab with three items, apply a discount, move it, then settle. The bill should look exactly as if the guest had never moved.

Merging tabs

Two tables push together. Merging should produce one tab with all items and one bill. The hard part is what happens to the table that disappears: it should become free, and any deposit or pre-payment on either tab should carry over, not vanish.

Test: merge a tab with a card pre-payment into a tab with none. The amount due should be the sum minus the pre-payment, not the full sum.

Splitting a bill

A group of six wants three separate bills. Splitting by item is easy; splitting by seat is the version that matters. Each payer should get a bill that adds up, with tax allocated correctly and no item billed twice.

Test: split a four-item tab by seat, then void one item. The remaining bills should still reconcile to the original total.

If any of these actions cannot be undone before payment, staff will avoid them and improvise on paper. That is the moment the POS stops being the source of truth.

The edge cases that decide the setup

The walkout. A table leaves without paying. The tab needs to be closed with a reason, not deleted, so the day’s sales report and the stock movement stay honest.

The complimentary item. A manager sends a dessert. It should appear on the tab at zero value with a reason, not be omitted. Otherwise stock says it was never sold and the guest’s bill does not match the kitchen’s ticket.

The transferred item. One item moves from table 4 to table 9 because it went to the wrong table. Move the item, not the whole tab.

The re-opened bill. A guest notices a wrong item after paying. Re-opening a settled bill should create an adjustment with an audit trail, not silently edit history.

The reservation that no-shows. A reserved table should release on a rule, not on someone remembering. Otherwise the floor plan shows a table as taken while it sits empty.

None of these are exotic. They are Tuesday.

A setup order that works

Draw the room on paper first. Label tables the way staff label them. Mark which ones merge.
Enter the floor plan and walk it. Stand at the counter and check that the screen matches what you see.
Define the states and who changes them. If servers update “served” and the counter updates “billed”, say so.
Run a dry service. Take orders, move a table, merge two, split one, void an item, close the day. Do it before a real customer is involved.
Review after the first weekend. The floor plan will be wrong somewhere. Fix it while the memory is fresh.

Where CafePOS fits

We build CafePOS, so read this as a product description.

CafePOS includes a table layout, attaches dine-in orders to tables, and puts dine-in, takeaway and delivery orders on one board so the counter and kitchen see the same status. Table and order changes are part of the same cloud record, which is the point of a connected POS: the person at the counter and the person on the floor are not reconciling two versions of the room.

It is a cloud service with an account, not an offline app. If your cafe loses connectivity regularly, ask the team what the fallback is before you commit.

CafePOS is configured with you rather than sold as a download. Visit cafepos.in or email contact.cafepos@gmail.com to book a demo.

The test of a floor plan

A good floor plan is not the one that looks tidiest in a screenshot. It is the one that is still accurate at the end of a busy Saturday — when the party of eight has paid, the two-top has been re-set twice, and the patio is closed. If the screen matches the room then, the setup is done.

What a cafe POS does — and what to check before you buy — the workflows that decide whether a system survives service.
GST billing for cafes: what the bill has to carry — the invoice fields and registration modes behind the printed total.
Why an on-device studio builds a cloud POS — where CafePOS sits in the catalogue, and why it is deliberately connected.

Common questions

Why does a cafe need table management if it has only ten tables?

Ten tables is exactly where it helps. A small floor changes constantly — a two-top becomes a four, a group moves outside, two bills become one — and the person carrying the orders is also the person who has to remember all of it. The system holds the state so staff do not.

What table states should a POS track?

At minimum: free, seated, ordered, served and billed. Some cafes add reserved and cleaning. The names matter less than the rule that every table is in exactly one state and staff can see it from the counter.

How should moving a table work?

Move the whole tab to the new table in one action, preserving the items, the guest count and any discount already applied. If the system makes staff re-enter the order, they will avoid moving tables and the floor plan will stop matching the room.

What is the difference between merging tables and splitting a bill?

Merging joins two open tabs into one, usually because a group has grown. Splitting divides one tab into several payable bills, by item or by seat. Both need to keep stock and tax correct, and both should be reversible before payment.

Should QR ordering replace table management?

No. QR ordering changes who takes the order; it does not change the fact that a table has a tab, a status and a bill. A QR menu without a table-aware POS creates the same confusion in a different place.