⚠ We would appreciate if you would disable your ad blocker when visiting our site! ⚠

Speaking a Common Language

Order a reprint of this story
Close (X)

To reprint an article or any part of an article from Hospitality Upgrade please email geneva@hospitalityupgrade.com. Fee is $250 per reprint. One-time reprint. Fee may be waived under certain circumstances.


June 18, 2018
Ron Strecker

If only I had paid more attention in school when I took a foreign language. The ability to interact with a different culture using a common language can make the difference between a nice vacation and a great vacation. My travel destinations, though not exotic, can often present opportunities to explore regional variations of English.

When we interact with each other in the absence of a common language, a lot can get lost in translation. The interaction will take longer and, if a critical piece is missed, there will be a level of frustration felt somewhere. Interactions like this are happening constantly. Sometimes through verbal communication, sometimes through non-verbal communication as in the case of technology.

Speaking a common language, in the context of system interfaces, is something most of us can relate to. Through the efforts of organizations like HTNG, and through the evolution of greater standardization in messaging, interfaces have come a long way. There is still, however, an area where I think the vendor community could loosen up a bit in the realm of standardized interfaces. I’ll have more on that at the end, if I have time.

In the spring 2017 issue of Hospitality Upgrade, I had another article titled, “From the Front Door to Boardroom,” that described the journey data takes. Following data creation from the moment a guest orders a burger all the way to where it appears as net operating income on the financial statement should be simple, but it’s not.

In that article I talked about how data can show up in various reports starting with the source application. The path for some of this data continues into as many as three other report levels. Each level becomes more summarized with the addition of various metrics and ratios. The goal at each level is to take data and turn it into valuable management information. The audience may change at each level, but the goal remains the same.

Management information is a key example of where a common language is important.  Anyone looking at the daily flash report who doesn’t understand occupancy percentages and average daily rates (ADR) may not understand what to do with the information. But if we take the time to train them on a few new terms, the report takes on a whole new meaning.
It is important that this new vocabulary is understood by more than just those who use these terms every day.  You would expect anyone working the front desk to understand occupancy and ADR (average daily rate). You should also expect your finance, HR, IT and maintenance teams to understand these terms. 

Any department that supports the operating departments should be responsible for learning the lingo they use every day running the hotel. After all, we expect them to learn a few of those boring administrative terms like purchase orders and employee status change.

In the table below, I describe the characteristics of the different report levels and how a common language exists around those levels.

Let me give you a few real examples of how easily things can go awry in the absence of a common language.
Suppose you’re the new manager for one of the hotel’s restaurants and you are trying to understand your payroll expense. You call your friendly payroll department and request a listing of your staff with the hours and pay from the previous month. Do you think your request was clear? Are you hoping to see all the hours your staff worked for the calendar month?  What happens if payroll sends you a report for all the hours paid during the month based on pay days? These two reports are different.

Another example that has become all too real for those who hire staff is the definition of full-time employee. The Affordable Care Act defines full time as any employee working more than 30 hours each week. The restaurant manager needs a full-time server to work the dinner shift. In the manager’s use of the term, they are looking for someone to work five shifts each week, with each shift being five hours. HR argues with the manager that 25 hours per week does not qualify as full time.
Both examples can be easily avoided if there were an effort on both sides to speak a common language, even if the words are the same. Sometimes, all that is needed is a simple follow-up question or just one more word in the request. Both sides should actively educate each other about potential misinterpretations. This issue is much worse when it is an emailed request. There is less opportunity to miscommunicate if we talk in person or by phone. Try it out sometime.

Getting our expert-self to speak a language common to the audience in front of us is imperative. When I present financials to the board of directors, I have a broad range of individual expertise in the audience. There are financial experts, hotel experts and lawyers. There are others who may not be as savvy in the topics being presented.

Do I dumb it down at the risk of missing key points? Maybe.
The better approach is to help educate the novices to a level where they become comfortable talking about the topic. Be patient and encourage questions. 

The same holds true if you are in a weekly staff meeting reviewing the daily report. Don’t miss an opportunity to teach. Many of those managers are tomorrow’s leadership team.

Vendors, listen up. I promised that if I had room I would return to the topic of standardized interfaces. Speaking a common language between two applications includes having different vendors think of their customers’ needs.

If I want to select a POS to connect to my PMS, there is an expectation that I can get all my POS data flowing smoothly into my PMS where I generate daily reports in detail without any manual intervention. But if the POS vendor is different than the PMS vendor, you might be faced with an interface that has been purposely reduced in capabilities. True story.

Another example is that for years there has been a desire by customers to use a sales and catering application of their choice to generate a banquet check. Then, in most operations, someone will post the check into the POS as open food, open beverage and miscellaneous income. Why can’t an electronic version of the banquet check, with PMS transaction codes in the background, get imported directly into the PMS?

Learn how to speak a different language today.

want to read more articles like this?

want to read more articles like this?

Sign up to receive our twice-a-month Watercooler and Siegel Sez Newsletters and never miss another article or news story.