Few issues frustrate hotel technologists more than interfaces.

The importance of sharing data across multiple systems in hotels grows every year. Yet some of the most common complaints I heard thirty years ago are still around today, maybe just a little less common. We still hear “my vendor doesn’t have the interface I need” or “we bought the interfaces from both vendors to connect their systems, but they just don’t work together the way we expected.” Closely related is “our vendors interface with each other, but one of them wants to charge us $10,000 and we can’t afford that.”

Thankfully some good options are emerging in the marketplace to connect almost any two systems even if the vendors don’t offer an interface (or it’s too expensive), and my next article will cover them. But before getting to the solutions, we need a solid understanding of the problem. For many interfaces, general management staff at individual properties are the ones who identify the need and place the order. They do this without the benefit of the specific IT expertise needed to assess whether an interface can really solve the business problem at hand.

The truth is, many buyers don’t ask the right questions about interfaces, and then are disappointed with the results. Today’s article is not intended for technologists who understand interfaces. Indeed, interfaces are far more complex than what I will cover here, and an expert’s reaction to some of my statements will likely be along the lines of “sort of, but not exactly.” Rather, this article covers general principles. It is intended for hotel management teams simply trying to find a way to get their systems to talk to each other, or for expert system users who have limited exposure to the technical design of interfaces. It should help you get the desired end-result without suffering quite as many battle injuries.

There is unfortunately no silver bullet. You must do your homework in each case. It is not always simple, but you can improve your odds of success by asking the questions and following the steps I will outline here. My next article will identify some software solutions that can help when your vendors cannot, or that may offer more functional or cost-effective options.

One Way or Two Way?

Vendors and even many hotel IT staff may talk about interfaces as “one way” or “two way.” At best, these terms are meaningless; in many cases they are flat-out misleading. I banned them from my own vocabulary about 30 years ago, and you should too. All a “one way” interface really means is “System A can send something to System B.” All “two way” means is “System A can send something to System B and System B can send something to System A.” They don’t tell you what “something” is or what the receiving system is expected to do with it. It’s like describing the characteristics of a highway interchange and how to navigate it without knowing where either highway goes, or the driver’s destination or current location and direction of travel.

The first two questions you need to ask are not “one way or two way,” but rather what specific data is being sent, and in which direction. The example I will use is an interface between a Central Reservation System (CRS) and a Property Management System (PMS) because most readers are familiar with their roles, and because it richly illustrates this point. But the same principles apply to any two systems.

Many different types of data might be exchanged between a CRS and PMS: new and changed reservations, cancellations, no-shows, rates, inventory, availability, length-of-stay controls, deposit policies, cancellation policies, guest profiles, group blocks, room-type descriptions, meal packages, whether the guest is checked-in and if so their room number, and so forth. Reservations might be limited to transient-only or might include ones in group or wholesaler blocks, at negotiated rates, or even at complimentary rates. Few CRS-PMS interfaces support all of these; many handle only transient reservations and cancellations, and only in one direction.

If your only expectation is that a CRS can deliver transient reservations to the PMS, then most commercially available interfaces can do this. If, on the other hand, you need the PMS to send rates and availability to the CRS, then you need an interface on both sides that will handle that. And if you need reservations or changes made in the PMS to flow back to the CRS (for example so that your central reservation agents will not view an old version of a reservation that has been changed by hotel staff in the PMS), that’s a totally different requirement that the more basic CRS-PMS interfaces cannot support. Group block bookings are often an entirely different animal, requiring an enhanced interface if they are supported at all.

In other words, you simply cannot assume that the data that you want will be included in your interface; you need to make an exhaustive list and ask about each item. Any use case that is handled differently by the sending or receiving system likely requires specific support by interface code at one end or both.

This detailed review should be conducted at the data-element level. For example, a CRS-PMS interface might deliver a reservation, but not handle every field. Do you need a credit card number (or payment token) included? Details of the cancellation policy? Commitments for ancillary sales? Are the fields defined the same way in both systems, or are they different? For example, an address might have several fields in one system for the street address, city, postal code, and country, while the other system might store all of these in one field, with a slash or some other character indicating where the lines need to be broken. Differences are completely normal, but each one needs to be specifically accommodated by the interface and may require special translations at one or both ends. Many of these differences will already have been sorted in a mature interface, but it’s not unusual for each new deployment to find ones that matter to them but didn’t matter to anyone else.

