What is hospitality data, really? An operator's definition

Ask ten people in a hotel what “hospitality data” means and you get ten answers. The revenue manager means rooms pace and the RMS forecast. The director of finance means the P&L and the labor lines. The DOSM means the group pipeline in the sales-and-catering system. The F&B director means covers and check averages in the POS. The GM means the guest satisfaction scores that land in his inbox every Monday. Each of them is right. None of them is describing the same thing. That is the whole problem in one sentence, and it is why “hospitality data” as a phrase is almost useless until you define it from the operator’s chair instead of the vendor’s.

So let us define it properly, because the definition determines what you build, what you buy, and what you stop wasting money on.

What hospitality data actually is

Hospitality data is the full operating reality of a hotel or restaurant, recorded as numbers, and then scattered across the seven or eight systems that run the building. It is not a database. It is not a dashboard. It is not a vendor’s platform. It is the exhaust of every decision and every transaction in the operation, and the defining feature is that it lives in pieces that were never designed to be read together.

Walk the operation system by system and you can see the whole surface area.

The PMS (Opera, OnQ, Maestro) holds the rooms ledger, the group blocks, the rate plans, the folios. It is the spine of the hotel, and the one system everyone agrees is authoritative right up until you ask it a question it was not built to answer.

The RMS (IDeaS, Duetto) holds the forecast, the demand signal, the optimized rate. It knows what the hotel thinks tomorrow looks like.

The sales-and-catering system (Tripleseat, Delphi, Amadeus) holds the group pipeline and the banquet revenue: definite, tentative, booking pace, function space. At a full-service hotel that is a quarter or more of total revenue, living in a system the rooms team rarely opens.

The POS (Toast and its peers) holds every cover, every check, every item rung in the outlets: the menu mix, the void rate, the actual spend per guest the catering contract only estimated.

The labor system holds the schedule, the hours, the punches, the overtime, the productivity standard. It is the largest controllable cost in the building and it almost never sits next to the revenue it was deployed against.

The guest and sentiment layer (GSS surveys, OTA reviews, social mentions) holds how it actually felt to be there. It is the only data that measures the product instead of the transaction, and the most orphaned of all of them.

Underneath all of it, the back-office P&L in the accounting system holds the version of reality the owner and the CFO actually believe. Reconciled monthly, late, and disconnected from every operational system that generated the numbers in the first place.

That is hospitality data. Seven or eight authoritative sources, each true on its own terms, each built by a different vendor for a different job, none of them designed to be joined. The operator does not experience a hotel as eight systems. The operator experiences one building, one P&L, one guest. The data does not.

Why it is a connection problem, not a collection problem

Here is the part the vendors get wrong, usually on purpose. Almost every conversation about hospitality data is framed as a collection problem: you do not have enough data, you are not capturing enough, you need another platform to gather more. That framing sells software. It is also backwards.

Hotels are not data-poor. A mid-size full-service hotel generates more usable data every day than its leadership team could read in a month. The folios, the forecast, the pipeline, the checks, the punches, the surveys, the ledger. All captured, all the time, by systems you already pay for. The operator is drowning in collection.

What the operator does not have is connection. The forecast in the RMS and the actuals in the POS never sit on the same row. The labor hours and the covers they served never line up by daypart. The catering pipeline and the banquet revenue in the P&L never reconcile without somebody doing it by hand, heroically, for a few weeks, and then stopping. The data to answer almost any real operating question exists. It is just in two or three different systems, defined three different ways, owned by three different people, and nobody has joined it.

This is why hospitality data services that promise to “give you more visibility” so often fail. They add another screen to a building that already has too many screens. The job is not to collect more. The job is to connect what is already there so that one number means one thing across the whole operation. When the operator’s data is genuinely connected, the five systems stop disagreeing, and the Monday meeting stops being a debate about whose number is right.

The honest framing, the one we use, is this. Hospitality data is not a collection problem. It is a connection problem. Real hospitality data solutions are measured by how well the sources join, not by how much they gather.

