My last column introduced the large and complex category of Guest Journey Software (GJS). It made the case that this should be on virtually every hotel’s radar as an inexpensive way to reduce operating costs, increase guest satisfaction, and generate new revenue. I outlined the benefits and explained why the timing is now right for many hotels – when just a few years ago, the offerings were still pretty rough. I also provided insights into the challenges of deploying GJS.

This week’s column builds on Part One but shifts the focus to evaluating GJS platforms. It’s not a simple checklist, because every hotel is different. Not every capability makes sense for every hotel, and integration with existing systems often creates challenges. You’ll need to overlay your own judgment on what you can learn here.

As noted in the first column, nothing described here is science fiction – everything is commercially available in at least one solution among the ones I interviewed. These included Canary Technologies, Duve, GuestTraction, hudini, NexGen Guest, Nonius, Operto, QikInn, TigerTMS, and Virdee. A few others did not respond to requests for interviews, but from what I know of them, they are in the same range.

We will start with how to think about deploying Guest Journey Software as a category, then dive into the details of specific features provided by various platforms.

General Considerations for Guest Journey Software

My interviews yielded a lot of good advice that can help you approach this complex category. I have distilled some of the main points in this section.

Prioritize Your High-Level Objectives. GJS can help optimize staff efficiency, can generate incremental revenue, and can improve the guest experience. There are often tradeoffs, however. The smoothest guest experience may be less efficient for hotel staff or might not generate as much revenue. Understanding your primary objective can help you select the best options. If your biggest problem right now is staffing the front desk, then you might focus on preregistration and mobile check-in – especially if upselling requires a lot of manual intervention to fulfill (you can always return to upselling later). If labor is not an issue but revenue is, then upselling may be more critical.

One Step at a Time. GJS can do dozens of different things, but as outlined Part One, it can require configuration, complex operational changes, integrations, and staff adjustments. Several of the more mature vendors emphasized the importance of implementing specific capabilities in a focused matter, one or two things at a time. You may have a long list of things you want to do, and this is relevant when you are selecting a GJS platform. But once you have decided on that, select one or two capabilities to implement. Then take the time to work through the implementation kinks before moving on to the next one.

If you do not already have them, upselling and guest preregistration are good candidates for many hotels because of their quick impact on the bottom line. Upselling can be kept simple: start with early check-in and late check-out and, depending on the property type, perhaps a few room-type upgrades or add-ons like breakfast. You can save a lot of time at the front desk just by getting most guests to provide their registration details before arrival; many packages support ID verification, payment, and key issuance. They can go to the front desk or kiosk to quickly complete any final steps and get a physical key, or (where offered) they can use a mobile key to bypass the front desk entirely.

Look at Engagement Statistics. The vendors should be able to give you solid and referenceable statistics on guest engagement. For example, what percentage of guests receive post-confirmation communications? What is the open rate, the click-thru rate, the conversion rate? How does guest satisfaction compare between those who engaged and those who did not? All things being equal, a platform that engages 80% of guests will deliver better results than one that engages 60% - but both will outperform native apps by a large margin in most hotels.

Engagement reporting capabilities are an important consideration. Will you get reports to show where and how guests are using the platform? What pages are most visited? How they correlate with market segments, booking channels, party size, and other factors? Particularly if you want to customize the journey based on factors like these (even if only in the future), this data will be critical.

Consider What You Already Have. If you have a brand app that you cannot change, then you still might be able to add a few capabilities it lacks. But you may also be able to use Guest Journey Software to reach those guests who may never download the brand app. Maintaining both a brand app and GJS can lead to multiple back-end staff processes for guests who use one vs. the other, but if the benefits are large enough, it may still be worthwhile.

Look at what your Property Management System (PMS) vendor offers in the way of guest journey capabilities. They may not be as slick as the best-of-breed offerings, but many PMSs do provide some GJS functions, and having fewer vendors will lead to smoother deployment and better support. Some newer generation PMS products were designed from the outset with the guest journey in mind and support many of the capabilities described here. If you have one of these (or are thinking you might want to move to one) then this may be your preferred option even if you still need to source a couple of modules elsewhere.

