Mobile food and beverage ordering has been around for a few years, but the pandemic has moved it into the mainstream, and diners are increasingly happy with it. The initial impetus was to reduce face-to-face contact and potentially contaminated shared surfaces. That imperative waned as vaccination rates increased and as the mode of virus transmission became better understood. But more recently, mobile ordering has been driven by severe labor shortages in hospitality and the inability of many hotels and restaurants to hire enough staff to return to the traditional operating model.

Additionally, many diners who have now experienced digital ordering have found that they prefer it, at least much of the time. Research by Crave Interactive from early 2021 shows that 91% of diners think service is as good or better with mobile ordering (44% say “better”), and 81% want to continue using mobile ordering and payment post-COVID. While the numbers will vary based on who is being surveyed, this follows the trend of consumers using their mobile phones for more and more aspects of their life every day, from banking to shopping to travel.

This week’s blog takes a deep dive into mobile digital ordering (MDO) solutions for restaurants, with a special focus on hotel restaurants.

Is Mobile Digital Ordering Right for You?

There is no simple answer to this question. Some higher-end restaurants may choose to retain traditional menus and wait-staff service to preserve ambience. Many will adopt MDO but retain printed menus to give diners a choice. But there is a compelling case for MDO in many hotels, where it can allow the restaurant to sell more via room service, at the pool, in cabanas, in the lobby, in meeting rooms, or via local delivery.

Bars and pubs that may previously have had no printed menus may generate more revenue from the more structured item positioning and upselling options available through MDO. Restaurants with experienced, first-rate servers may already maximize upselling and cross-selling, but others with less experienced staff often find that digital menus can do this more consistently. Restaurants with staff shortages may need to address slow service, while busy bars may find that patrons may order more rounds if they can reorder without having to flag down a server or leave their conversation to crowd up to the bar.

To be sure, MDO has costs and complexities, many of which I will address below. The important thing is to understand what you want to accomplish, how much you expect it to be worth in additional revenue, cost savings, or customer satisfaction, what it will cost to achieve that, and the risk involved in getting there. Establishing KPIs up front and measuring their achievement is an important key to success.

Market Overview of Mobile Digital Ordering

There are hundreds if not thousands of MDO products on the market, few of them more than two or three years old and, not surprisingly, most of them having appeared since the start of the pandemic. Most of them focus primarily on a single sector, such as large restaurant chains, stadiums, bars, pubs, independent restaurants, nightclubs, or hotels. Many are limited to a single country or region. The vast majority are independent of any particular point-of-sale (POS) provider and offer some level of integration with at least a few of the more common systems used in their markets. A much smaller (but growing) number are offered as add-on modules by POS providers.

Hotel restaurants present unique challenges because of the need for the MDO platform to support room charges, room service, and delivery to other public spaces. It must also usually work with the hotel’s existing payment infrastructure, which may already be shared across the POS, property management system (PMS), and retail and spa systems. Only a small fraction of the MDO providers can support hotels, and they may work only with specific POS systems, PMSs, and payment gateways, meaning that the choices for a given hotel may be quite limited. A few hotel-capable POS providers, including Agilysys, Shiji, and xnPOS now offer their own MDO solutions, which can natively and cleanly provide integrated ordering, payment, server support, and kitchen operations. These are typically easier to set up (less dual entry of menu items) and provide better coordination between the diner, the server, and the kitchen and bar.

I expect more hotel POS systems to follow this trend; I am sure MDO is on the roadmap of many. If your POS has its own MDO solution, it is likely to offer significantly better operational results because of common database and transactional design and/or tighter integration, and it should be high on your list for consideration. However, the DNA of most POS systems is based on a server-centric selling model, and as a result most of them have less experience with digital marketing (menu management, cross-selling, and upselling) than the more established third-party solutions. There may well be tradeoffs between the operational benefits of using your POS’s MDO solution vs. the incremental revenue opportunities available from some third-party products. This gap may shrink over time as the POS providers get more experience with the direct sales model used in MDO.

