‍

One of the biggest challenges faced by vendors in the hotel industry is keeping track of the constant changes in their customer base. One large distribution company estimates that 10% to 15% of their hotels change brands each year. Add to that the changes in management and ownership (key relationships for many vendors), new openings, closings, and name changes, and it is likely that within any given year, at least 20% to 25% of hotels undergo some change that matters to their partners in the vendor community.

No database tracks this information with any degree of accuracy or universal coverage, and vendors have no way to be systematically notified of changes. To be sure, each brand, management company, and ownership group knows its own hotels and how they are changing. But there are tens of thousands of such companies around the world, and hundreds of thousands of independent hotels. Vendors cannot exactly ring them all up every Monday morning just to ask “hey, has anything changed?”

It is not that no one has tried. Several companies offer databases that list many hotels, typically with cross-references such as Global Distribution System (GDS) or Online Travel Agency (OTA) codes. Many vendors buy these, often spending in the range of $40,000 a year. While they are helpful, vendors complain that they are incomplete, inaccurate, and fail to capture many changes on a timely basis (much less provide advance warning).

Most of these commercial databases are distribution oriented, and as such tend to track brand relationships but not managers or owners (which matter more to most non-distribution vendors). Additionally, while several vendors have over the years proposed solutions using their own databases, other companies have been understandably wary of giving anyone (especially a competitor) commercial control of a service that would, if successful, be mission critical.

A not-for-profit sponsoring organization would avoid this concern, and there have indeed been efforts by multiple nonprofit industry associations over the years, some dating back as far as 1997. But none have gotten off the ground. Several major global associations jointly identified the lack of such a database as one of the top three industry challenges in 2011, as covered in this article, published at the time in Tnooz. Hospitality Technology Next Generation (HTNG) created a workgroup about six years ago with participation from multiple associations as well as vendors and hoteliers. It defined the problem in detail as well as the technical details of a solution.  But the effort withered for lack of a business plan and funding.

Today, several industry veterans continue to work informally to find a path forward. Ideas that could work, including a business plan and funding models, have emerged from these efforts. They simply need enough industry players to say “yes, this is a problem we need to solve.” If this happens, the plan and models can be adjusted, funds raised, resources brought on board, and a solution launched.

Why It Matters

The lack of a complete, accurate, and timely registry of hotels is a significant problem for many vendors. It impacts hotels as well, but indirectly through the inaccuracies and inefficiencies in vendor databases and processes. I will start by identifying just some of the negative consequences for vendors, then explain how their issues impact hotels.

• Onboarding. Vendors who sign brands, management companies, and ownership groups often need to onboard many properties at once. Some of these are often already in their own database as customers or prospects, but often under former names, with slight variations in address, or different phone numbers. Add variations in languages and character sets and it quickly gets messy. Duplicating an existing customer can cause major issues, so there is often a manual, time-consuming, and error-prone process of matching the new properties to existing ones

• Cross-Referencing. Most technology vendors maintain interfaces to other systems. Building these requires entries in a cross-reference table for each partner. These entries identify the correlation between the hotel identifiers of the two systems, so that each system participating in an interface can interpret the messages to and from its partners. This requires a similar labor-intensive process as onboarding but is even more challenging because each company’s standards for entering hotel names, addresses, and phone numbers can be different. Furthermore, the cost of errors is greater because bad cross-references cause interfaces to fail. A large vendor with many interfaces may have to maintain cross-reference tables for hundreds or thousands of partners and tens or even hundreds of thousands of hotels.

• False reservations. These are a very common issue for booking websites, often occurring when a hotel changes brands (or closes entirely). When the hotel itself is undergoing major changes, staff are busy and rarely have time to notify every distribution channel that sells their hotel (if they are even aware they should). Guests book a particular brand they trust, only to discover when they arrive that no such hotel exists. Sometimes this is just a puzzlement to the guest that they ended up in a differently named hotel than they expected. But other times it gives rise to support calls, rebookings, and compensation.

• Billing. Vendors often find out about ownership, management, or brand changes in their customer base only when they stop getting paid. After a few months of escalating collection notices, overdue accounts get sent to the collections team. Often, invoices were sent to the old management company or owner, or to out-of-date email addresses. Outgoing owners and managers may have no reason to bother notifying vendors, and incoming ones often do not even know who all their vendors are. Some larger vendors have entire departments chasing old invoices. Perhaps half of these could be avoided if they had reliable notification of most changes.

