The Five Cs of Hospitality Interfacing (2024)

Often management gets the idea that since several hospitality technology applications are installed on the premises, it seems only logical that they be interconnected. Unfortunately, sometimes when connecting two stand-alone applications, management quickly discovers that the interface is ineffective. Data may be lost, application capabilities compromised, functionality slowed or lost and overall system confidence shaken. In addition, should the interconnected products be purchased from separate vendors, there is likely to be finger pointing and heightened frustration. Who needs such headaches? What went wrong with the interface? Why can’t two systems simply be connected and operate efficiently (i.e. plug and play)?

System Connectedness
Unless a hospitality property is contracting with a single system vendor capable of providing an all inclusive applications package (i.e. a vanilla system), there may be concerns over interconnecting separate applications to a property management system. Typically, hardware connectivity is not as troubling as software and networking issues. Connecting two hardware components can be accomplished a number of ways (cabled and wireless options) and can be established as easily as connecting two phones for a long distance conversation. By lifting the receiver on a pay phone and dialing a country code and phone number, it is easy to connect a local phone to a distant phone. Problems arise when one realizes that the party on the receiving end speaks a different language than the caller. This is analogous to what might happen during a system interface. Running a serial cable between two machines is easy; getting the devices to share information is more complex. In addition to software, some hospitality systems also face occasional network configuration challenges.

For the purposes of this article, the interface of a point-of-sale (POS) system to a property management system (PMS) will be discussed relative to an established set of interface criteria. The five Cs of interfacing are: confidence, contracting, communications, comparisons and contingency planning.

Confidence
Before interconnecting two stand-alone applications (e.g. POS system and property management system) be sure to test each system separately. There should be a high level of confidence in each system’s operational capabilities before attempting to link them together. This is no different than attempting to connect a CD player to a stereo system. Surely one would test the CD player and stereo system individually before attempting to wire them together. If there should be an interface problem and the components were not tested prior to connectivity, troubleshooting the problem is always more difficult.

While independent testing may seem obvious, often interface problems are encountered as a result of failure to prove each system’s functionality prior to interfacing. Once there is confidence that each device is functioning properly, the connectivity is more likely. For example, testing both a point-of-sale system and a property management system prior to linking will prove effective and efficient. The fact that POS transactions flow seamlessly to the PMS should come as no surprise.

Contracting
Before attempting to connect separate systems, management should commission a legal review of all involved product vendor contracts. Often there are contractual interface restrictions requiring direct involvement of the original product vendor when interface activity is contemplated. The reasoning behind this provision is to protect the interests of the product vendor. Data may be stored in a proprietary format, not be easily accessible, or be encrypted, thereby presenting serious interface complexities. Should an unauthorized technician perform the interface that results in erroneous data transmission or application formatting, an interface failure may occur. Unfortunately an uninformed technician may perceive faulty interface transmissions as an application design flaw when in fact it may instead represent a security strategy.

Unauthorized interfaces, in addition to being detrimental to the outcome sought by property management, can be highly problematic to the reputation of the product vendor. For example, when one manager contacts another manager and inquires about the effectiveness of an installed product, the response may be unfair since product performance was negatively impacted as a result of an unauthorized interface. By analyzing existing contract provisions, management will be better informed as to the correct interface course of action. Exercising caution prior to connectivity can prove highly beneficial to the goals of interfacing.

Once management contacts an authorized party to interface its installed POS system to its PMS, the interface can be attempted. Receiving permission from candidate product vendors helps facilitate proper interface activity. An increase in the efficiency of data communications can be expected as well, as both parties have insight to data structures and communication protocols.

Communications
When contemplating an interface, it is important to determine what information is to be exchanged, how frequently and in what format. In addition, there is the question of whether a copy of transmitted data should remain at the original source system or whether it should be permanently moved to the receiving system. Knowing what, when and how interfaced data streaming is to occur is important to effective interface design.

