‍

Every so often, innovative technology solutions emerge not from new ideas, but from combining existing products in new ways. The result can often enable a re-engineering of the business process, compounding the benefits.

This week, I will explore recent innovations that support new and better processes for ordering and payment in hotel restaurants. What I will describe is available from multiple vendors in the market. But because it requires shared hardware for point-of-sale (POS) and payment card processing, it is only feasible today for a small number of hotels that have (or are willing to buy) supported combinations of POS and payment processors. But the impact for many hotels is so significant that both hotel brands and POS and payment vendors have taken notice. As a result, the list of supported combinations is expanding, and I expect this capability to be much more widely available within the next year or two.

I will explain the technology, the benefits, and the key features to consider in discussions with your vendors. I will not cite specific vendors here, both because most hotels are constrained to using their existing POS and payment providers, and because many of the ones that are not yet supporting this kind of capability have it on their near-term roadmaps. This article can help set the agenda for discussions with them.

The new solutions apply to any hotel with a table-service restaurant, whether casual or fine-dining. It can also apply to many bars and lobby lounges. The busier the outlet, the greater the benefit.

The Concept

The basic concept starts with combining two devices into one: specifically, a handheld restaurant ordering that is also a pay-at-table device. The device’s core capabilities of processing, touch screen, and wireless or cellular connectivity are shared between the order-taking tasks managed by the POS system and the payment processing tasks handled by the payment partner. The payment processing provider fully controls the payment hardware and software, and these are segregated from a security standpoint so that the POS system can remain outside the scope of Payment Card Industry (PCI) security requirements.

Why It Matters

Historically, restaurant wait staff are constantly running back and forth. Let’s consider a typical process, repeated for each cover. Your restaurant may vary the specifics a bit, but many of these steps are universal for restaurants that are not using this newer approach.

• Server takes order at the table (repeated for each course)
• Server goes to the POS terminal to enter the order (each course)
• Server goes to the kitchen or bar to pick up the order (each course)
• Server goes back to the table to deliver the order (each course)
• Server goes back to the POS terminal to close and print the check
• Server goes back to the table to leave the check
• Server goes back to the table again to collect the payment
• Assuming use of a payment card, server takes the check and card back to the POS station to process the charge
• Server returns to the table to leave the charge receipt for the diner to sign and add any tip
• Server returns to the table once more to pick up the completed check
• Server returns to the POS terminal to close out the check with the tip.

Whew, that’s a lot of steps! And each of them takes time (meaning cost to the operator) and pulls the wait staff away from the dining room, where they could be better serving customers, suggesting drink refills, or selling additional food items. It also slows down the pace of service for diners, who must often wait for their server when they need them.

The new solutions enable a very different operating approach, at least for busy operations. Equipped with a mobile device that can place orders and accept payments, the server can spend most of their time in the dining room, checking on and interacting with diners. Runners can be used to efficiently deliver food and drinks to the table.

When the server greets a table, takes drink orders, and recaps the menu, the drink order is already being prepared by the bar and in some cases might be delivered even before the server leaves the table. And the diners are never left waiting for the server that has been sidetracked in the kitchen, or having to flag down another colleague, who must stop what they were doing to alert the right server. The early experience of restaurants using this technology shows that server availability and quick response can significantly increase the check size, particularly for beverage rounds.

Many POS systems and some third-party vendors already offer handheld ordering devices. Similarly, most payment system vendors offer pay-at-table options. Neither are yet common in hotels, especially in North America. But it is the combination of the two, which I have only seen within the last year or so, that is particularly powerful. It enables wait staff to actually wait on customers (rather than forcing customers to wait for the server!).

Evaluating the Options: The Basics

At its most basic level, the key product attributes are the ability for the wait person to:

•  enter an order on the handheld terminal and have it instantly delivered to the kitchen or bar;
• display and (if desired) print a check for the diner to review;
•  allow the guest to add a tip;
• process card payments on the ordering device (ideally via all options: tap, dip, or swipe);
• validate and post room charges; and
• print or send a receipt.

Room charges are challenging for many vendors to support. They are not technically necessary, but a major convenience for many guests. Business travelers want to submit a single receipt to their employer for reimbursement. I recently stayed at a hotel that had a reasonably nice restaurant, but they did not support room charges. At the end of my stay, I walked out with one invoice for the room and eight separate checks for meals. I did not appreciate all the additional paperwork that caused me when I got home, and while my stay was otherwise fine, I will probably not stay there again if I return to that city.

While less essential, it is also useful for the server to be able to see the preparation and delivery status of orders (especially since they will no longer be passing by the expo as frequently, and will lose the associated visual cues). This could be via an on-demand query, or the system could push notifications to the server’s device. I have not seen this feature in any product yet, but I have heard the need. It may require new integrations with a Kitchen Display System and/or the ability of runners to confirm that they have picked up an order.

Interaction with Self-Ordering

If you are evaluating solutions, there is a related set of capabilities that may be important to any restaurant that wants to enable the option for, or to require, self-ordering. Even for a fine-dining outlet that does not want to offer self-ordering in the dining room, it may be useful for room-service or takeout orders. Other restaurants want to minimize staffing requirements and will want it to be the default option. For most, however, it can and should simply be the guest’s choice: some will prefer self-service and the reduced dependence on finding a server at each stage of the meal, while others will want personal interaction with the server.