• Fraud. Particularly in distribution, bad actors often create fake hotels in online travel websites. Doing so can enable them to sell reservations, collect funds, and disappear. Some larger distribution companies have entire departments to deal with this type of fraud.

• Change Management.  Vendors whose products are interfaced to other systems constantly need to update those interfaces when brand or management affiliations change. They may for example need to swap out one property management system (PMS) interface for another one, and then reconfigure details such as room-type or rate-plan translation tables. Requests to do this often come in only at or even after the date of change, because the hotel did not understand the dependency until something broke at cutover. At that point, the hotel wants the change made instantly, while it may take the vendor hours, days, or even weeks of scarce resources to implement.

Hotels suffer indirect consequences of these vendor challenges.

• Lost business. Many distribution channels require several weeks to fully implement a hotel brand change, but often get no advance notice. This means the new hotel is not fully represented in online channels in the initial months after reflagging, and sales are lost.

• Misbranding. It is far from unusual to find misbranded electronic systems in hotels. If you are checking into a Marriott and the credit-card device says Welcome to Hilton, or if the television or Wi-Fi landing page at a Wyndham invites you to explore the Hyatt, the hotel has a problem. Asking vendors to make these changes is not hard but is time-consuming. It is often simply one of a thousand things that should be done as part of rebranding but are either forgotten entirely, or are too far down on the list to get dealt with in time (or sometimes ever).

• Notifying vendors. Lack of a central registry means that hotels must notify every vendor of any change (name, brand, management, ownership) that affects display, descriptions, transaction flow, contracting, or billing. Most hotels have 50 to 100 technology vendors alone (not to mention vendors of soft goods, foodstuffs, cleaning supplies, and many other items). It is a lot of work to notify them all, but there are potentially negative consequences for any that get missed.

• Guest satisfaction.  If your vendors have issues resulting from incorrect information, change backlogs, out-of-date interfaces, or third-party fraud, it can negatively impact the guest experience. It may not be the hotel’s fault, but it is the hotel’s reputation.

‍

What’s the Solution?

The solution, simple in concept but challenging to create, is a universal registry where each accommodation facility is assigned a unique, lifetime identifier – one that persists through brand, management, and ownership changes. Hotels (directly or through their brands or management companies) add critical core identifying data to the registry: name, address, phone, brand affiliations, management affiliations, ownership (all in multiple languages where needed). Vendors can subscribe, enabling them to look up identifiers or to retrieve information associated with them. They can also subscribe to be notified of upcoming or recent changes for hotels they service.

The registry would work very much the same way as the Internet’s Domain Name Service (DNS). If you are not familiar with DNS, it is simply a registry of every Internet domain and contains pointers to the IP addresses of associated resources such as web and mail servers. The registry entry for each domain name is permanent; if a company moves its web or mail servers, it simply updates its record to reflect the new IP address. Users continue to use the domain name to access the website or to send email. Without DNS, we would each have to maintain our own database of IP addresses for the sites we visit and the domains we send mail to. And they would fail every time one of them moves to a new server.

A critical design consideration for the registry is that no hotel or vendor should need to change their internal identifiers to implement an industry-wide unique identifier.

• Most existing systems used by hotels and vendors already have cross-reference tables used by their interfaces that map their internal codes to those of their connected partners; the unique identifiers are simply stored in a new column in those tables.

• Identifier translation occurs as interface transactions arrive or depart – exactly as they do today in each interface, but instead of translating from a partner’s property code to an internal code, receiving vendor would translate from the industry identifier to their internal code.

• In most cases no programming changes should be needed (or if they are, they will usually be very simple). This is true even for legacy systems.

• As partners start to adopt the industry-wide unique identifier, their columns in their partners’ translation tables can be removed, and will no longer require ongoing maintenance (a significant task for many vendors and some hotel companies).

Like DNS, the hotel unique identifier registry would be run by a not-for-profit entity and would expose only information that the hotel already puts into the public domain.

• Every building used as a hotel would get a unique identifier that would follow it for as long as it remains standing. Many other types of accommodation could also be supported, although some would require special consideration.

• Name, address, phone, geographic coordinates, and brand are always public domain (at least for currently operating hotels) and would be tied to each identifier (in multiple languages where needed).

• Management and ownership affiliations are often public, as are dates for future rebrandings or management changes. However, where these are sensitive, access could be restricted to approved partners.

• No information that would be considered competitive with existing products and services would be included. The goal is not to create a content database of information about hotels, but rather to fill the one gap that the vendor community has been unable to fill on its own, with the minimal information needed to fill it.

