The future of the search and book flow in hotel booking
1 out of 7 booking requests fails or makes the OTA less money than it could. Why? There are several flaws in the search and book flow, but a new approach aims to get rid of them.
As many as 15% of all bookings made by customers fail or don’t earn as much profit as they could, really hurting an OTA's customer retention and revenue. But what causes this? And is there a way to improve it?
In the time between the customer’s search for a hotel room and their booking, the so-called search and book flow, something seems to get lost, there is a disconnect. Let’s explore exactly where, and how it could be avoided.
The hotel search and book flow is a far more complex process than many realize, with a lot of players involved. The hotel industry is a multi-layered environment with a lot of overlap: OTAs buy from a variety of supply sources, who sell their inventory not only to OTAs, but across multiple channels to a large and varying customer base. This leads to a lot of players working together using an infrastructure that wasn’t designed for that purpose, creating a huge strain on the system. The outcome is many challenges and inefficiencies experienced throughout the hotel search and book flow.
Bad experience = lost customer
Currently each stage of the hotel search and book flow works with the other interdependently. What exactly does this mean? It means that when a customer searches for a hotel room, he is presented with an array of seemingly final offers, but they may not be final at all. In most cases cached results (saved results from a previous search) are used, a practice employed to save server power and speed up response times. While this aim is partly achieved, the major challenge with using cache is unreliable results: cache layers are outdated over 30-40% of the time, even if only a few minutes have passed.
Pricing and availability change exceptionally fast in the dynamic multi-player travel environment, and cached results become out-of-date very quickly. So while the intended process of the search and book flow is for every customer search to be sent to a supplier, in 1 out of 7 cases that doesn’t happen. Instead, outdated cached results are displayed and an error message is received, or the booking simply fails. In either case the customer will most likely abandon the booking, and never return. This directly impacts an OTAs bottom line, being that customer acquisition is the hardest and most expensive process for an OTA.
Response time is everything
Another source of losses stems from an OTA’s decision to offer their customers good response times to make sure they don’t lose patience and jump ship mid-search. For the sake of speed, OTAs have to limit the time allowed for suppliers to respond to each query, but then they miss out on better buy rates that lie outside of their set time frame.
Considering the interdependence of the search and book flow, it is becoming apparent that each of the stages has a different objective at heart. The search process is very customer geared, while booking focuses on customer satisfaction and achieving the highest possible profit margins.
The main reason the search and book flow is so intertwined has to do with the way the supporting technology was designed. So what would separating the search and book flow achieve? What possibilities would it open up for OTAs?
Separating search and book
Separating the search and the book flow would allow sellers to avoid search constraints and give their customers great service while increasing profit and optimizing their business. One way to separate the two could be to utilize data-based insights, supported by recorded user behavior and AI, to create a sort of predictive pricing mechanism during the search process. This would completely eliminate the need to query cache layers, significantly reduce server load and speed up response times.
In this scenario the booking process would only begin after the customer actually decides on an offer. The priority here would not be the response time, but finding the best supplier rate for the OTA, according to the customer’s chosen price. Errors would also be significantly reduced as all offers would be up-to-date, and even if any did occur, technology could be in place to catch and re-route them to the next-best offer.
While some aspects of these technologies already exist, for example solutions that intercept the search and book flow to recover error bookings, more will surely to come. Taking all of this into consideration, the previously unthought-of concept of splitting up the search and book flow now seems inevitable. Because who doesn’t want to enhance response times, customer satisfaction and retention, and at the same time eliminate errors, reduce server loads and increase profit?