Touchless Dining

COVID-19 has brought enormous misery to the hospitality industry, but it has also had some silver linings. One area that will likely be forever changed is how consumers choose, order, and pay for food away from home. There are hundreds if not thousands of mobile solutions serving restaurants around the world. Most of them did not exist just a year ago. This has of course been pandemic-driven, as a way to reduce COVID transmission risk. But in the process, restaurants and diners alike are finding some great advantages with the new solutions, many of which will survive post-COVID.

For now, most restaurants and diners want to minimize the need for physical interaction between staff (servers, hosts, cashiers) and customers, as well as the need to touch anything that could carry infection (such as menus, pens, checks, and credit cards). Mobile solutions are finding interesting and innovative ways to accomplish this.

In addition to addressing health and safety concerns of diners and staff, many of these solutions offer significant operational cost savings. One solution provider told me that some of their restaurant customers now see mobile solutions as allowing them to convert much of their traditional wait staff into runners, with substantially lower total labor requirements. The only thing still requiring human interaction might be the delivery of the food itself (and yes, robots may soon be doing that). The hygiene-driven desire to avoid contact may dissipate in the post-COVID world, but in the meantime, restaurants are finding that the new tools can also improve key aspects of the experience for diners, and provide operators with a more effective and consistent way of upselling. Both of these benefits will likely persist after COVID.

Today I want to explore some of the mobile food and beverage solutions, with particular focus on factors to consider when you are evaluating one for hotel restaurants. Most of the products on the market have been designed for table service, quick-serve, fast-food, and delivery/takeout restaurants, not for hotel restaurants. And while many of the requirements are common, hotel restaurants have some that are not found in standalone and chain restaurants, and that are not supported by most of the available solutions on the market.

The ones I will mention here are among the stronger ones I have seen for customer-facing mobile hotel food and beverage applications, and I include them not as recommendations (every situation is different and some may be impractical for any given operation), but rather as useful reference points for understanding the state of the art. None of them does everything I would like, but they all cover the more important requirements, and each offers some unique features. I would recommend including them all in any initial evaluation, along with solutions that may be offered by your existing point-of-sale (POS) or mobile app provider, and others that cross your radar. I promise I have not looked at everything out there, and I am sure I missed some good ones!

First, the basics. The best solutions require no app download, can be customized to the brand’s look and feel, and can be invoked easily and without advance planning (such as by scanning a QR code). They can display a menu with up-to-the minute pricing, photos, and availability. They allow diners to enter orders and send those orders directly into the restaurant’s point-of-sale (POS) system. They accept all relevant forms of payment, and they offer an application programming interface (API) or other means for embedding the solution within an existing mobile app.

One key consideration is the degree of integration with the POS. These are questions you should ask even if you are looking at a mobile solution offered by your current POS vendor, in most cases the mobile solutions were afterthoughts. A must-have is that the POS pricing model is used in its entirety: base prices, add-ons, taxes, gratuities, and discounts must all be calculated identically in order to avoid reconciliation nightmares. It’s highly desirable – and possible with a few POS systems – to have the entire content database maintained in one place: this means the short item descriptions that appear on the waitstaff application, the longer ones and full marketing descriptions that the diner needs to see, the photos, and of course the pricing. For pricing calculations, the mobile app should be able to utilize the POS API rather than trying to replicate all the logic.

Many older POS systems don’t store the photos and long descriptions, meaning that at least these elements of their mobile solution will need to be maintained separately. This can be cumbersome and time-consuming, so if it’s necessary with your POS, look at the process carefully. Failing to make changes in both systems simultaneously can easily lead to a poor diner experience and lost revenue opportunities for the restaurant. To address this issue, Oracle’s Simphony system recently moved to a single store of all menu data that is accessible through a new cloud application programming interface (API).

While Oracle does not yet offer its own mobile menu/ordering solution (it plans to release one next month), the API is well supported by third party apps such as ones from BookingTek and SevenRooms. Agilysys’ IG OnDemand uses its internal menu items but maintains pictures and diner-facing descriptions in a second database; a common dashboard simplifies the concurrent updates. The xnPOS system from Xn protel, which entered the US market about two years ago, uses a single cloud database for both its staff-facing and new guest-facing (xnPOS Go) versions.

In evaluating solutions, hotels should consider every mobile ordering scenario they need to (or might want to) support. You may first think about order-at-table and room service situations, but most hotels have (or could have) at least a few others, such as takeout or pickup (especially with COVID), kiosk ordering (particularly for high volume Grab-and-Go outlets), lobby lounges that are not formal restaurants but where food can be delivered, meeting rooms, poolside or cabana service, digital signage (common in some select-service cafeteria-style breakfast restaurants), and local delivery (either by hotel staff or via third-party apps such as Uber Eats or Doordash). Whichever of these you need to support, you need a consistent menu, database, pictures, and pricing across them all.

Many of these scenarios may play out for both immediate ordering or for delivery or pickup at a specific future time. Dine-in applications require the ability to organize an order into courses, which many self-ordering solutions do not support. Table-service ordering should make it easy for one diner in a party to request an appetizer to be served as the main course, another challenge even for some solutions that do support courses. For pick-up orders, a great feature is being able to automatically text the guest as soon as the order is bumped, so that they can maintain social distance while waiting. Finally, hotels that have their own mobile apps may want to consider how easy it will be to integrate menus, ordering, and payment into that app.