An interesting extension (furthering the parallel to DNS) would allow hotels to specify service endpoints. These are web addresses for services used by the hotel for critical functions like reservations delivery, folio postings, or payments. This would take much longer to become fully operational but could have a huge impact on the speed and cost of changeovers.

• If all hotels and vendors used service endpoints, it would enable automated system changeovers both by hotels and by vendors when hotels rebrand, change management companies, or change vendors.

• For example, if a hotel publishes its content management service endpoint, then approved distribution channels could use that endpoint to obtain the latest content for the hotel, helping ensure that content is updated in real or near-real time. If the hotel changes its content provider, any partners using the service endpoint could be updated instantly (assuming they already interface with the new partner).

• A vendor that was notified that a hotel would be rebranding on July 1 could be advised of the service endpoints for the new PMS, for example. Assuming that the new PMS was cloud-hosted, and that the vendor already had an interface to that PMS for other clients, the entire switchover process could be set to automatically happen at midnight on July 1.

• If the existing point-of-sale system, payment gateway, TV system, door lock system, telephone system, and other systems are using the registry and service endpoints, they could all process the update at the same time, with no manual effort. How cool would that be?

Complete cross-vendor automation is not possible unless there is universal agreement on the question “which hotel are we talking about?” And if you think that is an easy question to answer, I recommend spending some time with the database team at any large vendor that is responsible for onboarding new customers.

A critical design consideration for a semi-public registry is that hotels must own and control their own data. While most hotels will delegate maintenance of their registry entry to brands, management companies, or third-party service providers, the hotel owner is the ultimate authority. Brands must also have control over the use of their name, meaning that a random hotel owner cannot claim to be a Holiday Inn unless IHG, as owner of that brand, agrees. Furthermore, fraud controls can help ensure that only legitimate hotels (or other public accommodation providers) appear in the database. All of these and many other issues have been addressed in the design work done to date.

What Can Make It Happen?

Research with numerous vendors has identified a strong need and willingness to pay from all but the smallest vendors. The cost for most vendors would be no more than many of them are paying for the imperfect solutions today. Elimination or reduction of manual-intensive processes would multiply the savings.  

There is little question that once such a registry is up and running, it could charge fees that cover its costs. Vendors would provide the bulk of the revenues from subscriptions or usage fees. To avoid resistance to participation, hotels would be able to participate for free and/or for a very nominal fee.  Most of the proposals have ranged from $1 to $10 per year per hotel, mostly to ensure that smaller hotels that shut down can be detected through their nonrenewal. This would solve a major problem distribution channels face today; they often continue to list properties that closed years ago (occasionally even with availability!).

To create such a registry, three major elements are needed.

1. Either an existing or new non-profit organization will need to take the lead. Many for-profit entities have proposed hotel registries in the past, but other vendors would not sign on because they did not trust a company (possibly a competitor) with a profit motive.

2. Funding is required, probably in the range of $1 to $2 million to build the database and software and to launch it into a critical mass of the market. The technical code development is not difficult, but payroll costs need to be covered until the registry generates enough subscription and usage fees to break even. In the absence of an existing nonprofit taking this on, funds could be raised by selling charter memberships to vendors. These charter memberships would entitle them to reduced-fee access for long enough to pay off the amount invested and a premium for risk and interest. Several strategies might reduce this funding requirement; the higher estimate assumes none of them prove useful.

3. A seed database (or multiple databases), with enough hotels to meet most of the needs of most vendors, is required.

• This should not be needed permanently, since the objective is to get hotel owners, managers, or brands to take over their records as soon as possible so that they can be close to 100% accurate.
• But getting hotels to take control of their records will take years. While many major brands have said they would contribute their data, there are thousands of smaller ones and hundreds of thousands of independent hotels. It would be impractical to get them all on board until there are clear benefits to hotels. With most of the benefits to hotels being indirect and recognized only after the registry has been up and running for a while, this will take time.
• Third-party sources that cover most of the world’s hotels (and that, while imperfect, are accurate enough for a transition period) can fill the void for non-participating hotels until they join. Several companies with databases of several hundred thousand hotels worldwide have expressed their willingness in concept to provide their data on commercially reasonable terms.

‍

How Can You Help?

If you are a vendor and think you would benefit from the creation of a registry of unique hotel identifiers, please reach out to me (below) or Robert Cole and we can put you in touch with one of the team that has been championing this (several of us for years, as volunteers). It is not possible in this short article to answer all the questions, but there is much more that can be shared with those who are interested in finding a solution – including answers to most of the questions and objections that have been raised over the past 27 years.

‍

‍