Booking Health Check: Are You Failing for the Right Reasons?

Written by Lorie Grant, Director Product Performance Analytics & Insight at IHG Hotels and Resort and Chakradhar Munjuluri, Product Manager Third Party Distribution at Choice Hotels
Edited by
Emilie Galle, Director International Marketing and Distribution at Choice Hotels and Laurie Pumper, Communication Director, HEDNA

Note: The views are those of the authors and not necessarily the companies where they are employed.

Current use of the Booking Failure metric is limiting hotel chains to solve macro issues

The current hotel distribution landscape is a complex network of in-house or external connected systems. All these systems have different levels of technology maturity. This complex ecosystem results in points of failure in the distribution of inventory across partners. Any failure across this chain of systems may impact a hotel’s revenue. Minimizing the many points of failure can contribute to hotel profitability.

Identifying key metrics to track systems is important to resolve issues. Hotel chains have established metrics, such as the Booking Failure Rate. This rate is useful to track and solve systemic issues, but tends to be backward-looking, preventing proactivity. Depending on the scale of an issue, the Booking Failure Rate fluctuates from alarming to generally acceptable levels. Current technical teams’ operating procedures often account for alarming errors and have steps in place to address these issues. However, for generally acceptable levels of failures due to business rules, the root causes are often identified via discovery calls, which take time and resources. Product and technical teams give great thought to the list of business rules when designing system functionality and most central reservation system (CRS) or property management system (PMS) vendors can provide a list of their business rule errors. But, they are not used to detect or solve issues unless the Booking Failure Rate exceeds an overall threshold. While these overall thresholds may at first be acceptable, they can quickly turn into alarming failure rates when analyzed at the chain, rate, or region level. Left unresolved, these failure points add up to a constant loss of bookings and lost revenue over the course of weeks and months.

Turning to Booking Failure Rate to address micro issues

The Booking Failure Rate provides a direct correlation to an underlying issue which might be systemic or inherent to connectivity. If used in real time, this metric can enable hotel chains to address smaller issues in an actionable manner. A deeper look into the typical booking failure root causes provides insight into the solutions to put in place.

Three categories of Booking Failures:

Booking Failure Category Type Description Example (Root Cause)
Working By Design Healthy These errors prevent or protect from revenue loss targeting “end-user behavior” and “system behavior”.
  • Customer supplies an invalid credit card number.
  • Room sold out and is no longer available.
Business Process/Product Configuration Unhealthy These errors point to inaccurate or missing business processes and configuration or activation of products, in one or more systems.
  • Data in booking and availability source systems are not mapped or are missing (max persons per room type or credit cards accepted)
  • Missed steps when activating new products.
Software Issues Unhealthy These errors are the unintended “bugs” resolved with more software coding. Impacts are found at many levels, including product (rate or room) and channel and can be regional or global.
  • Special characters received, but can’t be processed.
  • New code did not account for all business cases.

 

For the last two categories, failures likely stem from an issue with availability or data policy. But in the case of a last room availability model or a third-party cache model, a failure may fall into two categories at the same time, adding to the complexity of identifying it and solving it. For example, a product sells out and a software issue prevents the availability change from being distributed to a third-party partner. While the booking is rejected as there is no availability (working by design), the failure root cause is that the availability was not shared (software issue). This is one of the toughest scenarios to analyze but valuable insights are gained from comparing all vendors with the same availability model. Organizations can also identify a healthy threshold (as a cache model implies latency) and pursue this area only when exceeding that threshold. In the case of issues in many categories, the best way forward will be on a case-by-case basis, as the cost of such a complex model can outweigh the benefit.

Building efficiency to address micro issues, using Booking Failure Rate

The Booking Failure Rate reflects any of the upstream and downstream data discrepancies, on any system across the distribution chain. It provides granular data to leverage in real time to identify issues and alert the right teams to resolve.

Leveraging the steps below will allow organizations to use booking failures as a metric and formalize a suitable real time process / model to address the smaller issues.

Building efficiency to address micro issues, using Booking Failure Rate

Figure 1

  1. Categorization: Review all booking failures over a timeframe, and group them based on the categories identified earlier (working by design, business process/product configuration, and software issues).
  2. Segmentation: Determine the consistency, frequency, and spread of each category of booking failures across channels, systems, products, properties and end all failures that cannot be reduced.
  3. Operational efficiency:
    1. Reduce Business Process errors at an early stage. This will prevent issues from escalating over time. When the root causes are identified as a training gap, reviewing training materials will be beneficial to fix the process gap. (This may be most noticeable when new staff are in place.)
    2. Align errors with their corresponding configuration settings. As the errors occur, examine all hotels where the configuration exists — as they are likely subject to future errors. Ex: In the case of a new rate launch, if a booking failure occurs on day 1, pair the error to the configuration to determine how many other hotels are affected by a configuration setting omittance.
  4. Threshold: Establish a healthy failure rate and update the threshold based on the new improvement.
  5. Product design: Based on the root cause identified in step 3:
    1. Product enhancement: Install a potential enhancement in the underlying product/system. For example: Validating or mandating data in the UI.
    2. Process Automation: Install an automation enhancement to address the errors. This would enable building a mature model to resolve identified issues.

The proposed process provides real-time updates and categorizes the issues based on predefined rules. Depending on the process, the time to identify and resolve the issue will vary with efficiencies gained through automation and alerts to take appropriate actions. In the following example, a rate that is supposed to be sold in a particular region is not selling. The estimated time to identify and resolve the missing mapping step ranges from 6 to 32 hours, depending on the maturity of the process.

Booking Rejection Model

Booking Rejection Model

Figure 2

 

Conclusion

In conclusion, use the Booking Failure Rate as a leading metric to identify and act on smaller issues, and integrate it to a consistent mature real-time process. These actions can drive an increase in revenue.


HEDNA Hotel Analytics Working Group
The Hotel Analytics Working Group raises awareness of the opportunities data analysis brings to optimize cost and conversion and thereby empower hoteliers to collect, store, analyze and act on their data to make intelligent decisions about their distribution strategies. The group is currently Co-chaired by Connie Marianacci at Accor and Anisha Yadav at Revinate. Click here to find out more and how to join as a HEDNA member.

Leave a Reply

Your email address will not be published. Required fields are marked *