Why your hospitality dashboards die in 90 days

The dashboard sits on the GM’s second monitor for three weeks. Then a STR report comes in wrong, the DOSM stops opening the tab, and by quarter-end it is a bookmark no one clicks. We have watched this happen at properties of every size, with consulting decks of every price.

The story is almost always the same. A vendor or an internal team builds something handsome, demos it to a leadership group that nods, and walks away. Ninety days later the data has drifted, the definitions have drifted, and the people who needed it have drifted back to spreadsheets. We think the problem is not the tool. The problem is that hospitality dashboards are designed as artifacts when they need to be designed as habits, and habits have completely different requirements than artifacts do.

The Monday morning ops call problem

Picture the Monday morning ops call. The GM is on a hands-free in the car, the DOSM is half in the room and half in an email, the F&B director is running on four hours of sleep after a Saturday wedding, and the revenue manager is opening tabs as fast as she can talk. Someone shares a dashboard. There are fourteen tiles. Three of them are KPIs nobody at the property actually owns. Two are pulling from Opera but were defined off a Lighthouse extract from last quarter. The DOSM looks at group pace and sees a number she does not recognize. She asks where it came from. Nobody on the call can answer.

That is the moment the dashboard dies. Not when it breaks. When someone in the meeting stops trusting it.

We have seen properties spend six figures on subscription BI tools and watch them get abandoned for exactly that reason. The tool was not wrong. It was just not built for the rhythm of an ops call. An ops call needs three numbers, in the same place, that everyone on the line already knows how to read. It needs a definition of “on the books” that matches what Tripleseat shows the catering managers and what ProfitSage reconciles for the controller. If the dashboard cannot survive being read out loud at 8:32 a.m. on a Monday, it will not survive the quarter.

The fix is not more dashboards. The fix is fewer, defined harder, owned by name, and built to be read by someone who is half-listening.

The definition drift problem

The second killer is quieter and meaner. It happens after launch, in the boring places where nobody is looking.

A revenue manager retrains the IDeaS forecast in March. The catering team starts coding a new “social” market segment in Tripleseat in April. The new VP F&B asks for banquet covers to exclude breakfast, just for his deck. The Toast menu gets reorganized in May when the chef rebuilds the bar program. None of these are bad decisions. Each one, on its own, is correct. But every one of them invalidates a number on a dashboard that nobody has touched since launch, and nobody tells the dashboard.

By July the asset manager pulls up the same dashboard he loved in February and the F&B contribution number is off by eleven points from what the CFO has in her board pack. He does not file a ticket. He just stops opening it.

This is the work nobody quotes for and nobody buys. Definitions are not a deliverable, they are a maintenance contract. A real one. A hotel changes its segment codes, its menu mix, its outlets, its forecast cadence, its comp set, sometimes its PMS, every single year. If the dashboard is not maintained against those changes the same way a P&L is reconciled every month, it will rot. We treat definition drift as a first-class operational risk, not a footnote.

The tell is always the same. Two people in the same meeting cite the same metric and read different numbers. The catering manager has “definite” group rooms at one figure, the revenue manager has it at another, and both of them are correct under their own definition. Nobody is wrong, the dashboard is just answering a question that was retired in March. Off-the-shelf forecasting platforms make this worse, not better, because they import yesterday’s segment logic and then never look back.

The “who actually owns this” problem

The third killer is the org chart. Dashboards die when nobody at the property feels personally responsible for them being right.

Most hospitality BI projects are sponsored by a corporate office and consumed by a property. That gap is fatal if you do not close it on purpose. The corporate team pays for the build, owns the data warehouse (whether it is Snowflake or something stitched together out of exports), and writes the requirements. The property is supposed to use it. Nobody at the property has time budgeted to maintain it, validate it, or push back when a number looks wrong. So when a number does look wrong, the property silently routes around it. They go back to the same Excel file the DOSM has been running for nine years, and they cite it on the ops call instead.

We see this most clearly at quarter-end and board review. The numbers on the dashboard and the numbers in the board deck are close but not identical, and nobody can fully reconcile them in under an hour. The CFO loses confidence. The asset manager loses confidence. Suddenly the dashboard is a “nice to have” instead of the source of truth, and a year of work gets quietly downgraded.

The fix is ownership written into the project itself. Every metric needs a named human at the property who agrees to validate it monthly, and a named human at corporate who agrees to fix it when validation fails. If you cannot name those two people for every number on the screen, you are building a museum piece.

We also notice the same gap on the F&B side. A VP F&B inherits a portfolio dashboard from a predecessor and finds three different definitions of cover count across four properties. The chef counts seats, the F&B director counts entrees rung in Toast, the catering office counts contracted heads in Tripleseat. The dashboard averages them and calls it a portfolio number. By the time the new VP figures out which one to trust, he has stopped trusting any of them and started rebuilding his own pull in a spreadsheet on Sunday nights. That is not a dashboard failure, that is an ownership failure dressed up as a dashboard failure.

What we would actually do

We would build fewer dashboards, with harder definitions, against a smaller surface area. We would start by sitting in two Monday ops calls and one quarter-end review before writing a single SQL query, so we know what numbers actually get used and which ones are theater. We would write a data contract for every metric in plain English (the kind a DOSM or VP F&B could read), commit it to version control, and refuse to add a tile that does not have one.

Then we would build a thin validation harness that runs every morning and flags drift the moment it happens, not at quarter-end when the board deck disagrees with reality. We would name an owner at the property and an owner at corporate for every metric. And we would charge for the second ninety days, not the first, because that is when the work actually starts. The first ninety days is the easy part. Keeping a dashboard alive in year two, through a PMS change, a menu reset, a segment recode, and three turnover events on the property leadership team, is the entire job.

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