The previous article was about spreading guests across the evening. This one is about what happens when a guest asks for a time, and the system has to decide yes or no.
Two scenes, both familiar. A couple tries to book a table for two on Saturday at 8 p.m. The page says there is no availability. They book elsewhere. On Saturday night, at a quarter past eight, one of your tables for two is still empty. Nobody told you, because the guest never rang and you never knew there was a booking to lose.
And the other scene. Two bookings, taken through two different channels, were given the same table. At half past eight you are explaining to a family that their table is not there, and you are doing it through a forced smile.
These look like opposite mistakes. They are not. Both come from how the booking system is designed, and a restaurant can judge a system on exactly that. There are two layers to it.
The first requirement is the baseline, and it has no exceptions. Every booking, whether it comes from your website, by phone or from a guest standing at the door, must go into the same book. Not three lists that are reconciled later, but one.
Then comes the moment that tests it. Two guests, on two phones, ask for the last table at the same time. A sound system lets one of them have it, and shows the other a different time. Never both. It sounds obvious, and yet it is the most common way for a system to fail, because two things happening at the same instant is exactly what a simple design handles badly.
If a system cannot guarantee this, nothing else about it matters. It should not be taking your bookings.
Suppose the system never double-sells. The second question is how many guests it manages to seat. This is where good and ordinary systems part ways, and the reason is easy to see once you picture a Saturday.
Bookings do not arrive together. They arrive one at a time, over days and weeks, and each one has to be answered the moment it comes in. Where you put one booking changes what is possible for the next.
The traditional way, in a paper book, is to fix the table as soon as the booking arrives. First come, first served: a booking arrives, someone picks a table, and that table is blocked for the length of the meal. For a quiet week this works perfectly.
Now look at what it does on a full evening. Three parties book on Saturday night, and the free table at that moment happens to be the table for six. They get it. A week later a family of six rings, and there is no table for six. The room has seats, but not in the right place for the people asking.
Or take two tables for two, booked separately for different parties. Then a party of four wants to come. Those four chairs exist, side by side, and the book says no. Had the two parties been placed differently, the tables could have been pushed together and four people would have been fitted in.
In both cases the system says "full", and in both cases a different arrangement of the same evening would have found room. The mistake was not made when the guest asked. It was made earlier, when each booking was fixed to a table before anyone knew what would follow.
You might say: then work it out when the phone rings. But the number of ways to arrange even a modest dining room across an evening is enormous. A person standing by the phone, with a guest waiting on the line, cannot work through them, and neither can a simple program that just takes the next free table.
What you can expect from a good system is simple to state. It fits more guests than a system that puts each booking at the first free table. It answers a guest within seconds. And it never moves guests who are already seated, or a table you have chosen by hand.
Here is one rule you can carry into any demonstration or sales call:
When the system says "full", is the evening really full?
A good system turns a guest away only when no arrangement of the whole evening can seat them. And it should not sell the same table twice. A system that turns guests away while a rearrangement would have fitted them is losing you covers you will never see. A system that sells a table twice is losing you something worse, which is trust.
Everything else, such as how the screen looks or how many reports it has, comes second to those two.
You do not need to run tests. You need answers about how the system is built, and a good supplier can give them in a few sentences.
If you want a fourth, ask how long a guest waits for an answer on the booking page. Seconds is the right unit.
Bientenu is booking software for small restaurants, and we built it around these principles. We checked it by simulation. These are Bientenu's own simulation results, not an independent study and not measurements from real restaurants, and they depend on the assumptions we made.
In about 125,000 simulated online bookings, there were no oversold evenings. And for a mid-sized restaurant, with 15 to 20 tables, the number of guests wrongly turned away was half what it was when tables were assigned booking by booking, first come, first served.
Want to see your own evening on one screen? See the demo or try it with your restaurant.