If your hotel is using middleware such as Hapi, Impala, iReckonu, Nonius Hub, NEC Univerge, or TigerTMS iPortal, talk to your vendor about which integrations they can support. Similarly, robotic process automation software such as from Aphy or RobosizeME can help avoid having to transfer transactions manually between systems. Talk to the GJS suppliers to understand what interfaces they already have to your PMS, point-of-sale (POS), messaging applications, middleware, and others. Reusing existing interfaces can reduce the cost and risk of deployment significantly, although you still need to ask the right questions (see my earlier two-part blog here and here, and sections on specific capabilities later in this article).

If you have existing software that performs certain GJS functions (like a text messaging app) and that you want to keep, look at whether it can be integrated into a platform that can do more. Some of GJS products are designed to facilitate this, while others are harder.

Integration: If your PMS or other key systems are difficult to integrate, and if middleware or robotic process automation are impractical, you may be limited in your choices. Manual processes may be workable for some low-volume transactions like room service ordering or certain upselling options. Even without integration, some guest journey vendors can, for example, deliver room-service orders to the kitchen via a tablet or printer, where staff can manually enter them into the POS system. You can always upgrade to an interface if volumes warrant, and in the meantime the guest can enjoy a better, more interactive ordering experience and the hotel can earn more revenue.

Do not underestimate the complexity of integration. To fully deploy mobile check-in, for example, typically requires integration of the PMS, key encoders, kiosks, payment terminals embedded in kiosks, and the payment gateway. Unless you have your own integration experts, look for a vendor who will take ownership of getting these systems fully working together, not one that delivers the pieces and tells you to have fun assembling them!

Some of the GJS products offer Application Programming Interfaces and/or Software Development Kits. These can significantly reduce the time required to implement new interfaces, and may be a useful consideration for both the initial deployment as well as for the addition of future modules.

Flexibility. Consider whether you have multiple hotels that may need to work differently, or whether even within one hotel you want different processes (overall or for specific functions) for different guests, reservation types, or channels. This is a significant point of differentiation for GJS products, and if you plan to use it, carefully consider how you will resource its regular maintenance. The better systems allow hotel staff to modify the flow and/or the information presented for specific types of guests or reservations, but this requires some training and regular staff attention that smaller hotels might find challenging and that larger ones might not understand. Be sure to look at the configuration screens and see how intuitive they are; the better ones will show you the results of your changes in real time on a mock mobile phone screen on the same page.

Even with the more flexible packages, if you customize them, you should start simple and add complexity gradually. The more complex the configuration, the greater the likelihood that the rules that define the path of a particular guest’s journey will conflict with each other. Nevertheless, even at the outset you will probably want to set a different default path for third-party bookings than for direct bookings, since you will typically need to collect contact information from third-party bookers that you will already have for most direct bookings.

Activating the User Experience. Look carefully at the different options a guest can use to get into the application. A personalized URL sent by email, text, or chat can persist throughout the relationship, enabling every new interaction to be aware of every prior one. This can make for a smoother guest experience and less need to re-enter data. Text or chat are usually more effective than email because the guest can more easily find the text thread with the hotel and simply continue to use it to chat, or can scroll back to the URL to re-enter the progressive web app (PWA, discussed in detail in Part One).

For guests who have checked in but not yet used the GJS app, look at options the vendor may provide to identify them through the Wi-Fi portal. Anything you can do to avoid the need for a guest to create a login will reduce friction and increase usage. Some systems can be configured to load a guest journey landing page immediately when the guest connects to the Wi-Fi.

You may also want to enable guests to scan QR codes to access relevant content around the property, such as a restaurant menu or the pool hours. Look at whether and how a guest who has already used the PWA can still get a personalized response if they later scan a QR code – the PWA should still know who they are and if appropriate, personalize what they see based on the location and individual.

Be wary of generic rather than personalized URLs sent individually to guests. While generic codes can invoke the guest journey software, they do so without access to information about the guest that can otherwise be retrieved from the PMS or other systems. The guest may have to re-identify themselves each time, adding friction. QR codes posted in public spaces will still be generic, of course, but you can still personalize the results when they are scanned by a device where the PWA has already identified the user.

