Which plan includes table management?

Table management is part of the Reservations module, and Reservations is on the Business plan. The walk-in waitlist, guest messaging, digital menu and QR joins are on every plan, so you can start smaller and move up when you want bookings on your own floor plan.

Can two bookings ever land on the same table?

No. Every hold, booking and block writes a time range against a specific table, and an overlapping range is refused by the database itself rather than by application code that a busy Friday could race. The floor plan is inventory, not a drawing.

What happens when a booked party arrives and the table is not ready?

The host moves them into the walk-in queue on the same visit. They keep the booking, they keep their place, and the guest history shows one visit rather than a reservation plus an unrelated queue entry.

Does it sync table status with my POS checks?

No. StoveOps runs beside your point of sale and never reads checks or payments. If a server section, the open check and the table state have to be one object, a POS-native table product will fit tighter than a tool that runs alongside.

Restaurant Table Management Software

What table management software has to get right

Every table management tool draws a room. The ones that survive a Saturday get three harder things right.

Inventory that cannot be oversold. A floor plan is only useful if a table can be committed to exactly one party for exactly one window. If two hosts on two devices can both give table 12 to a 7:30 pm booking, the drawing is decoration.

Two truths at once. A table has a planned future — the 8:45 pm booking that already exists — and a physical present — the party still lingering over coffee. Those two facts coexist. A tool that stores only one of them either forgets tonight’s bookings or pretends the room is empty when it is full.

A path for the party that shows up anyway. Walk-ins do not stop arriving because the book is full, and booked guests do not stop arriving early. The floor has to absorb both without a host re-typing anyone’s name.

How the StoveOps floor plan works

You describe the room the way you talk about it: areas first — main dining, patio, bar, private room — then the tables inside each area, with the party sizes each one really seats. Layouts are versioned, so redrawing the patio for summer is a revision you publish rather than a destructive edit made mid-service.

That plan is the inventory the booking engine sells from. Availability is computed against real tables in real areas, which is why a guest booking from your mini-site sees the room you actually have rather than a generic slot grid.

Double booking is a database rule, not a check in the code

When a hold, a booking or a block is written, it claims a time range against a table. Overlapping ranges on the same table are rejected by the database, under load, whether the second request came from the public booking page, a host on the floor, or an import running in the background. This is the difference between “we validate that” and “it cannot happen.”

The three states a table is really in

During service the board separates what is committed from what is happening:

Allocated — a future window is claimed for a party. Nobody is sitting there yet.
Occupied — a party is physically at the table right now.
Clearing — the party has left and the table is not yet ready for the next one.

Keeping these apart is what lets an occupancy that is running long and a booking that starts soon coexist without the system silently cancelling somebody. A turn that overruns is surfaced to the host as a decision to make, never resolved behind their back.

When a booked party meets a full room

Two moments break most tools, and both have a defined path here.

The booking arrives early, or the table is not ready. The host puts the party into the walk-in queue on the same visit record. The reservation still stands, the guest keeps one place in one queue, and the CRM records one visit — not a booking and a mysterious second entry with the same name.

The night is full and the guest still wants in. They can register interest for a time window instead of leaving. When a table frees up, the freed window is offered to matching guests with an expiry, so a cancellation at 6 pm becomes a seated cover at 8 pm instead of an empty two-top.

Arrival policy you set once

Three settings decide how the floor treats time, and each ships with a default you can change per store:

Early check-in window. How long before the booked time a guest may check themselves in from their confirmation link.
No-show grace. How long the table keeps being held past the booked time before staff may release it. The default is a grace of a few minutes past the hour, the way the industry actually runs it, rather than holding a table until the end of the whole seating window.
Cancellation cutoff. How close to the booked time a guest may still cancel themselves. Staff are never bound by it; the cutoff exists so a kitchen that already bought for the cover is not surprised, not to trap the guest.

What this deliberately does not do

No deposits or prepaid covers. There is no card hold on a booking. If your model depends on prepaid tickets, a ticketing-first reservation platform fits better.
No POS check sync. Table state here is about seating, not about the open check.
No diner marketplace. Nobody is sent to you by a discovery network, and nobody is charged per cover. The guest list is yours.

Which plan this is on

Reservations — floor plan, service agenda, public booking and the table management described on this page — is the module on the Business plan. The walk-in waitlist, two-way guest messaging, the digital menu and QR joins are on every plan, including Basic. Compare the tiers on our pricing page before you decide: a single room that mostly seats walk-ins is often better served starting on the waitlist and moving up once the book is genuinely full.

Setting it up in one shift

Draw the areas and tables as your team names them. Do not model the room you wish you had.
Set the service periods you actually seat, and the pacing you can cook.
Set the arrival policy — early check-in, no-show grace, cancellation cutoff.
Publish the booking page on your mini-site and put the link where guests already look.
Run one real service. Watch where the board and the room disagree, and fix the plan, not the process.

If you are still deciding between running the door and running the book, start with reservations and waitlist compared, and check turn time for the number this all moves.

Table management software that keeps the floor honest during service