The third question to ask is what the receiving system will do with the data. You need to be specific about what you want to happen and verify that the receiving system will do it. When a CRS sends a new reservation to a PMS, you probably expect the PMS to create its own copy so that you can check the guest in from it (and every CRS-to-PMS interface I know of will in fact do that, at least in some cases). But what else? Does it need to send updated inventory or availability status for the rate or room type back to the CRS, since there are now fewer rooms available to sell? Or does the CRS not need that information (perhaps because it is tracking inventory itself)? Does the PMS need to process a deposit or prepayment, or validate a credit card? None of these actions are automatic. They may require special versions of an interface or changes to configuration settings, or a special add-on module or enhancement to one of the systems, or they may not be possible at all. Don’t assume, ask! And get the answers in writing, with a guarantee from both vendors that the interfaces will be able to send/receive all the data you need, and that the connected systems will act on it the way you want.

Where is Your Golden Data?

Often the same information resides in multiple systems in hotels. Reservations may be held in both the PMS and CRS. Guest profiles might sit in both the loyalty system and the customer database system. Housekeeping status might be mirrored in both the PMS and the housekeeping system. Data overlap is very common in hotels with multiple systems, and unless you can completely ignore the version in one system, interfaces are needed to manage it. Whether you need them and how they should work depends on your operational needs and often the limitations of systems you are unable to change.

If both systems need to be totally accurate at all times, then it’s easiest if only one system changes data, and the other one simply gets notifications from the first of every change. If housekeepers update rooms status in the housekeeping system but the PMS needs to know the status so it can assign guests only to clean rooms at check-in, then it may be fine for the housekeeping system to simply send the updates to the PMS.

Since most room status updates are initiated by housekeeping, this approach makes sense. But what if a guest comes back to the front desk and reports that the room they were just checked into has not been cleaned? (Yes, it happens!) The front desk associate will want to mark the room as dirty, but they may only have access to (or training in) the PMS, not the housekeeping system. If they change the status in the PMS, that change needs to get back to the housekeeping system so that housekeeping knows to clean the room. Without an interface that supports this situation, the front desk might have to call a supervisor to make the change in the housekeeping system. Depending on your operation, this might or might not be an acceptable solution.

But what if a front-desk associate tries to do update the status in the PMS anyway (maybe they learned how at another hotel)? This may result in a room that housekeeping never realizes needs to be cleaned, and potentially lost sales. Preventing this means asking your PMS vendor if they can turn OFF the ability to update room status. Many PMS vendors have options for things like this, but you will likely have to ask them. Part of implementing an interface is setting the configuration of the two systems appropriately, and this is something that many (maybe most) vendor deployment teams cannot do well. While their installers or configuration specialists may know their own system inside out, they usually don’t know the system you are trying to connect it to or exactly how you want to use it. Nor is it realistic to expect them to!

To be sure, you may choose to live with the occasional errors that will result if you haven’t thought through every different situation and implemented interfaces and configuration changes to support them all. But this should be a conscious choice that you make based on a realistic assessment of whether you can deal with the consequences when things go wrong – not just an unhappy result of buying an interface without asking the right questions. Data synchronization errors can result in unhappy guests, service recovery costs, additional staff time to investigate and address the issue, revenue loss, and confused or frustrated staff. In some cases, the impact will be minor enough or sufficiently rare that can live with the risk. But you cannot assess that unless you know what the risks are.

A key rule to try to follow when data is duplicated across systems is that only one system should be “in charge of” any specific piece of data. This system’s version is sometimes referred to as the “golden copy” – the one that can be trusted when any of the other systems disagree. Even if you allow changes to be made both systems, and send updates back and forth, this is a good policy because there are always situations where they will get out of sync (for example when one of the systems has a bug or is down for maintenance). When they do, you may need to be able to refresh everything to the best copy. Ideally any human-initiated changes to the data should be made only in the system with the golden copy. If that’s not possible, then changes made in other systems should be sent immediately to the other one using a highly reliable interface process such as synchronous messaging (described below). Otherwise, data will inevitably get out of sync, and you may not find out until a guest has been disserviced, such as by being checked into a dirty room.

Did You Get My Message?

Regardless of design, all data exchange interfaces involve one system composing a message with data or instructions and then sending it to another system. Just as messages can be sent by snail mail with varying degrees of speed and reliability, the same is true for interfaces. Knowing the basics of messaging protocols, even at a nontechnical level, is important when choosing the right solution. Reliability and speed are the important things to watch.