A few systems provide personalized URLs per guest, as opposed to per reservation. This can be important in some upselling situations, such as for a family at a resort where one adult might want some golf time, another might prefer a spa treatment, and the teenagers might want the video game room special offer.

Payment. Where payment is required, it should be as frictionless as possible. Guests will appreciate an option to post charges to their folio as well as standard mobile payment options like Apple Pay or Google Pay. The latter will, however, either require integration with the hotel’s payment gateway, or processing through an independent gateway contracted by the vendor or by the hotel. Guest folio integration is useful because it meets the needs of most guests and use cases, is simpler for guests, makes it easier for business travelers to prepare expense reports, and can result in lower credit-card fees. Where feasible, folio integration is also generally simpler than payment integrations.

It goes without saying that GJS should not touch raw payment card data; this should only be done through a secure gateway operated by a reputable payments company. In some cases, tokenized card data can be obtained from a payment gateway or PMS and used to process a transaction without knowledge of the underlying card data.

Collecting Guest Data. Guest journey software has better access to detailed guest data than almost any other hotel system, because it is the one the guest is holding in their hands and using to communicate with the hotel throughout their journey. But what happens to the personal data that is collected and used? Some guest journey platforms can serve as a pseudo-Customer Relationship Management (CRM) system for hotels that need one. Others can exchange relevant data with a third-party CRM or the PMS; a few can do both. Since much of this data qualifies as personally identifiable information (PII), it is important to understand what systems store it, what they do with it, and how they comply with applicable privacy laws. You also want a single source of truth for customer data, which is easier if one system is primary and the others obtain data and provide updates via interfaces.

Regardless of where your guest data is stored, questions to ask with respect to the guest journey include whether it is actionable (can the stay be personalized based on what has been learned?), whether requests and nuances are saved, and whether they can be filtered or queried for marketing activities. If a guest makes the same request on multiple stays, whether by chat or using app functionality, they are probably telling you something that you can act on in future stays!

Branding. Most GJS platforms support branding and white-label deployments, where the hotel can control colors, fonts, layouts, logos, and the like. Some can also white-label outbound emails and text messages so that they appear to come from the hotel rather than a third party. Be sure to evaluate how each solution can support your brand’s look and feel.

Platform Architecture. Several architectural design considerations and capabilities should also be considered.

·      A/B testing, if supported, can help hotels understand what works for them. Find out if your vendor offers it, whether you need their support to utilize it, and how to use it.

·      For hotels that support mobile keys, and for guests who want to use them but have not downloaded the native app that is (for now) still required for mobile keys, the handoff from a PWA to the native app should require as few actions as possible. A common design has a “request mobile key” button (or similar) on the check-in page that looks for the native app. If present, it switches to it, deep linking to the key issuance page so that the switch is seamless. If the native app has not been downloaded, then it advises the user that they will be taken to the download page in the app store, from which they must initiate the download and then continue. The native app should ideally offer identical functionality and user experience as the PWA so that guests can continue to use it, once downloaded.

·      If your check-in process includes a kiosk option, make sure that the user interface and terminology are consistent with the mobile check-in, so that guests can complete each part of the process on any device, without confusion.·      Watch out for latency, especially with on-premise PMSs. GJSs are cloud-based systems and communication will not be instant, but the mobile device or kiosk should be able to retrieve reservation or other data in less than a second. Some guest journey systems cache copies of the PMS data to avoid this issue.

·      If a transaction starts on one device (e.g., mobile phone) and then continues on another one (such as a kiosk), make sure that information previously captured or verified does not need to be requested or verified again. If the GJS caches guest information from the PMS as mentioned above, test the process by having a guest preregister on their mobile phone but then immediately go to a kiosk to change a detail or obtain a mobile key. Did the preregistration data arrive in time? If not, is the error-handling intuitive?

·      As with any hotel software, if you expect to deploy in multiple countries, language support and fiscalization matter. While most GJS platforms support multiple languages and character sets, many vendors who have limited international experience are often naïve about the complexities of fiscalization, which can involve currency rounding and presentation rules, tax invoices with special requirements and fields, special rules for when taxes must be/need not be collected, and reporting requirements to tax authorities (which in some cases may be real-time), just to name a few of the common ones. Some vendors try to do fiscalization for each country themselves; others leverage the fiscalization already done within the PMS or POS, which can result in lower barriers to deployment in new countries and better ongoing compliance over time.