In the case of POS interfacing, for example, how much order entry detail should be transmitted to the property management system? The details of order entry are really of importance to the food and beverage department, not the accounts receivable module of a back office accounting system. Hence, perhaps only total revenue amounts from the food and beverage outlet should be exchanged. When should the POS data be sent to the PMS? Well, since the property is going to bill its guests during service, there is probably no need to transmit POS data as it occurs (real time). Instead it will make more sense to wait until a guest check is closed or if feasible, consider batching the POS data until the end of the meal period, or some later time. What about data format? A workable data transmission format will be dictated by the requirements of the receiving system in the interface. While historically ASCII formatting was fairly commonplace, Windows-based POS systems employ open database connectivity formats. Open database connectivity (ODBC) is an open standard application-programming interface (API) for accessing a database. By using ODBC statements in a program, the interfaced system is capable of accessing files in a number of different databases (e.g. Access, dBase, DB2, Excel and text). A major supplier of ODBC programming support is Microsoft. Although Windows was the first to provide an ODBC product, versions now exist for UNIX, OS/2 and Macintosh platforms.

Management must determine whether data transferred from a host system to an interfaced system remains on the host or is deleted at time of transmission. For hospitality management applications, this tends to be a difficult decision as the data is often useful to both systems. Should a guest question a transaction posting, the accounting office would like to have access to the original transaction to prove its work. Leaving a copy of the original data in the source system provides a more comprehensive reference base and ability for the department to build analytical reports. While there is no clearly preferred rule for data storage and removal, copying data from a source system to a non-volatile backup media (e.g. tape, zip disk, CD, etc.) is usually a workable option.

Comparisons
One of the most important elements of an interface project is identifying already installed users. One of the biggest mistakes hospitality management can make is not contacting currently installed users to determine the best means by which to accomplish an interface. How can management learn of installed users? Product vendors normally have a detailed list of installed users and tend to be aware of successful (and failed) interfaces to and from their product line. By inquiring about successful interfaces with an installed product vendor, and contacting properties of a similar size and scope, management can gain invaluable insight into interfaced solutions. Although this appears to be a low cost, obvious strategy, it is not usually exercised. Too often management seeks out interface partners without inquiring about existing solutions with an installed product vendor.

When considering interfacing the hospitality’s POS system with its PMS, the most efficient approach is to inquire with the hospitality system vendor as to which of its installed users currently have successful POS interfaces. Such an inquiry will provide management with a list of installed users, if any that have had a successful experience with the two systems under consideration. If there are experienced users, then management should contact those properties and formulate an interface strategy. If there are none, then contacting the POS vendor next with a similar inquiry, may be wise.

Contingencies
A major concern of hospitality management tends to be that staff will become too automation dependent and forget the basics of operations. In other words, staff becomes computer dependent, not computer oriented. Management must be sure that staff members are trained to operate the enterprise efficiently should the interface fail during the data processing cycle. There needs to be a set of downtime strategies that assist staff in continuous business operations even if the interface crashes. In addition, there needs to be some attention paid to maintaining an inventory of spare parts should any be required by the interface. The point being that if an interface fails or loses integrity, there needs to be a way to audit and/or restore the system so that data processing objectives can be accomplished.

For example, when interfacing a POS system to a PMS there needs to be a set of provisions governing backup procedures so that proper processing can be accomplished even if the interface is not operational. What often happens is that departments get so dependent on an interface they may forget how to function should there no longer be an electronic linkage between two installed systems. One popular strategy is to develop a procedures manual that documents the flow of data and information in a workable interface scenario. Then, if the process fails, a backup procedure can be invoked. Contacting installed interface users will help the hospitality’s management develop such contingency plans.

Summary
The decision to interface stand-alone hospitality system applications requires strategic planning. While the technical aspects of the interface warrant careful management review and active participation, there are additional considerations.

Remember Kasavana’s three basic interface-nevers:

1. Never be the first user of an interface.
2. Never be the largest user of an interface.
3. Never be the last user of an interface.

Michael L. Kasavana, Ph.D., CHTP is NAMA Professor in Hospitality Business, School of Hospitality Business, Michigan State University. He can be reached at mailtkasavana@pilot.msu.edu.