Why this definition matters to an operator

If you accept that hospitality data is fundamentally a connection problem, three things change about how you run the building, and all three save real money.

First, you stop buying point tools to plug gaps. Every disconnected system tempts you to buy another that promises to show you the thing the last one could not. That is how a property ends up with fourteen logins and no single source of truth. Once you see the problem as connection, the next purchase is judged on whether it joins your existing sources or adds an eighth island. Most add an island.

Second, you stop trusting any single screen as the whole truth. The RMS forecast is real but partial. The P&L is authoritative but late and disconnected from what caused it. The GSS score is honest but orphaned from the operational decision that moved it. An operator who understands hospitality data as a scattered, partial, system-by-system thing reads every screen as one witness, not the verdict.

Third, and most important, you start asking questions that cross systems, because those are the only questions that matter. Did the labor we deployed Saturday night actually serve the covers we booked? Is the catering pipeline pacing to the budget the owner is holding us to, or just to last year? Did RevPAR going up actually move GOP, or did it just move the top line while costs ate the gain? Not one of those questions can be answered inside a single system. Every one is a connection question, and every one is what the COO, the analyst, and the owner actually need answered. The hospitality data insights worth paying for almost always live in the seams between systems, not inside any one of them.

Where it fits in the Operator Intelligence model

So if hospitality data is the scattered raw material, what is the finished thing? This is where the definition has to point somewhere, because a definition that ends at “your data is a mess” is just a complaint.

We think about the finished state in three layers, and we call it the Operator Intelligence model.

The first layer is one connected source of truth. Not another dashboard on top of the chaos. The actual join: the PMS, the RMS, the sales-and-catering system, the POS, the labor system, the guest layer, and the P&L brought into one place where a number means one thing. This is the layer that turns hospitality data from eight arguments into one record. It is the unglamorous, expensive, load-bearing work, and it is the work almost everyone skips because connection does not demo as well as collection.

The second layer is an operator-intelligence layer that reads the way an operator already thinks. Connected data is necessary and not sufficient. A perfectly joined warehouse that still speaks in SQL and schema is useless to a GM on a hands-free in the car. The intelligence layer translates the connected data back into the operator’s own language: pace, mix, flow-through, productivity, the questions a COO asks at 8 a.m. without thinking about which system the answer lives in. This is what most hospitality data services never reach, because they hand you the warehouse and call it done.

The third layer is an operating cadence that makes it a daily habit. Data that is connected and readable still dies if nobody opens it. The cadence is the Monday ops call, the quarter-end review, the owner update, all reading from the same connected source, every week, owned by name. Without the cadence, even good work quietly dies inside ninety days.

Hospitality data, then, is the bottom of that model. It is the raw material, not the product. Defining it from the operator’s seat (scattered, partial, true-but-disconnected) is what makes the rest of the model obvious. You cannot build the intelligence layer or the cadence on top of eight systems that disagree. You have to connect the data first. That is what hospitality data is for, and that is the only reason the category exists.

The flag we are planting

So here is the definition we will stand behind. Hospitality data is the full operating reality of a hotel scattered across the PMS, RMS, sales-and-catering, POS, labor, guest and sentiment, and back-office P&L. It is being collected exhaustively and connected almost never. The value is not in gathering more of it. The value is in joining what is already there so the operator runs the building on one truth instead of eight.

We say this as operators, not as a platform looking for something to sell you more of. We are a hospitality data company built by people who sat in the Monday meeting and watched five systems disagree, then went and built the connection that ended the argument. The definition is the easy part. The connection is the work.

You can do this connection yourself, source by source, if you have the patience and a person who will not stop halfway. Many teams should try, because the discipline of writing down what each number means is worth the trip on its own. If you would rather the join just existed, stayed current, and spoke the operator’s language without anyone babysitting an export, that is the work we do. Either way, stop calling your data a collection problem. It was never that. It is, and always was, a connection problem, and it is the most valuable one in the building.