Restaurant table management is one of those phrases that sounds like software and is really a description of a person. Somebody in every restaurant already does it: they look at the plan, decide the party of six goes on nine and ten joined, hold four back until half seven in case anyone walks in, and move two people off a four top when a bigger party rings. A restaurant table management system is an attempt to write that reasoning down so it survives the person having a night off. This page sets out what it has to encode.
Joins, and the tables that cannot
The first thing the plan has to know is which tables can become a bigger table. Nine and ten join because they are the same height and there is room to pull them together; four and five look adjacent on a drawing and cannot, because a pillar is between them. A system that treats every table as an interchangeable number will confidently seat a party of eight somewhere they physically cannot sit, and the host will start ignoring it within a fortnight. Encoding joins is unglamorous and it is the difference between a plan and a picture.
Holds, releases and the walk in
Every dining room keeps something back. Two covers by the window until a quarter past eight, the counter for anyone who arrives without a booking, the big table until Friday lunchtime in case a party rings. Those are commercial decisions and they expire: a hold nobody releases is an empty table, which costs exactly as much as a no show and is entirely self inflicted. Restaurant table management software earns its price when it releases automatically at the time you set and shows you what is still being held.
Pacing, or why a full book is not a good book
A book with sixty covers all starting at eight is not sixty covers, it is a queue at the door, a kitchen that dies at twenty past and a set of tables that turn once instead of twice. Pacing spreads the starts so the room and the pass can carry them, and it is the single largest difference between what a floor plan seats on paper and what it takes in money. The free worksheet on this site makes the same point arithmetically: the sittings a table turns, not the seats it holds, is what multiplies into the week.
What it should refuse to do
A table management system that will let anyone seat a party of six on a four top, double book a table, or overwrite a hold without a note is not being flexible, it is being useless in a way that only shows up on the busiest night. The useful products make the wrong thing hard and the right thing quick, and they keep who overrode what, so Monday's conversation is about a record rather than about whose memory of Saturday is better.
Questions people ask about restaurant table management system
What is the difference between a restaurant table management system and a reservation book?
The book records that a booking exists. The system decides where it sits and what that does to everything around it. If your problem is remembering the bookings, a book is enough. If your problem is that the room does not fill the way you planned it, the book was never the constraint.
Can restaurant table management software handle walk ins?
It should, and it is worth checking specifically, because walk ins are the part demos skip. You want to be able to seat someone who is standing in front of you without inventing a fake booking, and you want the covers they take to count in the pacing so the next thirty minutes is not oversold.
Does it replace the person on the host stand?
No, and be wary of anything sold that way. It replaces the part of that person's job that is memory and arithmetic, which is the part that fails when they are busy. Judgement about the party in front of them stays with them, and any system that removes it will be overridden within a week.