An interface is reliable if every message sent by one system is received and processed by the destination system. Errors can occur during transmission because the destination system is down, or because the destination system detects a problem trying to act on the message (for example, if it receives a new reservation for a room type that is sold out). They can also happen because of software bugs.

Many early hotel system interfaces were designed using the principle of “throw the message over the fence and pray,” often using a serial cable to drop a file into a specified folder on the destination system, which would periodically scan that folder for messages waiting to be processed. If there was a glitch in the process, the messages might simply be lost forever, and ignored. Or, if the hotel was lucky, the messages might have made it to the destination system and are still sitting there waiting to be processed. This approach is error-prone and usually requires onsite IT support to investigate, fix the problem, and deal with any lost messages whenever possible. The speed of these interfaces could also be somewhat slow, as messages were often batched before sending, or found only via a periodic scan for new messages received at the other end. The reliability and speed might be acceptable for some applications, but not for others.

While many such interfaces still exist in hotels today, modern approaches (especially with cloud-hosted systems) are much speedier and more reliable. The process usually entails one or more

“handshakes” between the two system to verify the receipt and/or processing of a message, but there are different approaches with varying implications for speed and reliability. With some interfaces, the receiving system responds with “I got your message and processed it successfully” (or did not); this is called synchronous messaging because the two systems are synchronizing their activities around the message in real time. With others, the receiving system initially responds “I got your message” and then, when it is finished processing, initiates a new message back to the original sending system with the result (this is called asynchronous messaging).

Synchronous messaging might be needed where the first system needs to know the second system has acted on the message before closing out a transaction. For example, a CRS sending a new reservation to a PMS might not want to confirm the reservation to the guest until the PMS has accepted it, just in case inventory was out of sync. A point-of-sale system processing a guest room charge might want to wait for a confirmation that the guest is checked in and is authorized for room charges in the PMS.

Asynchronous messaging might be preferable in situations where the second system might need time to process the request and the first system isn’t dependent on an immediate result. For example, a CRS might request a revenue management system to reoptimize rates and inventory, which could take some time to complete. It can also be useful if the destination system may be subject to periodic outages or if human review of certain transactions is required in the second system.

Well-designed modern systems isolate interface processing in a module that can handle things like queueing outbound asynchronous messages if the network connection is lost or if the other system is down or backed up. Such modules can also queue inbound messages if they cannot be immediately processed, and can log activity so that errors can be researched after the fact. Some interfaces support both synchronous and asynchronous processing, enabling immediate response when possible, but falling back to queued asynchronous messages when the receiving system is unable to respond. How interfaces will respond in these situations is an important thing to understand when designing your solution.

Sometimes you don’t really need the handshake described above. For example, a nightly handoff from a PMS to the accounting system may simply send the message and not worry about whether the accounting system received it. In a case like this, it may be discovered by accounting staff that can simply recover the message manually or resend it. This might be fine if no one is going to look at it until the next day anyway, or not acceptable if corporate is expecting the data in time to prepare a consolidated report across multiple hotels.

In many cases, you don’t get to choose the interface approach; you must take what the vendor provides. But it’s important to ask questions to understand the limitations and what the consequences will be for the operation when (not if) something goes wrong. If you know that a CRS-PMS interface might regularly result in out-of-sync inventory because of a sluggish, less-than-real-time approach, you can try to compensate, for example by requiring that all reservations be processed in one system or the other. Some major brands, for example, only allow reservations to be made in the CRS until the day of arrival (it has the golden copy and is used by both central and hotel reservations offices). On the last day, it may allow reservations to be taken in the PMS as well, so that the front desk can accommodate walk-ins without having to find someone trained in the CRS while the guest stands and waits. This minimizes the risk of oversales for most of the selling period, and the hotel still has a way to shut down CRS sales on the day of arrival if it is expected to be full.

Conclusion

If a direct interface between the systems isn’t an option (maybe one of your existing vendors won’t support what you need), then there are several alternative approaches, which I will cover in my next column. The right question to ask is, what will be the consequence if a message sent by one system is not received by the other one? Could a guest get walked because a reservation isn’t delivered? Could their room key fail because a check-in message never reached the lock system? Could a deposit get lost because the PMS message to the payment gateway never arrived? You may well decide to accept certain risks to reduce your interface costs – but you should also be prepared to deal with them when they happen!

‍