Why Hotels Need Bar Codes

Talk to anybody who has tried to clean up corporate hotel data, and you’ll know they hate doing it. It’s a pain in the butt to take a company’s hotel booking data from its TMC, and merge it with the company’s paid hotel data from its corporate card.

The first and arguably hardest step is to normalize the hotel identities. Somehow, you have to recognize that a credit card transaction at the “Marriott Courtyard in Salt Lake” should be tied to the reservation made at the “Courtyard by Marriott in Saltlake City”.

The variation in hotel names, as captured by the travel agencies, GDSs and credit card providers, is nothing short of maddening. And we’re not yet even talking about the problems caused when a property changes its flag, e.g. changes from a Hampton Inn to a Holiday Inn Express.

The solution is barcoding, figuratively speaking.  Somebody needs to establish a database of hotel properties, each with its own barcode – a unique identifying number.  The barcode stays with the physical location of the property, as defined in three dimensions – latitude, longitude and altitude.  (Altitude solves the problem of having two or more hotel properties in the same skyscraper.)

The rest of the database captures the data attributes about the hotel – its name, address, phone number, room count, etc.  These attributes are what database jockeys call slowly-changing data.  They are quite different from fast-changing data, such as room rates and inventory levels.

Once a three-dimensional property has its own unique identity, then it can be linked to any number of aliases – names by which the property is known in GDSs, TMCs, and credit card providers’ databases. From there, the whole process of mapping a card transaction and a TMC booking to the right property becomes a whole lot easier. Not entirely hands-free, but a huge improvement over what we face today.

No question, the accuracy of this slowly-changing database needs to be maintained, which means ongoing costs to the database provider.  But wouldn’t the industry be better off by having one really well-maintained database, rather than the countless hotel databases that exist across TMCs, card providers, data reporting tools, consultancies and RFP platforms?

Maybe the solution is for one of the data reporting firms (TRX, Cornerstone, Travel GPA?) to partner with someone like Smith Travel Research, with the goal of creating subscriber-based access to the most accurate hotel database available.  Or, perhaps such a database exists, and it just needs better marketing.

What do you think? Want articles like these delivered to you by e-mail?  Sign up here.  It’s free, and you can unsubscribe at any time.

This entry was posted in Data, Hotels, TIILTS, Travel Technology and tagged , , , , , . Bookmark the permalink.

11 Responses to Why Hotels Need Bar Codes

  1. Carey Pascoe says:

    Brilliant.

  2. Tom Ruesink says:

    Excellent post Scott – it always confounds companies when you try to explain it to them. The addresses always get me – the variation amongst how addresses, cities, etc are entered is also huge. I do see more progress in the past year or so than I’ve seen before – but it’s still a heckuva tiger to tame.

  3. Luís Vabo says:

    Scott,

    The mess is even greater when you operate a corporate travel management system, with self booking tool agregating 10 or more hotel operator’s content, including GDS’s hotel content.

    Imagine how to match, compare and filter one hundred thousand different hotels without Gillespie’s Hotel Bar Codes…!

  4. cinthiaf says:

    This is a fantastic idea!

  5. Alan Minton says:

    Scott – This is an excellent analysis of the challeneges surrounding hotel data normalization. Not only does this affect expense reporting but supplier negotiation and duty of care responsibilities as well. We began working with Smith Travel Research at the end of last year. This has been a lot of work for the reasons that you have outlined. We should be wrapped up and have a product available for the market by the time GBTA rolls around.

  6. Graham says:

    My first reaction was postive. Oh, I had a few niggles – cruise ships used as temporary hotels were my first thought and then there’s the issue of apartments which may be used for corporate housing for stays of about a week so you may get apartments offered by separate vendors on the same floor at the same address. Do you go down to the level of bed and breakfast – they get used on business in Europe more than you might believe.

    When I begun to think about it some more I also realised that all sorts of hotel data needs normalising. Phone numbers are my bete noire. Do you include the international dialling code? Do you include the domestic dialling code? There is supposed to be an international standard but few people seem to know or use it.

    Then I started thinking about the proposal. Let’s take the example and suppose it’s listed in the new database as “Salt Lake City Courtyard”. Unless the booking site/GDS and the billing system tell you the new code how do you tie it all together? You still have to work out that Salt Lake City Courtyard,Marriott Courtyard in Salt Lake and Courtyard by Marriott in Saltlake City are all the same place. And, if the booking and billing systems include the code you don’t really need real time access to the database because it’s already there for you.

    And, when it comes to chain codes I believe you need to know what it was and when it changed and what it will be and when it will change – after all your deal may well be with the chain, not the hotel.

    The underlying proposal for normalisation is brilliant but the implementation?

    • Scott Gillespie says:

      Absolutely, the devil is in the details. One way to implement this is to construct an ever-growing alias table for each unique property. It probably needs some text-parsing and matching algorithms to work best, and doesn’t eliminate the need for manual intervention. But over time, the alias table would capture a high percentage of the variations in hotel’s name, address and phone number, yes?

      Alternatively, one can use whatever address data is associated with the property’s transaction to resolve to a lat/lon location. That assumes a preliminary step of address normalization, and the availability of good lat/lon data for the address…an unsafe assumption for locations in some countries, including China.

      Any other suggestions out there?

      • Graham says:

        I’m not wholly convinced. Yes, an alias table, but it’s my belief it would need constant human vigilance and maintenance by people who understand what they are doing and are allowed to question things. It’s not just about adding new aliases it’s also about ensuring out of date ones are flagged (but left in place and dated so people can still find out it’s changed from a Holiday Inn to a Hampton). I’ve seen too many examples of algorithms, however well constructed, getting it wrong and once the data gets corrupted the risk of that spreading in this application is, in my view, high. Remember, this IS going to affect financial transactions and thus needs to be extremely accurate.

  7. Jay Richmond says:

    Having built RADIUS’ first normalized hotel metabase, using a combination of Sabre, Amadeus, Apollo, Worldspan, and HTI data, I can attest that this is a monumental feat. Especially to Graham’s point to introducing systematic errors in the matching process that can be a devil to locate and then correct. We first built ours just to be able to normalize the data sourced from different GDS systems, as well as non-GDS property content, in order to provide consolidated reporting for our multinational clients. The system now inserts and modifies records based on automated algorithms, but still needs to create an exception list that needs human review and action.

    • Scott Gillespie says:

      Jay, it sounds like you’ve really worked through the very messy details involved in this issue. Your point about it still needing human attention is well worth noting. It doesn’t seem that there is any way around this. That’s where I see an opportunity to centralize the human workload, rather than have those manual efforts duplicated across so many travel data shops. Sounds good in theory, doesn’t it?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s