Location detection is critical; it doesn’t work to have a guest submit an order and expect it to be brought to them, if you don’t know where they are. Evaluate solutions based on their ability to easily identify where the diner is, whether in the restaurants, in a guest room, poolside, or elsewhere. While there are different ways to do this, the most common approach is a QR code that can be scanned and that identifies the specific table, guest room, meeting room, or public area. Another option for room service is if the ordering app is embedded in the hotel’s mobile app, in which case it can be possible to identify the guest’s room number from the app (but you may still need to give the guest an option to override it if they are somewhere other than their own room).

For table service, integration of a virtual waitlist can be a big help in reducing congestion at the host stand. Solutions such as SevenRooms can text the party when their table is ready, and even push them the menu or special offers while they are waiting, then automatically open the check for the assigned table when they are seated. For guests in a hurry, it can be a benefit to be able to place their order while they are still waiting for a table.

Whenever ordering is mobile, you need to consider that the normal means of managing to the kitchen’s capacity is now gone. The sudden arrival of 100 hungry patrons a half hour before the kitchen closes won’t encounter the usual human buffer to say “no”. This means your mobile app needs to either be able to throttle the number of orders or items to some preset limit, or (better) be connected to the kitchen display system so that it can assess capacity (and prep time) in the moment.

Another important consideration is payment, and this is where most of the restaurant solutions fail in hotels, because most do not support room charges. To get the maximum benefit of mobile ordering at every outlet, there also need to be options for in-app payment via credit or debit card, Apple Pay, Google Pay, Samsung Pay, or Paypal; depending on the customer mix you may well need others such as Alipay or WeChat Pay. These will need to either integrate with your existing payment gateway and acquirer, or process through the vendor’s partner (in which case you will need to consider whether the reporting can be easily reconciled with your POS). Tipping needs to be supported, with reporting that can be exported into any back-end payroll and tax solutions that may require it. An open tab option is a common requirement in bars and sit-down restaurants; it should also be possible to issue a credit against a closed check by using a saved token rather than having to start a new transaction.

Some solutions may require you to use the designated payment partner for all transactions, which may or may not be practical with your existing POS and payment setup. Others will allow you to continue to use your current setup for card-present transactions and require theirs only for e-commerce transactions. Integrating mobile pay with your existing payment providers can be difficult and time-consuming and can often create security risks, so using the solution’s preferred payment process for e-commerce payments may well be the most practical choice even if it results in a slightly higher discount rate. Some solutions enable brands operating from multiple locations to consolidate transactions into just one e-commerce merchant account per country, which can significantly reduce deployment time; otherwise it is typically necessary for the owner of each hotel or restaurant to get involved in opening the account for their location – meaning the operator has to track each owner down, convince them why it’s necessary, and get them to complete the notorious Know-Your-Customer paperwork.

Functionality also needs to consider scenarios such as splitting checks, and diners joining other diners and either combining checks or maintaining separate ones. One interesting settlement feature that IG OnDemand offers is a paper check with a unique QR code; the waitperson in a table-service restaurant can deliver that to the table, then the diners can scan the code to pay. They don’t ever need to touch it, or a pen, or share a credit card, and they don’t need the server to come back to complete the transaction.

Many of these mobile ordering features are designed to minimize the need for the diner and staff to interact physically and are specific to COVID; some also provide better service options or operational benefits that will be useful post-COVID. Other ideas come to mind here as well. Not yet common, but on the horizon, is table-service functionality that can enable both the diner and server to interact with the same order in real time. This addresses the scenario where the diner orders via the mobile solution, but then decides on a change after a discussion with the server. The server should be able to make the change without forcing the guest to go back into an unfamiliar system themselves.

Another feature I was looking for but haven’t yet seen is the ability to use the same app to request something from the server, such as replacement utensils or additional condiments. This requires a means for alerting the server in real time, which most systems don’t yet have. And as long as COVID remains a risk, some diners (and servers!) might also like the option to intact with their server via video rather than physically at the table – I have seen this with hotel check-in but it could equally make sense for restaurants.

Another point of differentiation is integration of customer data. Maximizing upsell opportunities within an ordering solution should ideally use a 360-degree view of the customer, which means two-way integration with the hotel’s customer relationship management solution – what they purchase in the mobile app should be used to enhance the guest’s profile, and the profile should inform the mobile app on what might be a successful upsell offer. SevenRooms’ out-of-the-box integration with solutions like Cendyn and Travelclick provide a significant advantage in this regard.

Don’t ignore ways you can use the technology to generate more revenue. If it uses QR codes, think about where you can put them to drive more sales, for example to suggest a smoothie for a guest who’s just finished a workout in the fitness center.

Pricing models differ. Some solutions charge a subscription fee, others take a percentage of sales, or offer a choice or mixed model. There may or may not be charges for API access or integrations. Some providers, such as BookingTek, offer the solution for free to the restaurant but earn a portion of the payment transaction fees from the acquirer; this could be very attractive to cash-strapped hotels.

Solutions like these are rapidly re-engineering the operational models of restaurants everywhere. Pay attention not just to how they can help you survive COVID, but also to how they can enable you to run a more profitable food and beverage operation, with greater customer satisfaction, afterwards.

‍