Today, most hotel-capable POS systems still require third-party MDO solutions. Even Oracle, whose Simphony POS has the largest share of the global hotel restaurant market, has historically supported only third-party solutions. This may now be changing; just last week, Oracle acquired GloriaFood, a Romanian company with an online marketing and ordering platform, which may presage a future offering of a Simphony MDO product.

MDO pricing models vary. Some are traditional SaaS subscription models, others use revenue-share, a transaction fee, or a combination, and still others claim to be “free” but require the use of their preferred payment gateway, from which they earn a commission.

Key Considerations in Selecting an MDO Solution

I spoke with key executives at several companies that offer MDO solutions to get a better understanding of best practices, and what restaurants may wish to consider when evaluating their options.  There were far too many to talk to them all, so I tried to cover a representative sample, which included Crave Interactive, Nonius, RoomOrders, and wi-Q, as well as the POS providers with MDO solutions mentioned above.

There were many common themes, which I will address in the balance of this article. But each company had a distinct emphasis based on its business model, architecture, features, and integration approach. Some are more focused on revenue generation, some on guest experience, others on operations. Of course, these are interrelated, but no single product I saw would get top ratings on all three aspects.

The MDO landscape is still quite young, and none of the companies I spoke with can do everything. A few items mentioned here may not yet even be available in any commercial product, but they are on future roadmaps or wish lists. And to be sure, not everything will matter to any one hotel or restaurant, but each reader can decide what is important to them.

App Design. There was broad agreement that for most diners, a Progressive Web App, invoked by a QR code (or alternatively a tap by an NFC-enabled phone), was preferable to a native app. Most diners will not download an app for a single ordering experience. Regular customers may, however, prefer one, especially if it has a loyalty component, so a white-label native app or a Software Development Kit that enables MDO within a brand’s native app (or in-room tablet, etc.) can be useful options. A progressive web app can provide an option to download the full app and is therefore a useful bridge for first-time users.

The QR code or NFC tag is typically used to identify the diner’s location: table, guest room, lobby area, meeting room, pool area, or elsewhere, or a generic QR code can be used for delivery or pickup. Room service orders may use the QR code or the room number and guest name instead (or if embedded in a hotel app, the app itself may identify the room).

Everyone stressed ease of use for the diner: navigation should be simple and intuitive. Beyond this, there were significant differences: some were more transactional (essentially a digital version of the printed menu) while others were much more focused on visuals, menu item placement, upselling and cross-selling, and easy payment options.

The app should consider accessibility. ADA requirements in the United States and similar regulations elsewhere can impose significant fines for deploying apps that lack the required features for use by those with disabilities. This is an important item to check especially if the provider has a limited presence in your jurisdiction and may still be unaware of the requirements.

From a security standpoint, diners’ mobile devices should communicate directly only with the cloud host, not with local systems at the hotel or restaurant. This can be challenging if the posting interface to the PMS is on-premise. If mobile devices do need to communicate with local systems, a local firewall will be required, and it should be configured and remotely managed by security professionals to minimize the potential for breaches.

Revenue Maximization. Several of the providers cited features and design considerations that could help increase revenues and profit. There was some agreement that it was difficult to measure the exact uplift due to the impact of COVID, which changed diner behavior especially with respect to room service ordering. But the general expectation was that a typical restaurant might get a 10-15% increase in revenue and profit from a combination of menu engineering (prominent placement of popular or high-margin items), marketing (pictures and descriptions), personalization (filtering for dietary preferences and restrictions, or based on past orders), and flexible pricing. Hotels with limited in-house dining options may also benefit from MDO platforms like RoomOrders, which can also provide guests with connectivity to local restaurants that can deliver to the hotel (and earn a commission for the hotel).