Operational Considerations. As you plan the implementation of guest journey software, give careful thought to how many and which staff will need to learn and manage the new system. Ideally, most colleagues can continue to use the systems they use now, and for them, the GJS simply operates behind the scenes. However, there are often new functions that need to be resourced. If you are adding text messaging, for example, then someone needs to answer the texts, and metrics are needed so that management knows whether they are consistently being handled in a timely way. Some guest journey and messaging software providers are offering first line response “as a service,” which may be a good option especially for smaller hotels where there may only be one person working during off-peak times.

Where interfaces are not practical, you may need to manually transfer data from one system to another. This may be manageable for a small number of transactions, but problematical for other activities.

Vendor Viability. With any software acquisition it is important to consider both the likelihood and risks that the vendor will fail or that the product may be withdrawn from the market. In some cases, the risks are small: you might lose certain functionality for a while but could replace it fairly easily. With a more comprehensive GJS solution, however, the financial viability of the vendor becomes critical. Several of the vendors listed above are comparatively well established and funded, while others are earlier stage.

Components to Consider

Part One of this blog discussed various elements of the guest journey that might be included in any solution. Some of these are applicable to all hotels, others only to a few. Here are some highlights of what to look for in each area.

Booking: The confirmation (or post-booking email sent to the disguised email address provided by some Online Travel Agents, or OTAs) should include a link to get hotel information, personalize your stay, see upsell opportunities, and preregister. While some OTAs restrict what hotels can include in post-booking emails, many vendors offer OTA-approved solutions that can enable you to establish an ongoing dialog with the customer. It should also be easy to make new bookings and to view, modify, or cancel existing ones.

Upselling: GJS should be able to offer the right upsell options at the right time. This might mean pushing a late check-out offer both pre-arrival (when the guest is planning) and the day before checkout (when the need may be clearer). Activity bookings or dinner reservations for high-demand restaurants, on the other hand, might need to be offered days or weeks in advance of arrival. The best time to offer a particular item can depend on occupancy, capacity, the advance booking window, the length of stay, or other factors. The more you can fine-tune the offer to the guest and adjust it over time, the greater the revenue potential. The ability to push real-time offers for facilities or activities that are underutilized, and to target guests who have indicated an interest, can also generate high financial returns.

Look for personalized upselling. Breakfast is a common upsell item, but it probably should not be offered to a guest whose package includes breakfast. The more things your hotel might want to upsell, the more important personalization is. It is poor practice to make a guest scroll through 100 different add-ons when you can identify the five or ten they are most likely to select.

Several GJS products offer easy capabilities to make reservations for restaurants, transportation, or third-party activities, and one even offers a marketplace of local options from which the hotel can choose what to offer. The hotel can establish its own commission or revenue sharing structure for direct relationships, or piggyback on arrangements made by some vendors or their partners. Some packages integrate with third-party booking channels such as OpenTable, Ticketmaster or Viator in a way that allows the hotel to select only certain activities or restaurants to display; the third party can handle the reservation natively or via an API.

Upselling effectively can require multiple presentation modes. While descriptions and photos may be fine for some things, others (such as room upgrades) may benefit from floor plans that let the guest pick a specific location. Look for upselling capabilities that support differing inventory models: some items can be free-sold, others inventoried, while still others must be time-sliced or may have more complex inventory models based on simultaneous availability of staff, space, and equipment. Bundling multiple items into a package can also be useful. Most packages will have some limitations, so evaluate your needs carefully.

An important feature to look for, when the upsell involves reserving third-party services or activities, is whether the app can prepopulate fields in the reservation form using the guest data it already has, such as name, email, or mobile phone. This makes for a more frictionless guest experience.

Many believe that upselling only applies to higher-end hotels with lots of things to spend money on. But even limited services properties can generate additional revenue from early check-in, late check-out, charges for additional room cleanings, and third-party food and beverage ordering.

