The Failures of Existing Booking Systems

For over 20 years since OpenTable started the first online restaurant booking system, all online restaurant booking systems have to use the same basic technique for the allocation of bookings to tables, and just like the fly in Wittgenstein’s bottle, the best they have done is to continue banging their heads on the glass.

The other thing history has taught us is that 20 years is a long time for technology to remain unchanged. Time and innovation stay still for no one.

The problem with previous attempts to improve online booking allocation processes, methodologies and techniques is the continued use of the same framework. So, after 20 years of attempting to improve booking allocations using the same framework without success, we can safely say is that like the fly that was trying to get out of Wittgenstein’s glass bottle. It continued to fly towards the base of the bottle as that was the direction that the sunlight was coming from.

Failure 1: Creating a list of all tables to set up

What all existing online restaurant booking systems do is wrong as they first create a list or pool of all the tables set up in the restaurant. Then they refine that list or pool by noting which tables can be joined together to create a list or pool of all table and table combinations. Obviously, this list or pool of tables, must all fit into and within the restaurant space in any of the potential table or table combinations, otherwise, the allocation system can allocate more bookings that are physically possible within the space.

By definition, the list or pool of tables and table combinations can create different sizes of table combinations, such as 4 tables for 4 people or on a table for 16 people, the combination for 16 people utilises less floor space as gaps are no longer required between the smaller booking sizes. This being the case, the use of table combinations for different booking sizes is inherently space inefficient.

However, these manually created pools of tables and table combinations from which a booking allocation is made are wrong on many levels. Before we review the process and methodology of how the bookings are allocated. First, we do not know the composition of the booking requests before they arrive, hence, any list of tables and table combinations manually created cannot be an optimised solution. At best, what any allocation system can do is attempt to optimise booking allocations within the inefficient list or pool of tables that it has. Secondly, as the list of tables and table combinations is manually created, there is no check or balance to ensure that the list or pool of tables and table combinations has been created properly, to begin with.

Failure 2: Use look-up formulas or search algorithms

The next thing all online booking systems attempt to do is to use look-up formulas or search algorithms to find a table or table combination of the “right-size” to allocate the booking to. This approach is also inherently wrong as a search algorithm can only return a correct answer. It does not have any additional process to predict the future or understand unknown events such as what the next or future booking sizes will be to better allocate the current booking request.

For example, if a booking request is received for a table of two and there are 20 empty tables of two available, search algorithms do not have the ability to determine which table provides a better allocation solution with respect to other future booking requests. As such, existing online booking systems have simply adopted one of two different approaches which are both wrong.

First, the allocation is made at “random” if there is more than one available table, which offers no benefit. Secondly, the 20 tables of two would be placed in a priority list and the table of two at the top of the priority list is the table of two selected for the allocation. While some may argue that the priority list offers a better solution, it is still wrong. This is because the priority list is static, does not change and does know what order future booking requests will come in, what number of people each booking request may be seeking and the quantity of those future booking requests.

In practical terms, either the random booking allocation process or the priority list allocation process is in effect “random” as future booking requests and the details of those future booking requests will always be unknown.

Failure 3: Use of 2D Gantt chart framework

The further significant problem that all existing systems do is that they use a 2-Dimensional Gantt chart framework to introduce the element of time to the allocation process. Within this 2-D Gantt Chart framework, the tables and table combination list by necessity are then placed on the y-axis and time is placed on the x-axis. The problem with the use of a 2-D Gantt chart is that it is easy to understand when one considers that placing tables on an axis means that the tables form part of the allocation framework such that the tables then become fixed and cannot be added to or removed during the allocation process. Clearly, this is not what happens in real life and as part of normal restaurant operating requirements.

To put it another way, placing tables on an axis is the same as taking a 2-Dimension environment being a floor plan that comprises a length and a width where tables can be moved and rearranged within the 2-D environment and compressing that 2-D environment into a 1-D single fixed linear list. It simply does not work!

Their Unrealistic System

As such, all existing systems are limited to a framework that is not realistic and a framework that is an incorrect and inefficient representation of the real-world environment from which to apply non-optimal allocation processes that are linear and fixed even before they are applied to the inefficient 2-D framework. The inefficiencies of the existing 2-D frameworks and allocation processes result in the following unacceptable outcomes: 

• The allocation of bookings by being at “random” and unrelated to future unknown bookings result in “booking fragmentation” whereby empty tables are trapped between booked tables creating allocation inefficiencies.
• Existing system booking allocations by being made at “random” means that the allocations cannot be maximised or optimised.
• Existing systems can easily start rejecting bookings when a restaurant is only 60% – 65% full as a result of booking fragmentation.
• Existing systems are incapable of differentiating tables such as window tables to other tables, without segmenting the linear list of tables as placed on the y-axis. The curse of segmentation in these circumstances is that the allocation process will be split into smaller groups, such that booking fragmentation will increase resulting in even less optimisation and further increasing the number of bookings rejected.
• The inability to further segment and gives attributes to tables means that a key requirement of yield management being product differentiation cannot be applied to existing online booking systems.
• The inability to control capacity by adding, removing or rearranging tables is another key requirement for yield management that existing systems cannot offer.

The problem with all prior attempts to solve these problems is they all focused on the same wrong framework and tried to make it better. Such as trying to build better search algorithms in the same wrong 2-Dimensional framework. 

Luckily, our founder Peter Petroulas thought differently and did not continue hitting his head against the base of the glass bottle like the fly in Wittgenstein’s fly bottle thinking the direction of the sunlight offered the correct solution.