The biggest revenue impact was reported in bars and pubs, where menus may have been previously nonexistent or written on a chalkboard, where patrons may have to go to the bar or counter to order, and where staff are often not strong at upselling (or lack many opportunities to try). One MDO provider reported that the number of drink rounds and snack sales went up substantially in busy bars because patrons did not have to crowd up to the bar or flag down a server; they said they were also able to upsell extra shots much more easily.  Breakfast restaurants reported a significant increase in specialty coffee sales when it was offered as an upsell option to the standard coffee inclusion.

Depending on the level of POS integration, many MDO solutions can also implement flexible menu presentation and pricing, based on time of day, day of week, or special events. Flexible pricing is commonly implemented as discounts or loyalty-point promotions rather than surcharges. These can be supported for mobile ordering even if the POS cannot mirror the same schedule (albeit with potential consequences as noted in the section about POS interfaces below).

One important aspect of menu engineering is the importance of A/B testing, where small menu variations can be tried to see what works best. On a random basis, half the patrons see the menu one way, while the other half see it a different way. Over a reasonable sized sample, this approach provides a very accurate measure of which presentation is more effective, and by how much – it is not biased by differences in timing, location, sampling, or other factors. From a menu optimization standpoint, the best MDO solutions offer extensive A/B testing capabilities that can help hotels understand how to optimize their menus.

Dining Mode: MDO solutions offer varying levels of support for different situations, several or even all of which may be relevant for a particular restaurant. These include dine-in; takeaway; pickup; room service; delivery to a meeting room, pool, beach, or lobby location; local delivery by the hotel; and third-party delivery. Each of these may require a specific sequence of events and have rules regarding things like when the payment method is collected; whether, when, and for how much a payment is authorized; whether and when any tip is added; whether an open tab can/should be maintained; how an open tab can be closed; whether a signature capture is needed, and when the payment is processed. The right choices need to be offered to the customer at the right point in time. Each outlet should consider each relevant scenario, map out their desired sequence, and verify that solutions being considered can be configured to handle it appropriately, or that workarounds exist.

Some situations may require additional steps. A dine-in customer requesting a room charge may, for example, enter their name and room number on the payment screen, but the MDO system will usually have to request the POS to post the charge to the PMS. The POS may get an error from the PMS if the guest mis-typed their room number, in which case the MDO system will need to report the problem and request that the guest re-enter the correct information. A local delivery request may need to check that the location is within the delivery area and calculate a delivery charge, which may depend on distance. A curbside pickup order may require entry of an automobile make and license. An order that includes alcohol may require special steps to verify age.

Third-party delivery via services such as Uber Eats, Postmates, Doordash or Deliveroo require either manual processing or their own integrations, which can be done either directly or through a service like Deliverect or Omnivore that supports a single connection to many. Manual processing may work fine when dine-in business is slow (as during the pandemic) and the kitchen can consistently monitor the printers or tablets where third-party orders arrive. But if third-party delivery is a long-term strategy, integration is the way to make sure that customer expectations for delivery commitments are consistently met.

POS Integration: MDO solutions are designed to work with POSs, not independently.  There are some low-end exceptions where the MDO solution essentially functions as a simple POS, but these are practical mostly for restaurants that have only mobile orders. For all others, at least some level of POS integration is almost always required to avoid the need to maintain two copies of the menu and transfer orders manually. Like most integrations, however, the question is less “is it integrated?” than “exactly what is integrated?”.

Most POS solutions were designed to optimize kitchen and server experience; they were never meant to be customer-facing. They assume that a server provides the interface between the diner and the system. Operationally, servers may even bypass the system in some situations, dealing directly with the bartender or kitchen to communicate certain specifics of an order. Integrations between MDO solutions and the POS usually cover basic ordering but rarely everything else a server might do, and there are many specific situations to consider. Except for MDO solutions that are integrated modules of a POS, many of these tasks will not be handled by most interfaces. This means you may need to adjust your operational practices to cover those that are not.