There are many self-ordering solutions on the market, but very few (yet) that really support the level of integration required to make the whole process work seamlessly.

We are all familiar with the basic interaction: the guest typically scans a QR code on their phone, views a menu, and places an order. Basically all systems can do this, but beyond this, the differences are significant.

The first question is whether the order is automatically entered into the POS system, either via an Application Programming Interface (API) or natively. If it is simply printing on a kitchen or bar printer, then someone will need to re-enter it into the POS system manually, and until they do, the server will have no visibility of the order and will, for example, be unable to address inquiries or requests from the diner, or to add or amend items – and this is a step backwards, not forward. For seamless service, the server’s device should reflect a diner-placed order (and subsequent changes) instantly, and the self-ordering app should also display any changes made by the server.

For this to work consistently, anything that can be self-ordered by the diner needs to be mirrored exactly in the POS system, including items, modifiers, combos, prices, and coupon codes. Without this, you will be constantly struggling to update two separate databases every time a menu item or price or tax rate changes, and errors will be inevitable. Additionally, items that have run out should not be offered on the self-ordering screen.

If the self-ordering functionality was developed by a third party rather than by the POS provider, the pricing and running total should also be calculated by only one of them. Usually, the POS is responsible for this, in which case the ordering app should receive the line item charges, tax calculations, and total from the POS system. But it can also work for the mobile app to calculate these and override amounts in the POS system. Without this, discrepancies will occur more often than you want. You need the final prices and check total that the diner sees to exactly match what was calculated when they placed the order. This will only work consistently if one system is the system of record for the financial calculations.

The self-ordering app should support check close-out, addition of any gratuity, and payment in the same way as the server’s device, except that (because it has no card reader) it will be limited to mobile payment options such as Apple Pay or Google Pay.

While the underlying menu structure and pricing need to be identical, self-ordering apps need very different content and navigation than mobile devices used by wait staff. They should be focused on merchandising what you have to offer and an intuitive user interface, whereas server-facing ordering apps usually focus more on speed of entry.

This means photographs (perhaps even videos for certain dishes), richer text descriptions, nutrition and allergen information, and (where appropriate) support for multiple languages. Filtering options for dietary preferences and allergens are a common and useful enhancement, so that diners do not have to wade through a long list of items to find the ones that match their needs. Upsell suggestions (“would you like a side of fries with that”) should be delivered consistently. While some of this functionality can be useful for wait staff as well (particularly if you have high staff turnover), the more seasoned ones will need it only occasionally; they don’t want to have to scroll through long descriptions of items they already know well.

For all but the most casual restaurants, both the ordering app and the mobile POS device should support diner seats or names, the ability to share dishes, and check-splitting, and should do these things in a way that is reflected consistently on both applications. Wait staff who take orders manually already do this and recognize it as an important element of good service; replicating it when the order is placed digitally can help avoid confusion over “who ordered what” when the food is delivered, especially if it is by a runner rather than the order taker.

Socializing with Wait Staff

Handheld ordering devices and mobile self-ordering can improve service and reduce costs, but like many workplace changes, can raise concerns with staff that automation may be replacing their jobs. Managers should not underestimate the need to manage the process, but evidence is strong that, properly introduced and socialized, most wait staff (and especially star performers) will not only adapt but will quickly come to prefer this approach.  With guests able to communicate with servers in real time, requests or problems can be dealt with much more quickly, improving service levels, and the need to wait multiple times just to close out the check and pay are eliminated. Faster order placing means larger ticket sizes, and larger ticket sizes and better perceptions of service lead to larger tips. And for many tables, less time spent closing out checks after the meal is done can mean faster turnover and more covers.

Restaurants that have successfully implemented this approach have said that involving their key front-line staff in the process from the outset was a key to success. Where possible, participation in pilots should be voluntary; let the most eager adopters help persuade the skeptics. Where tipping is the norm, the better waitstaff often end up taking home much more than before, and become champions to help persuade the more reticent ones.

A key to success is rearchitecting the operational flow to split responsibilities between waitstaff, who should normally be stationed in the dining room, and runners delivering the food and drinks. The waitstaff may get engaged for several minutes with a large table placing a complex order, and while they are, they will be unable to deliver food or drinks that is ready. Having dedicated staff just for delivery means less waiting by guests, better perceived service, and the potential for more rounds of drinks or add-on food items. And because delivery (unlike order taking) is usually quite quick, the runner can be back at the kitchen or bar quickly to pick up the next ready order.

Conclusion

Fundamentally, most hotel restaurant operations today still operate much as they did decades ago, with the financial aspects having moved from pen and paper to POS systems, but with very few other operational changes. Today’s wireless technology and applications enable a much more agile and diner-friendly operational design, where your revenue-generating staff are maximizing their time with guests, where guests can either order themselves or quickly summon staff, where food and drinks are delivered faster, and where diners generate the largest possible checks.

Is it time for your restaurant operations to move into the 21^st century?

As always, feedback to my articles is welcome. Since the host site does not support discussions, I will post a link to this article on my own LinkedIn page once it has been published, and I invite you to comment, like, or share from there!

‍