Hospitality data strategy: a one-page framework for operators

Picture the offsite. A consulting firm or an internal team has spent three months on a data strategy, and the readout is a forty-page deck. There is a maturity curve with five stages and a dot showing where you are. There is a future-state architecture diagram with twenty boxes and arrows nobody can trace. There is a roadmap with three horizons and a slide titled “data as a strategic asset.” The room nods. Someone says this is great work. The deck gets a SharePoint folder. And then the building goes back to running on the same five spreadsheets it ran on that morning.

We have read a lot of those decks. We have watched them die in the drawer. The problem is not that the thinking is wrong. It is that a forty-page strategy is built to be admired in a meeting, not used on a Tuesday. An operator does not need a maturity curve. An operator needs to know what number to trust before the owner call. A data strategy that does not change what happens on Monday morning is not a strategy. It is an artifact, and artifacts die.

So here is the version we actually use. An operator’s data strategy fits on one page and answers four questions. That is the whole document. If you cannot answer them in writing, no architecture diagram will save you.

What a data strategy actually is

Strip away the consulting language and a data strategy is a set of decisions about how the operation will know things. Not how it will store things, or process things, or visualize things. How it will know things, reliably, fast enough to act. The architecture is downstream of that. The dashboards are downstream of that. The AI use cases everyone wants to talk about are way downstream of that.

Most decks invert this. They lead with the technology (a warehouse, a BI tool, an AI layer) and treat the decisions as implementation detail. That is backwards, and it is why the deck dies. The technology choices change every eighteen months. The decisions about what the operation needs to know do not. Anchor the strategy in the technology and you have bought a platform before you know what it is for.

A real hospitality data strategy answers four questions. We will walk each one.

Question 1: What decisions are we trying to make?

Start here, always. Not with data. With decisions. What are the handful of recurring calls this operation makes where being right matters and being slow costs money?

For most hotels and restaurant groups the list is short and boring. Do we drop the shoulder rate this week. Is catering pacing to budget or is the soft quarter real. Is the labor model holding as covers move. Which menu items are carrying the margin and which are quietly bleeding it. Did F&B actually do what the flash report says it did. What goes in front of the owner on Thursday, and can we defend it. Six or eight decisions, made over and over, by the same handful of people.

Write them down. That list is the spine of the entire strategy, because every other choice flows from it. A number that does not feed one of those decisions does not belong on a dashboard. A data source nobody needs for one of those decisions does not need to be in the warehouse on day one. A strategy that starts with decisions stays small on purpose. A strategy that starts with data tries to boil the ocean, because every system has a thousand fields and none of them tell you which matter. The decisions tell you.

Question 2: What is the one source of truth?

For each decision, there has to be one number, and one place that number comes from. Not a preferred number. Not a usually-right number. The number, the one you are allowed to put in front of an owner, and the single source it is computed from.

This is the question that exposes the real problem, because most operators cannot answer it. Ask what F&B did last month and the PMS says one thing, the catering system says another, the POS says a third, and finance says a fourth off the accounting export. Each is correct under its own definition. None is the source of truth, because nobody declared one. We have written a whole piece on what that costs and how to fix it without ripping anything out: five systems that disagree.

Naming the source of truth is not a technical act. It is a decision. It says: when these numbers conflict, this one wins, and here is why. Sometimes the answer is the accounting export, because that is what reconciles to the P&L. Sometimes it is the PMS, because that is what the block is sold against. The point is that somebody decides, in writing, per decision, before the conflict happens in a meeting. A data strategy without a declared source of truth for each decision is just a list of systems that will keep disagreeing forever.

Question 3: Who owns each definition?

A number is only as trustworthy as its definition, and a definition is only as durable as the person who owns it. So for every number on the page, name two humans: the person who validates that it is right, and the person who fixes it when validation fails.

This is the question decks skip entirely, and it is the one that kills more strategies than any architecture flaw. A hotel changes its segment codes, its menu mix, its outlets, its forecast cadence, sometimes its whole PMS, every single year. Every one of those changes silently breaks a definition somewhere. If no human owns “cover count” or “definite group revenue” or “F&B contribution,” the definition drifts, the number rots, and three months later two people in the same meeting read different figures off the same metric and both are correct. That is not a tooling failure. It is an ownership failure wearing a tooling costume.

Ownership has to be written into the strategy itself, not assumed. Every definition gets a name next to it. Not a department. A person. If you cannot name the human who owns “RevPAR to budget” or “labor as a percent of covers,” that number is unowned, unmaintained, and already drifting. The org chart is part of the data strategy. Most decks pretend it is not.

Question 4: What cadence makes it a habit?

The last question turns a strategy into behavior. When does each decision get made, in what meeting, off which screen, read by whom? If you cannot answer that, you have a reference document, not a strategy. A number that is correct and never looked at is worth exactly as much as a number that is wrong.

Cadence is where strategies go to live or die. The catering pace curve only matters if it is on the screen in the Monday revenue meeting, next to rooms pace, owned by a named person, read every week. The flash report only matters if it lands before the decision it informs, not after the month already closed. We have argued before that the whole game is cadence, because most hospitality dashboards die inside ninety days for exactly this reason: they were built as artifacts when they needed to be built as habits.

So the fourth line of the strategy, per decision, is the cadence. Daily, weekly, monthly. Which meeting. Which screen. Who reads it out loud. That is what makes the other three questions matter. Without it you have a correct, well-owned set of numbers that nobody opens.

How the four questions map to the operating model

Those four questions are not arbitrary. They are the operator-facing view of the same model we build everything on, the Operator Intelligence model: one connected source of truth, an intelligence layer that reads the way an operator already thinks, and an operating cadence that makes it a daily habit.

Question 2 is the source of truth. It says the five systems have to join in one place so that “what did F&B do” has one answer, not four. Questions 1 and 3 are the intelligence layer. The decisions define what the layer surfaces, the ownership keeps it honest as the operation changes underneath it. Question 4 is the cadence, the part that turns all of it from a platform into a habit. The one-page strategy is just the Operator Intelligence model written in the language an operator uses on a Tuesday: decisions, numbers, names, and meetings, not warehouses, pipelines, and maturity curves.

This is also why the technology decisions can wait. Once the four questions are answered, build versus buy gets easy, because you know exactly what the operation needs to know and how often. You can hold a SaaS contract or a custom build up against a concrete list of decisions and definitions and ask whether it serves them. That is a real test, and most operators are surprised which way it points: build vs. buy for hospitality data. You cannot run that test against a forty-page deck. You can run it against one page.

What good looks like

A finished operator data strategy is one page. Down the left, six or eight decisions. For each one, four columns: the source of truth, the definition, the owner, the cadence. That is the document. A GM or an asset manager can read it and know, in two minutes, what the building trusts and who is accountable for it staying true.

It is unglamorous on purpose. No maturity curve, because maturity is not a decision. No three-horizon roadmap, because the roadmap falls out of the four columns the moment you see which decisions have no source of truth and which definitions have no owner.

You can build this yourself, and you should at least try, because filling in the four columns is where most of the value is. The exercise forces the arguments a forty-page deck lets you avoid. If you fill in the page and find half the cells empty, that is not a failure. That is the strategy doing its job, showing you exactly where the building is flying blind. If you would rather have it built, the sources joined, the definitions held, and the cadence running without a person babysitting a spreadsheet, that is the work we do. Either way, the test is the same. If your data strategy does not fit on one page and change what happens Monday morning, it is not a strategy yet. It is a deck waiting for a drawer.

Peter Hough is co-founder of Hospitality Data Solutions. Twenty years in hotel and restaurant operations, now building the systems we wished we had.