Most MDO solutions synchronize at least menu item codes and prices from the POS, and then build their own database of descriptions (often multilingual), pictures, and menu structure and ordering, all of which need to be optimized for the guest: the short descriptive codes used in the POS may be meaningful to a trained server but are not customer friendly. Many MDO systems allow manual addition of ingredients, allergens, dietary classifications, and caloric information as well, which enables guests to filter for choices that meet their requirements.

Modifier lists as set up in the POS may be too generic for customers ordering on their phone, resulting in too many options. It may be possible to order ketchup on your lemon meringue pie, and your POS may be configured to allow it, but you might not want to include that as an option for mobile ordering! Or the list may be too limited, for example there may only be one menu item in the POS for a soda, if the procedure is that the server pours the actual drink herself and the POS does not therefore need to know whether it is a diet cola or a root beer. It may make sense to rationalize the POS configuration before integrating an MDO solution, so that more of it can simply be imported vs. needing to be maintained separately.

A frequent tripping point is the final bill calculation. The total calculated by the MDO solution should match the one in the POS to the penny. There are many sources of potential discrepancies: out-of-sync prices or tax rates; items taxed at the wrong rate; whether and how taxes, service charges, tips, and discounts are compounded on top of each other; and differences in rounding algorithms. If they do not match, a guest may see a different total on their mobile device than gets posted to their room (or payment card, if the card posting is done by the POS). Or if the card posting is done directly by the MDO solution, the guest will be charged the exact amount quoted, but the revenue totals in the POS will not match the revenue received. The best approach is to have one system (usually the POS) calculate the final bill, with the other refreshing a copy as needed.

A variation on this is where the MDO solution supports dynamic pricing and the POS does not. This gives the restaurant more pricing flexibility, but unless all orders are placed via the MDO solution, can make revenue reconciliation and reporting more challenging.

Many governments have fiscalization requirements for invoices presented to customers. If the MDO solution is presenting the invoice, it may need local certification. If it is reusing an invoice prepared by the POS, some locations will still require separate certification for the MDO solution, while others will not. In addition to the regulatory requirement, some jurisdictions require online real-time reporting of closed sales, which one or both systems will need to do.

Operationally in many restaurants, servers often need the ability to modify orders placed via MDO; for example, a diner may place an order but then change their mind after speaking with a server. Good service suggests that the server should then be able to make the change for the diner, but unless the orders are synched between the MDO system and the POS, any change the server makes will not be reflected on the guest app. In this case, if payment is to be made via the MDO system, it needs a way to retrieve the updated bill and correct amount, either by interface or using a mechanism like scanning a QR code on a printed POS check. The better MDO systems either reference the same database as the POS for orders, or they refresh via interface from the POS each time the guest opens them. An additional useful feature is the ability of the POS to retrieve an order that has been started via MDO but not yet sent.

Only a few POS systems have the ability to page wait staff to handle requests from specific tables, but for those that do, it makes sense to integrate this with the MDO system so that the diner can make simple requests from their phone (e.g., request additional condiments or cutlery) or to request their server (such as to report an undercooked entrée). For those that do not, products like Dinggly can fill the gap. This functionality in an MDO platform may also be usable with room service to signal the need for a tray pickup (or a product like Trayaway can do this).

MDO solutions and POS integrations also need to consider scenarios such as diners at a single table that want to order separately but receive one bill, or to order from one device but split the bill. POSs can generally handle these situations when orders are placed with a server, but both the MDO functionality and the interface need to be considered for them to work for an MDO order. Best practice is to clarify the desired ordering and payment approach at the outset of the ordering process.

Some MDO solutions have the ability to throttle orders, either entirely or for specific items; for delivery or pickup orders this may mean a later ready-time or outright rejection of the order (this may be based on timing estimates obtained via interface from the POS). Many restaurants will throttle only for delivery and pickup and not dine-in, meaning that the MDO solution can handle the throttling without consulting the POS, but it needs to apply that throttling only to the specific order types. For dine-in, it may be appropriate to warn the diner that their order may be delayed and to suggest alternatives that can be prepared more quickly.