Check-In. The goal should be to get as many of the common tasks of the check-in process handled prior to arrival, and without the need for staff intervention unless the guest wants it. While it is theoretically possible to handle every variation, there are simply too many edge cases for this to be practical at most hotels. The focus should be on supporting the “happy path” that most guests can follow; the app should politely hand the guest off to staff for the one-off edge cases it cannot handle. But if you have common cases that might not fit the happy path, look for a package that can handle them. One that I saw, for example, could handle checking in an airline crew member to a room block in the company’s name, where the guest’s name is may not be known until check-in. That is not common for most hotels, but might be for an airport property.

Guests should be able to (and encouraged to) preregister online; this is a great way to collect contact details from OTA bookers without having to rely on overworked or undertrained front desk staff. Preregistration should have multiple points of engagement: the confirmation or post-booking email, a pre-arrival email or text with a link, a QR code to scan at a kiosk, the kiosk itself, or a QR code in the lobby are all valid options.

Many of the systems can do an identification check and, where required, capture ID information and send it to local authorities. There are significant cost differences associated the third-party services used by different GJS platforms, however, so evaluate the options carefully. In some locations it may make sense to store ID information (with the guest’s permission) to facilitate future check-ins and reduce transaction fees; while this is possible, the security considerations of storing sensitive PII need to be considered carefully.

Biometric matching, typically of a real-time selfie to the photo on identity document, is supported by many GJS vendors; be sure to look at the cost, reliability, and awkwardness for the guest. Some systems can also verify that the selfie is taken within a geofenced area such as the hotel lobby at the time of check-in, which may be needed for compliance in some jurisdictions. Many solutions can also handle signature capture.

Most guests need to provide a credit card at check-in. This can be done through many of the apps, typically by capturing and tokenizing using the hotel’s payment gateway (or another third party that operates within scope of payment card security regulations). The app or kiosk calls the gateway to collect and tokenize the card info, receives the token, and passes it to the PMS; the GJS software never touches raw card data. Some solutions can also handle split charges and multiroom folios, and some kiosks can accept cash. The payment card requirement may depend on various aspects of the reservation and hotel, such as whether the room has been prepaid, whether incidental charges are expected, whether the hotel charges or preauthorizes up front, and whether special billing arrangements apply. The better packages can tailor the payment aspects of registration based on these factors.

Key issuance can be handled by mobile key if the hotel offers it, via a keycard dispenser at a kiosk, or by a manned front desk. If other check-in formalities have been completed pre-arrival, then a common solution is for the guest to scan a QR code on their phone at the kiosk to generate keys, or they can pick up a prepared key packet from the front desk.

Check-in software needs to address what happens when the room is not ready when the guest arrives. At a minimum, the system should be able to notify the guest automatically as soon as their room becomes ready; each hotel may have other actions they might want to take. These actions might currently be handled by another hotel system such as housekeeping, in which case the guest’s mobile phone number may need to be passed from the preregistration to the other system via interface.

If the hotel has a loyalty program and the guest is not already a member, a one-button “opt in” option can be very useful; the guest can be enrolled based on contact details they provided as part of preregistration, perhaps only adding a few preferences.

Many hotels currently use different check-in processes for regular guests, loyalty members, or VIPs. For example, they may use stored payment information from the loyalty profile, or waive ID checks. The better guest journey platforms allow customized processes based on guest or reservation type. Registration can also handle choices that certain (or all) guests may be offered, such as frequency of room cleaning, or the choice of welcome amenity that some brands give to elite loyalty members.

Messaging, Chat, and Telecommunications. This is a huge and complex topic, and one I have written about in the past, but not in the context of guest journey software. Many message platforms work only for in-house guests, whereas GJS messaging can start at or even before booking and continue after the guest has departed.

Every guest has different preferences for communication. Some prefer email, others will use a web link sent by chat or email, and some like SMS text, WhatsApp, WeChat, the telephone or potentially even a video call. The goal should be to support any of these that are relevant to your guests, while enabling consistent interaction by both the guest and hotel staff. For staff this will usually mean a single inbox where all guest requests and history are tracked, regardless of how they originated, and the ability of staff (or artificial intelligence) to tag messages for action by the appropriate department or individual. For guests, this means ongoing access to past messages sent and received, regardless which device was used at the time.

