Patent Application
20200356910
At conventional restaurants one of the most important problems is that guests and food are not being served in a timely manner which may result in a bad word of mouth leading to negative online reviews and a loss of revenue for the restaurant. This loss of revenue stems from the fact that tables are not being turned over as quickly as possible ergo few customers are served in one day. Also, customers experiencing these problems will not return which may further cause a decrease in future revenues. Further, because of poor service, restaurant Managers may have to issue complimentary food or drinks which leads to a decrease in profit margin.
In conventional restaurants poor service may occur because staff is too busy to wait on guests in a timely manner and staff are often not accountable for slow service. Guests are often frustrated with trying to flag their servers for help. Unfortunately, within conventional restaurants, Managers don't have the right tools to forecast and manage staff. In some instances, tables are taking too long to turn so waiting guests in the lobby may become fed up and leave. This results in a loss of revenue. Generally conventional restaurants use systems which are manual to manage tables and customers and result in an inefficient way to communicate between hostess, server, busboy, and manager.
Accordingly, there is a need for a table and waitstaff management system which enables improved response to customer needs. There is also a need for a system which provides more control for customers to have their needs met. As well, there is a need for a table and waitstaff management system that uses software, and sensors to monitor and determine customer needs and helps to provide table availability information to hostess and dining room staff.
An exemplary embodiment relates to a table management system. The table management system includes a host display device for displaying table placements within a room. The host display device includes more than one staff identifier device coupled to staff personnel and more than one table sensor including a communication device. The table management system also includes a server running a table management system algorithm and an aggregator device in communication with the server and in communication with the more than one table sensor. The aggregator device receives presence information and staff information from the more than one table sensor and communicating that information to the server. The server runs a software algorithm for managing table assignments and communicates table assignment information to the host display device.
Another exemplary embodiment relates to a restaurant table management system. The restaurant table management system includes a host display device for displaying table placements within the restaurant and a wait station display device for displaying table placements within the restaurant. The restaurant table management system further includes more than one staff identifier device coupled to staff personnel and more than one table sensor including a communication device. The restaurant table management system further includes a server running a restaurant table management system algorithm. Further still, the restaurant table management system includes an aggregator device in communication with the server and in wireless communication with the more than one table sensor. The aggregator receiving presence information and staff information from the more than one table sensor and communicating that information to the server. The server runs a software algorithm for managing table assignments and communicates table assignment information to the host display device.
Yet another exemplary embodiment relates to a method of managing tables within a restaurant. The method includes providing a host display device for displaying table placements within the restaurant and providing a wait station display device for displaying table placements within the restaurant. The method also includes coupling more than one staff identifier device to staff personnel. The method further includes identifying by more than one table sensor the presence of any customers and the presence of any staff and communicating by the table sensors to an aggregator device over a wireless communication link customer presence information and staff presence information. Further still. the method includes communicating information from the aggregator device to a server running a restaurant table management system algorithm and running a software algorithm by the server for managing table assignments. Yet further still, the method includes communicating table assignment information to the host display device.
In addition to the foregoing, other system aspects are described in the claims, drawings, and text forming a part of the disclosure set forth herein. The foregoing is a summary and thus may contain simplifications, generalizations, inclusions, and/or omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is NOT intended to be in any way limiting. Other aspects, features, and advantages of the devices and/or processes and/or other subject matter described herein will become apparent in the disclosures set forth herein.
The use of the same symbols in different drawings typically indicates similar or identical items unless context dictates otherwise.
Referring to
In accordance with an exemplary embodiment, each of restaurant staff (bus staff, wait staff, host staff, etc.) is equipped with an RFID badge. Each badge at a minimum is coded with a unique class ID according to the staff member's function (e.g., bus, wait, host, etc.). Each restaurant situation is configurable, for example some restaurants may not use a separate host or hostess or in other situations, there may be different levels of servers (food runners versus wait staff, e.g.) or there may be different levels of staff (senior staff versus junior staff versus training staff, e.g.). Each table may be configured with a table sensor 7 that is able to detect the presence of people at the table and further can detect the number of people at each table. Sensors 7 may also include RFID readers such that they can detect what staff is near each table and for how long. Information from each table sensor is communicated over WiFi or the like to aggregator 1 which sends the information over the internet (TCP/IP) or other communication network to server 2.
Server 2 runs algorithms, such as artificial intelligence algorithms (deep learning neural networks and the like) to achieve key performance indicators (KPIs) based on busy times and meals. In an exemplary embodiment there may be more than one aggregator 1 in a restaurant depending on the structure of the building. Each table and table sensor 7 has a unique ID so that the table may be easily identified. The information from the aggregators may be tied into any of a variety of off the shelf or customized table management software systems. In a further exemplary embodiment, information processed by AI engines in server 2 may be provided to administrators or managers in real-time using a restaurant management system 8. Restaurant management system 8 may be used by restaurant managers in real-time to identify problems and make changes to staffing, etc. on the fly or may be used by managers for tracking performance such that longer term changes may be made to staffing, etc. for increased efficiency in the longer term. In accordance with exemplary embodiments all of the electronics used in the table management system may be IP65 rated from the International Electrotechnical Commission (IEC) as published by the International Protection Marking IEC 60529 in accordance with the recommendations of the local restaurant association.
The table management system, as depicted in
Referring now to
Referring now to
Referring now to
Referring now to
The table management system may also include a feedback system that can be used by both guests and restaurant staff. A button or other triggering device is used to track and guide staff to wait on guest in a timely manner. The button may, e.g., be located under the table and will be use only by the staff Alternatively, the button may be located at the table and used by both staff and guests. Each buzz (press) of the button triggers that a server will get a code yellow warning (visually via display and audibly via a headset) when it is close to the end of an average time period for an event, such as an average time it takes for the guest to look over the menu and be ready to order. Then the server and manager will get a code red alert (visually via display and audibly via a headset) once each time period ends.
For example, in operation a host may seat a table of guests and then press the button. This alert for example will let the wait staff know that the guests are ready for an introduction from a server and possibly to take a drink order. Once the drink order is received, and the wait staff takes the food order from the guests, the button may be pressed by wait staff to send an indication that a food order has been taken. Once the food is ready, the wait staff delivers the food and then returns to take a dessert order after which the button is pressed to indicate where the guests are in the progression of the meal. Next, the server drops off the check and presses the button. The check is then finalized and the server presses the button indicating that bus staff can clean and prep the table for the next customer. The bus staff then presses the button to indicate to host staff that the table is ready for customers. In some embodiments, not only are restaurant staff able to press the button, but the guests are also able to press the button in order to call wait staff. In all cases, having not only a button but also an RFID reader at the table so that the system knows who is pressing the button. In some exemplary embodiments a centralized viewing monitor can be used by a manager to monitor all staff and tables. The manager may have communication with restaurant staff through a radio system.
Time in restaurant studies show that 40 minutes exactly is the optimal time for the highest profits and highest TIPS. The KPI goal for the owner/manager of the restaurant and the employees is how close does each table hit that 40 minute window.
Looking at that each table makes a certain dollar per minute, we know that the highest dollar per minute mark happens at 40 minutes and the highest tips are given at that time. So the KPI's become:
Showing the wait staff that the device/system can help them get more tips acts like a carrot making it more fun and a challenge for them. Also they are now rewarded by the customer not by the owner/manager. The owner/manger is optimizing his business, retaining employees (without bonuses) and improving guest experience.
In accordance with further and alternative embodiments, various features may make the system more readily useable for restaurants and restaurant staff. Some of these features include but are not limited to:
In development of the software for the aggregator and server Hash tables may include:
In some instances, one or more components may be referred to herein as “configured to,” “configured by,” “configurable to,” “operable/operative to,” “adapted/adaptable,” “able to,” “conformable/conformed to,” etc. Those skilled in the art will recognize that such terms (e.g. “configured to”) generally encompass active-state components and/or inactive-state components and/or standby-state components, unless context requires otherwise.
While particular aspects of the present subject matter described herein have been shown and described, it will be apparent to those skilled in the art that, based upon the teachings herein, changes and modifications may be made without departing from the subject matter described herein and its broader aspects and, therefore, the appended claims are to encompass within their scope all such changes and modifications as are within the true spirit and scope of the subject matter described herein. It will be understood by those within the art that, in general, terms used herein, and especially in the appended claims (e.g., bodies of the appended claims) are generally intended as “open” terms (e.g., the term “including” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “includes” should be interpreted as “includes but is not limited to,” etc.). It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases “at least one” and “one or more” to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim recitation to claims containing only one such recitation, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an” (e.g., “a” and/or “an” should typically be interpreted to mean “at least one” or “one or more”); the same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should typically be interpreted to mean at least the recited number (e.g., the bare recitation of “two recitations,” without other modifiers, typically means at least two recitations, or two or more recitations). Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, etc.” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., “a system having at least one of A, B, and C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). In those instances where a convention analogous to “at least one of A, B, or C, etc.” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., “a system having at least one of A, B, or C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and/or A, B, and C together, etc.). It will be further understood by those within the art that typically a disjunctive word and/or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms unless context dictates otherwise. For example, the phrase “A or B” will be typically understood to include the possibilities of “A” or “B” or “A and B.”
With respect to the appended claims, those skilled in the art will appreciate that recited operations therein may generally be performed in any order. Also, although various operational flows are presented in a sequence(s), it should be understood that the various operations may be performed in other orders than those which are illustrated, or may be performed concurrently. Examples of such alternate orderings may include overlapping, interleaved, interrupted, reordered, incremental, preparatory, supplemental, simultaneous, reverse, or other variant orderings, unless context dictates otherwise. Furthermore, terms like “responsive to,” “related to,” or other past-tense adjectives are generally not intended to exclude such variants, unless context dictates otherwise.
