7 data implementation mistakes hotel groups make (and how to avoid them)

Picture the steering committee for a data project at a hotel group. There is a vendor on the screen, a signed statement of work, a project plan with a go-live date, and a room full of people who all want the same thing and cannot quite say it the same way. The COO wants one number she can trust. The VP of Ops wants something his GMs will actually open. The analyst wants clean inputs. The owner wants to know what it costs. Eight months later there is a platform, a login, a training deck, and a quiet sense that the property teams went back to their spreadsheets the week after launch.

We have sat on both sides of that table. The pattern almost never comes down to the tool. Hotel groups have the same warehouses, the same BI layers, and the same consultants as everyone else. What separates the implementations that stick from the ones that die is a short list of decisions made (or skipped) before anyone writes a query. Here are the seven mistakes we see most, why each happens to good operators, and the fix. Read it as a checklist.

1. Buying the tool before defining the decision

The most expensive mistake comes first, in the procurement meeting. A group decides it needs “better visibility,” runs a vendor bake-off, picks a platform, and only then starts asking what it should show. The tool arrives in search of a job.

Why it happens. A tool is concrete and a decision is not. You can demo a dashboard, sit through a sales call, and compare two quotes. It feels like progress. Naming the actual decision the data is supposed to improve (which rate to drop, which property is soft on group, which menu item to cut) is harder, more political, and easier to defer. So the org buys the thing it can buy and hopes the decisions show up later.

The fix. Start from the decision, not the data. For every workstream, write one sentence: “We are building this so that [role] can decide [thing] every [cadence].” If you cannot finish that sentence, you are not ready to buy anything. The decision tells you which numbers matter, which sources you need, and who has to be in the room. Best practice in data implementation is to let the decision pick the tool, never the other way around. A modest tool aimed at a real weekly decision beats a powerful one aimed at “visibility” every time.

2. No single owner of definitions

Six properties define “occupied room” five ways. The catering team counts contracted heads, the chef counts covers rung in the POS, and finance counts something else again. The dashboard averages all of it and calls the result a portfolio number. Nobody is wrong. The number is still useless.

Why it happens. Definitions live in people, not systems. Each property grew its own logic over years of turnover, and each version is locally correct. Nobody owns the cross-property meaning of a metric, because owning it means telling four GMs their number is going to change. That is an uncomfortable conversation, so it does not happen, and the ambiguity gets baked into the warehouse instead.

The fix. Name one human who owns each metric’s definition for the whole group. Not a committee. A person. Write the definition in plain English that a GM could read, version it, and make every dashboard cite the same one. We have written this case at length in the five systems that disagree, because definition ownership is the root cause under most reporting fights. The test is simple: two people in the same meeting should never read the same metric and get different numbers. If they can, you have a definitions problem wearing a dashboard costume.

3. Ripping and replacing instead of connecting

A group decides its data is a mess, so it sets out to replace the PMS, or consolidate every property onto one platform, or sunset the systems the property teams actually use. The project balloons. The timeline triples. Two years in, the operators are still waiting for the visibility they were promised, and the change-management bill has eaten the budget.

Why it happens. A clean slate is seductive. Operators look at five disconnected systems and conclude the systems are the problem, so the answer must be fewer systems. Vendors are happy to agree, because a platform migration is a much bigger contract than an integration. And “one system to rule them all” is an easy story to tell an owner.

The fix. The data is almost always already in the building. The PMS holds the rooms picture, the sales-and-catering system holds the pipeline, ProfitSage or the accounting export holds the actuals. The problem is rarely that you own the wrong systems. It is that they do not talk to each other. Connecting those sources into one trustworthy layer is faster, cheaper, and far less disruptive than replacing them, and it does not ask your property teams to relearn the tools they run the building on. Rip-and-replace when a system is genuinely dead. The rest of the time, connect first.

4. Ignoring source-data hygiene

The warehouse goes live, the dashboards look sharp, and then the F&B contribution number is off by eleven points from the board pack. The build was fine. The inputs were not. Garbage segment codes, a menu that was reorganized mid-quarter, a forecast that got retrained and never re-mapped, and the cleanest dashboard in the world is now confidently wrong.

Why it happens. Hygiene is invisible work that nobody scopes and nobody buys. A vendor quotes the build, not the cleanup, because cleanup is unbounded and hard to price. The property teams who create the source data have no time budgeted to maintain it. So the project assumes the inputs are clean, the inputs are not, and the gap surfaces at quarter-end when the CFO loses confidence.

