The most influential Megatrends set to shape the world through 2030, identified by Euromonitor International, help businesses better anticipate market developments and lead change for their industries.Learn More
Euromonitor International is pleased to present an interview examining the nuts and bolts of hotel distribution. The first instalment features my conversation with Keith Cotton, Senior Vice President of Global Business, DerbySoft, Inc. DerbySoft is a technology company, founded in 2002, which builds software to connect hotel companies’ central reservation systems to distributors, such as online travel agencies and tour operators. Part One explains the backend of hotel distribution.
Keith Cotton: When a hotel’s central reservation system (CRS) connects to a distributor, such as an online travel agency (OTA), there are two primary methods for that CRS to provide ARI (Availability, Rates and/or Inventory) to that distribution system:
Also, it is very important to note that keeping a third party cache such as ours as accurate as possible is an evolving, sophisticated science. Almost any company can build a basic cache to store ARI, but it is the maintenance and management of that cache that separates a typical third party company from the the leading third-party companies like DerbySoft. As usual, there are a variety of caching processes and tools that should be utilised with any method of caching, but there are really two basic methods:
I should also note here that the terms “pull” and “shopping” are often used interchangeably. After all, the original pull messaging was basically simulating shopping messages that extracted ARI information from the results of the shopping message to compare to their cache. However, there is now a quickly evolving true “pull” message, whereby a third party can send a data request to a CRS for chunks of information, such as all of the ARI for a particular property for the month of December.
Hybrid: Then there are hybrid connections that utilise some combination of “Push” and “Pull” based on a variety of criteria. Hybrid connections allow the third party to optimise the building of the cache by specific criteria, for example, receiving a push to populate a cache for arrivals within two weeks, and a pull for more future arrival dates. For instance, we use a smart cache application that intelligently adjusts the frequency of simulated shopping messages based on previous shopping results and historical data patterns.
Because querying to update the cache can negatively impact a hotel’s CRS, DerbySoft optimises how often the cache is updated to balance accuracy and speed. We’ve developed “SmartCache”, which is artificial intelligence decision support software that analyses booking patterns and rate changes from historical data, and interrogates shopping message results in order to determine how often it needs to query the hotel’s CRS for updates. For example, if 80% of the queries indicate that the hotel rate hasn’t changed, our SmartCache software will automatically adjust the query schedule to send less query messages for that hotel for that particular period. Or, as another example, our software would quickly learn that it must issue queries about a property in Manhattan much more often than it does for an interstate property in South Dakota. Or, that beachside hotels’ data needs to be queried or requested much more often in the summer than in the winter, etc.
One of the better, more recent industry developments is that of “change discovery”, which is a method of determining and communicating the existence of change in hotel rates and availability. Change discovery is an application built by the hotel CRS company, whereby the hotel company recognizes all of their changes and tags them so a third party can easily find them when it pulls. Then, even though the third party must still send queries to pick up those update messages, it is checking for updates in a specified area in which it already knows every result will have a change. For example, we have one large hotel customer that has implemented change discovery and it allows us to query its change discovery data every 10 minutes. Therefore, our cache is never more than 10 minutes old at any given point in time. This makes each availability message more useful, meaningful and efficient.
Generally, all of the above methods are transparent to the online traveller, with negligible differences. As previously discussed, seamless connectivity is the most accurate, but it also requires large volumes of hits to the CRS system. And caching is the most useful way to avoid substantial hits to a hotel CRS, but it also will be slightly less accurate, depending mostly on the capability of the third party to update its cache. Basically, you will find that most hotel companies use a variety of methods to distribute their inventory, with the traditional GDSs using seamless connectivity and the OTAs using cache.
One other benefit to the hotel company for utilising a cache is the ability for an OTA to use the cache data for packaging and promotions. Often times, an OTA can build a package that even the hotel company CRS cannot create. The consumer books the package with the hotel stay included in the package and the OTA can separate the package behind the scenes and send only the hotel booking to the hotel company CRS.
Typically, when a hotel company is utilising a third party cache to avoid an overwhelming number of hits to its system, it will accept the occasional “force sell” or “force rate” during situations when a consumer happens to request a reservation for a particular arrival date that has changed in the hotel CRS but was not yet updated in the third party cache. In this event, an immediate update or shop will be triggered so as to limit the exception to that one occurrence for that arrival period.