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.
Q: Can you please provide some background on 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:
- Seamless Connectivity: This method allows the distribution system to send the consumer’s “shopping” messages directly to the CRS to get a real-time response to their queries about availability, rates and inventory. This is the most accurate method because it is basically a real-time response, but it also requires the hotel CRS to process and respond to a tremendous amount of shopping messages, sometimes at unmanageable levels. Hotel CRSs have been known to slow down substantially or even temporarily crash under the load of an unexpected volume of messages from distribution systems or other similar connections. Obviously, this can have a noticeable impact on revenue generation, and the prevention of such events is taken very seriously by the hotel CRS community. To a large extent, the importance and focus to avoid these events is what led to the evolution of the cache connectivity method.
- Connectivity with Cache: This method was generally born out of the need for the hotel CRS to be protected or buffered from the tremendous volume of online shopping messages mentioned above. In this method, a cache of ARI is built and managed externally, usually by a third party technology company like DerbySoft, so that the third party cache absorbs the shopping messages sent by the distribution systems and sends only the essential booking information back to the hotel CRS after the consumer has made their final decision. Of course, the external cache must be populated, supported and kept accurate. Even just populating the cache can sometimes mean a tremendous amount of hits to the hotel CRS (see “Pull” method below), but at least the cache is being built to absorb, for example, up to 10 different distribution system connections, as opposed to the hotel CRS having to take hits from 10 different systems simultaneously. In other words, the true value of a third party is not realised with the first connection, rather, the value is realised primarily after several connections are provided by the third party.
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:
- “Push”: One method, known as “Push”, is for the hotel CRS to push ARI information to the third-party cache and continue to maintain the accuracy of the cache by generating additional push updates every time the CRS recognises that ARI for any of its properties has changed. This delta of information can be pushed real-time or set on a schedule, such as every 10 minutes. The accuracy of the data in the cache is dependent upon how often the hotel CRS pushes its data to the third party. As for DerbySoft, we can accept any frequency of push messages so the push schedule is typically dictated by our hotel customers. Also note that the example above only addresses the accuracy of the cache between the hotel company and the third party; the other factor would be how often the distribution system company is willing to accept an update from the third party.
- “Pull”: The other method, known as “Pull”, is for the third party to pull ARI information out of the hotel CRS. This is typically accomplished by the third party sending simulated shopping messages that mimic actual consumer shopping. This method requires the third party to send fake shopping messages without guidance from the hotel CRS as to which hotels may have changed their ARI. As a result, huge numbers of shopping messages may be sent just to blindly search for any changes that might have occurred. This not only results in large volumes of messages and skews the “look-to-book” ratio, but it is also somewhat inefficient since many of the messages come back with a result indicating no change necessary. DerbySoft tries to control this inefficiency by analysing the results and evaluating historical data and trends to help adjust the frequency of shopping hits accordingly, by property and by date period.
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.