The fix. Treat the source as part of the system, not an upstream someone else’s problem. Audit the inputs before you build on them, fix the worst offenders at the source (segment codes, menu mapping, market segments in the sales-and-catering system), and stand up a thin daily check that flags drift the morning it happens, not at quarter-end. This is unglamorous and it is the whole ballgame. A perfect model on dirty inputs is just a faster way to be wrong. Best practice is to budget for source hygiene as an ongoing line, not a one-time cleanup, because hotels recode their segments, reset their menus, and change their forecast cadence every single year.

5. Building for analysts, not operators

The finished product is gorgeous. Twenty drill-downs, a filter for every dimension, a query builder, a data dictionary. The analyst who helped spec it loves it. The GM opened it twice. The VP of Ops never logged in at all, because reading it would cost him fifteen minutes he does not have on a Monday.

Why it happens. Analysts are in the room and operators are not. The people who build and specify data tools are data people, and they build the tool they themselves would want: flexible, deep, capable. Operators want the opposite. Three numbers they already know how to read, in the same place, every week. The flexibility that delights an analyst is friction to someone running a property half-listening on a hands-free in the car.

The fix. Build for the person who is busiest, not the person who is most fluent. The default view should answer the operator’s standing question in one glance, with the depth one click away for the analyst who wants it. If the tool cannot survive being read out loud on a Monday ops call by someone who is half in the room, it will not survive the quarter. We have watched this kill more dashboards than any data error. The discipline is to design the operator’s view first and treat analyst depth as an additive layer, never the front door.

6. No adoption plan

The launch is the finish line in the project plan. There is a demo, a training session, a celebratory email, and then the team moves on to the next initiative. Ninety days later the tool is a bookmark nobody clicks, and the leadership group is quietly puzzled about why a six-figure investment is gathering dust.

Why it happens. Adoption is nobody’s deliverable. The vendor’s contract ends at go-live. The internal sponsor’s success metric is “shipped,” not “used.” Everyone assumes that because the tool is good and the training happened, the habit will form on its own. It does not. A new tool competes with a nine-year-old spreadsheet the DOSM trusts, and the spreadsheet wins by default every time, because it is the incumbent and the incumbent is free.

The fix. Plan the second ninety days harder than the first. Pick the one weekly meeting the tool will live inside, name the person who reads it there, and make it the only source for that conversation. Retire the spreadsheet it replaces, out loud, on purpose. Adoption is not a training problem, it is a habit problem, and we wrote the full version of this case in why dashboards die in 90 days. The honest rule: a data tool that nobody opens has failed, no matter how correct it is. Measure adoption, not delivery, and treat a number falling out of use as the same severity as a number being wrong.

7. No operating cadence

Even the good implementations drift without this last one. The tool is right, the operators use it for a while, and then a busy month hits, the weekly read slips, and within a quarter it is back to ad hoc. There was never a rhythm holding it in place.

Why it happens. Cadence feels like overhead until you have lost it. A standing weekly read looks like a meeting you could skip when things get busy, and things in hospitality are always busy. So the discipline that makes the data useful (looking at it on the same day, in the same room, with the same owner) is the first thing to go when the property is slammed, which is exactly when the data matters most.

The fix. Wire the data into a fixed operating rhythm and protect it like a financial close. One named meeting, one owner, one read, every week, non-negotiable. The cadence is what turns a tool into a habit and a habit into a system. It is also the cheapest of the seven fixes and the one most often skipped, because it requires discipline rather than budget. A number looked at once a quarter is a report. A number looked at every Monday by the person who owns it is an operating system. The difference is cadence, and cadence is a choice you make, not a feature you buy.

What good actually looks like

Read the seven back and a shape appears. The mistakes are not really seven separate failures. They are one failure showing up in seven places: a data project treated as a thing you buy and install, instead of a system you operate. The tool was never the hard part. The decision it serves, the definition behind it, the inputs feeding it, the operator reading it, and the cadence holding it in place are the hard parts, and none of them come in the box.

That is the whole of the Operator Intelligence model, and these seven are just the failure modes you hit when a piece of it is missing. One connected source of truth, so the systems stop disagreeing. An intelligence layer that reads the way an operator already thinks, so the busiest person in the building can use it. And an operating cadence that makes it a daily habit, so it survives past ninety days. Get those three right and most of this list never happens.

You can build this yourself from the seven fixes here, and plenty of capable groups should. If you would rather start from a model that already accounts for all seven, that is the kind of thing we build. Either way, the next time a vendor opens with the tool, stop them, and ask what decision it is supposed to improve. If nobody in the room can finish that sentence, you are not ready to buy. You are ready to think.

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