It can be very useful if the system is able to identify guest-initiated messages sent by SMS, WhatsApp, WeChat or similar platforms, even if the guest is not logged in or using the PWA or a native app. Some systems track phone numbers and chat accounts from prior stays, and can remember the specific guest if they start a new conversation for a future stay. If the guest is in-house, they can also identify the room number – all without the guest having to explicitly identify themselves.

To make messaging work operationally, staff must be alerted to new messages as they come in. The ability to forward messages via SMS or another tool so that the recipient gets an audible alert on their mobile device can help ensure quick responses, especially from departments that may only get a few messages a day. Some systems can direct messages into a specific system, such as the work order management or housekeeping system, to avoid the need for transferring them manually.

Metrics are needed to monitor and fine-tune response time. Guests expect text messages to be answered almost instantly, but this will only happen consistently if response time is measured and staff held accountable. Messages that have not been answered within a few minutes need to be escalated. Some guest journey products offer support for multi-hotel contact centers operated by the hotel group or even the vendor itself; these can deliver consistent response times with less labor because of the higher volume of messages, but the quality of responses can be harder to manage when the staff are offsite and handling multiple hotels. Artificial intelligence responses are also supported by some solutions and can be very useful at providing quick answers to common questions without the need for staff resources.

Templated responses can facilitate quick, thorough, and accurate dispatching of many guest requests; some can even personalize the response based on the guest or reservation. For example, a template might provide the answer to an inquiry about parking at the hotel, and the templated response might be different for a guest who has purchased a package that includes parking than for one who has not.

Automated language translation is a common feature, but it will never be completely accurate. Templated responses that can be customized in each common language (and reviewed by a native speaker) can help ensure that the hotel’s responses are not mistranslated.

Some solutions offer push-to-call buttons on relevant pages for guests who want to speak with a hotel colleague. If the hotel wants to support this, look for solutions that default to using the WebRTC protocol to avoid incurring per-call charges. Voice and video chat can also be useful for a hotel that wants to offload large group check-ins that cannot be handled through preregistration or a kiosk, by enabling human assistance from a brand or third-party call center.

Unsolicited outbound messages should also be supported, subject to opt-in by the guest. Features to look for include prescheduled messages, remembering a guest’s preferred messaging channel, saving messages for future reuse, and sending messages only to defined audiences, such as guests in a specific group, staying on a particular floor, or staying on a golf package.

Hotel Compendium. Most of the packages offer some sort of content management system that allows the hotel to build a digital compendium covering the hotel, its facilities, travel logistics, things to do nearby, and other information. Look for systems that allow you to add your own categories and pages and update them easily. Where needed, you should be able to create them in multiple languages, but also provide automatic translation for any languages you have not specifically loaded. The better packages support text, photos, PDF documents, videos, maps, and external links. Some of them also integrate with messaging if the guest does not see the information they want on a particular page. It can also be useful to be able to define which audiences should see specific pages; for example, you may want to provide different information about certain services for in-house guests vs. future or prospective guests or day visitors.

Guest Requests. A guest journey app can handle many standard requests, such as housekeeping (please clean my room; I need more towels), engineering (my desk light is broken), bell services, laundry pickup, valet parking car retrieval, and the like. Look for integration with work-order management or other operational systems to help ensure requests are actioned in a timely manner; where this isn’t possible, the solution should effectively alert the staff in a way that is difficult to miss or ignore.

Food and Beverage. For on-premise dining, the simplest implementation of food and beverage ordering (whether for room service, table service, pickup, or delivery) is to have the guest journey app link to an ordering app provided by the hotel’s POS vendor (or sometimes by third parties). The guest’s identifying information can be provided via deep link to enable a seamless transition. This approach can avoid the need to enter the menu, pricing, tax calculations, and other details into both the POS and GJS. However, this may not be an option for in-house restaurants, as it requires that your POS offer a mobile ordering app or support one from a third party that utilizes the POS menu structure, items, and pricing.

