I've been in a lot of rooms where someone presents a new BI tool or a rebuilt ProfitSword dashboard and the energy in the room is good. The numbers are clean. The design is clean. Someone from the tech team or the corporate office explains what each panel means and how to drill down into the detail.
And then, three months later, nobody is looking at it.
The dashboard is still there. It's still pulling data. The numbers are probably still accurate. But the GMs are checking their own spreadsheets. The DOOs are asking the finance team to email them a summary. The ownership group is still getting a PDF that somebody built by hand.
This is not a technology problem. It's a trust problem. And a new dashboard doesn't fix it.
The thing the dashboard can't do
A dashboard shows you what the system thinks happened. That's all it does.
If the system is right — if the PMS mapped correctly to the GL, if the labor system is pulling from the right cost centers, if the revenue is landing in the right buckets — then the dashboard shows you an accurate picture of reality. That's genuinely useful.
But if any of those things are wrong, the dashboard shows you a clean, well-designed, beautifully formatted picture of wrong. And here's the problem: it's very hard to tell the difference by looking at the screen.
The people who know the operation best — the GMs, the F&B directors, the front office managers — they know when something looks off. They just can't always explain why. So they stop trusting the screen and go back to the system they built themselves, the one where they understand every number because they entered it.
That's not a failure of the operators. That's a rational response to a system that has been wrong before.
Where the trust breaks down
In most hotel portfolios I've worked in, the trust problem originates in one of three places:
1. The PMS-to-GL mapping was never validated after go-live
The implementation team maps the revenue categories during the system setup. Room revenue goes here. F&B goes there. Miscellaneous income goes somewhere. It looks right on the configuration document.
Then six months into live operation, someone notices that resort fees are hitting the rooms revenue line but the property is supposed to report them separately for USALI compliance. Or the pool bar revenue is going to "other operated departments" instead of F&B because of how the POS was mapped. Or the OTA commissions are netting against revenue in one property and showing as an expense in another.
By the time someone catches it, there are six months of data in the system that is structured wrong. The dashboard was showing it accurately — accurately wrong — the whole time.
2. The labor data and the P&L data don't agree
This is the one that breaks operations teams faster than anything else. The labor system says housekeeping ran 14.2 MPOR. The P&L shows rooms expense over budget by $45,000. When you try to reconcile the two, the numbers don't connect cleanly because the labor system and the accounting system are pulling from different sources with different cutoffs and different department code structures.
The GM looks at the dashboard. She sees both numbers. She can't reconcile them herself. She stops trusting both.
3. The dashboard was built for finance, not for operations
Most hotel BI dashboards are built by people who understand data. They are not always built by people who understand what a GM needs to know at 8am on a Tuesday before the morning meeting.
The result is a dashboard with 14 panels, six of which require a finance background to interpret, three of which are duplicative, and one of which has a label that means something slightly different than what the operations team thinks it means. Nobody tells them this. They use it wrong for a while, get a bad answer, and stop using it.
What actually creates trust
The technology people will tell you that trust comes from accuracy. Get the data right and people will trust it. That's partially true — accuracy is necessary. But it's not sufficient.
Trust in hotel reporting comes from two things that have nothing to do with the software:
The team has to understand where the number comes from. Not at a systems level — they don't need to know which API call pulls which data point. But they need to understand the logic. If rooms expense is over budget, they need to be able to trace it to something they can recognize: contract labor, a specific week, a rate variance, an overtime spike. If they can't do that trace, they don't trust the number even if it's correct.
Someone they trust has to vouch for it. This sounds soft but it's real. When a finance team member sits with a GM and walks through the labor report line by line — not presenting it, actually working through it together — and the GM sees that the numbers match what she experienced that week, something shifts. She starts to trust the report. Then she starts to check it on her own. Then she starts to use it to make decisions before month-end.
That process doesn't happen on the dashboard. It happens in a conference room or on a phone call, with someone who knows both the numbers and the operation well enough to translate between them.
The dashboard is not the destination
The best version of any hotel reporting system is one where the team would notice if the dashboard went down — not because they depend on it for information, but because they've already internalized the numbers and they use the dashboard to confirm what they already suspect.
That's what trust looks like at the end of the process. The screen is just the last step.
Getting there requires doing the work that doesn't show up in any implementation plan: validating the mapping, reconciling the systems, and sitting in enough rooms with enough operators that the numbers start to mean something to the people who are supposed to use them.
A new system does not fix bad data. It gives it a new place to live.
But a new system, implemented well, with the right people doing the translation work between finance and operations — that can build something that actually sticks.
That's the goal. The dashboard is just the screen you look at when it's working.
If you're in the middle of a systems implementation or a reporting rebuild and the trust problem sounds familiar, the consulting page describes how I work. The labor reporting post covers a related problem — what a useful labor report actually contains versus what most teams are looking at.