A final important consideration with POS integration is stock control. If MDO orders are entered into the POS via the interface, then stocks will be automatically adjusted as items are sold; if not, then a separate feed to the stock control system will be needed. Related to this is the ability of the MDO solution to check that a menu item is still in stock and if not, then either remove the item from the menu or, if the out-of-stock situation is only discovered when the order reaches the POS, to handle the exception gracefully.

Payment Integration: Most MDO solutions offer at least one built-in payment option; many support interfaces with many, even dozens, of gateways. Some MDO solutions, especially ones advertised as free, may require that all MDO orders use their gateway partner. This may be fine for a standalone restaurant, or as a short-term solution for a hotel restaurant. Most hotels will, however, want to use their existing payment gateway, as this tends to reduce processing cost and to simplify account reconciliation and chargeback inquiries.

Payment integration is complex, especially for a vendor with limited experience in doing it. If a vendor does not have an interface to your payment gateway, they may claim they can do one easily. You can have some confidence in that claim if the vendor has done several dozen already, but I would be very hesitant if they have only done a few; there are many issues are handled in distinctly different ways by different gateways and it takes considerable time for a vendor to reach the point where they have dealt with most variations. It is essential (and now commonplace) that sensitive payment data be transmitted directly and securely from the mobile device to the payment gateway, without ever passing through the MDO cloud environment.

In addition to the hotel-specific situations of room charges and bill-to-group-master charges, MDO solutions need to handle the traditional payment methods that are relevant in the location. This will almost always include credit and debit cards, cash, Apple Pay, Google Pay, and may include others such as Samsung Pay, Paypal, Alipay and WeChat Pay. Country-specific direct-payment methods that are in widespread use, such as Swish in Sweden or MobilePay in Denmark, may also be needed. Settlement rates for these payment methods can vary widely; if they do, you will want to ensure that you either get the benefit when lower-cost payment methods are used, or that your blended rate is appropriate for your actual mix of payment types.

Authorizations can be a sticking point for restaurants and (especially) bars that use them. POSs are generally optimized to ensure that an open tab always has an authorization for the right amount (often including an allowance for tip). If the MDO solution is doing the authorization, it needs to adhere to the rules of both the payment network and the payment method, particularly with respect to open tabs and tipping. This is important in most bars, but also in any restaurant where there is a significant risk of “dine and dash.”

Operational Considerations: Several of the MDO providers emphasized the importance of involving front-line managers and service staff in the selection and configuration process. Servers and bartenders can see MDO as a threat to their jobs, whereas the reality is that it could be quite profitable for them, particularly in tipping cultures. Digital ordering enables servers to handle more tables per shift, increasing tips per shift. If better upselling increases the average order size, then tips increase even more. And depending on the features, MDO can increase diner satisfaction, which can again lead to larger tips. Operational managers may feel threatened by change, the need to learn new technology, or fear of the unknown – all concerns that can be reduced through early involvement.

It is critical to evaluate kitchen and bar order processing in the new system. Many MDO solutions will operate via a dedicated ticket printer, which someone needs to watch; variation in ticket formats can also cause issues. There is a strong advantage to having all orders delivered via the POS regardless of source, but in many cases this will not be possible.

If a restaurant often has a line or waiting list, it may be useful to select a solution that enables the guest to order while they are waiting; this can reduce the turn time on many tables if the appetizers and drinks can be delivered as soon as the party is seated. Restaurants may also want to incentivize guests to pre-order, even a few days in advance, so that they can better plan inventory and staffing. These capabilities may require additional integrations.

Conclusion

Mobile digital ordering is an important emerging trend that most restaurants should now be considering at least as an option. It can simultaneously increase diner satisfaction, reduce costs, and increase revenues. However, the options, particularly in a hotel restaurant, are often not simple. Careful analysis, thought, and planning are required to achieve the desired results.

‍