If you have an in-house restaurant and there is no ordering app for your POS, then you can look at the food and beverage ordering offerings from the guest journey platforms. A few of them offer interfaces to major POS systems. Be aware, though, that some interfaces deliver the order to the POS but do not extract the menu, descriptions, modifiers, prices, and other information. Without these, you will need to maintain menu items and prices in both the POS and the ordering app, which can be time-consuming and will lead to errors and inconsistencies. Even for interfaces that include these, you may need to add pictures for the menu items in the ordering app, since most POS systems don’t have these at all, but most GJS apps do. Best practices would also say that if the guest check total on the mobile ordering platform is different from the total in the POS, the mobile total should be the one that gets charged; discrepancies should be posted to an account that can be monitored so that out-of-sync items or prices can be corrected.

A lower-tech option is for the guest journey app to display the menu and prices, and offer a “call to order” button that places a phone call to the restaurant. My personal experience with these has not been very good; many hotels let the menus get out of date and the guest ends up having to order something different than what they selected on the app. But some hotels can manage the process well.

One other useful feature is the ability for a guest to order a meal when they are outside the hotel, either prior to arrival or while they are out for the day. The ability to specify a delivery time may be desirable especially for luxury hotels.

For hotels with limited or no food and beverage onsite, GJS modules support third-party relationships that can generate commission revenues. Integration with platforms like 2ndKitchen or GrubHub can be effective and retain hotel branding, although there may be some payment friction if the guest cannot charge the meal to their folio. Third-party integration with delivery and pickup apps that support nearby restaurants can be another good way to earn commissions while providing a useful guest service; in this case the guest is clearly leaving the hotel’s site but is transferred seamlessly to a familiar brand. Some platforms allow you to establish your own business relationships with local restaurants, while others have done this already through alliances with delivery services; they may allow the hotel to select the specific restaurants it wants to include. The commission is split between the ordering/delivery service, the guest journey platform provider, and the hotel.

Guest Room Controls.  A few guest journey platforms offer integrations to common guest room systems, including the television, temperature, lighting, drapery controls, and do-not-disturb and make-up-room lights. This can be relatively straightforward for an independent hotel but more challenging to achieve across a brand because these devices often vary from hotel to hotel. To achieve consistency, interfaces will be needed to support each one (often including legacy systems for which they are unavailable).

A few guest journey providers also support the use of their platform through a bedside tablet or, with some limitations, the television. An existing tablet should be able to use a PWA with minimal integration, but you will likely want to offer a different default menu and navigation on a bedside tablet than on the guest’s phone (perhaps defaulting to a control panel for guest room devices). If you do want to deploy these capabilities on a bedside tablet, check that the user experience can be customized accordingly.

Digital Tipping. At a time when many hotels are struggling to get staff, digital tipping can help increase employee compensation at little or no expense to the hotel. The opportunity to leave a tip for housekeeping, bell services, valet parking, and other staff can be built into a guest journey app, both as an ad-hoc menu-level capability, or as part of other transactions such as check-out. I plan to cover this topic in depth in my next blog, so will defer details for now.

Folio View and Check-Out. With a guest journey platform, you can get better information from more guests about when they plan to check out, enabling better optimization of housekeeping and more rooms available for early check-in. Several of the platforms recommend a message the day before departure, reminding the guest of the check-out time, offering late checkout as an upsell option, and recording their expected check-out time. The ability to view the folio, at that time or anytime during the stay, is also useful.

At least one platform offered self-reporting of chargeable in-room items such as minibar purchases, helping ensure that the guest gets a hassle-free final bill without having to stop by the front desk or request after-the-fact copies from the accounting department. A couple of products had or were about to introduce a feature allowing the guest to add a tip for housekeeping at checkout.

Once the guest has checked out, the guest journey app can offer a satisfaction survey and/or opportunity to leave a review. Again, these may be native capabilities or be instantiated as a link from the main menu.

Conclusion

As these two long blogs have shown, evaluating guest journey software is definitely, well, a journey. While there are some principles that apply to most hotels, every hotel will need to consider which features make sense for its guests, its brand positioning, and its existing systems. Some hotels may look at the list and want to do everything, but most will find only a subset that makes sense. I hope this article can give you some pointers identify what might makes sense for your hotel(s), how to evaluate it, and how to buy and deploy it.