Insights · Operations

The report that comes to you beats the dashboard that waits

By the YMME team·7 min read·September 2026

The dashboard was launched with a training session and a login for every manager. Three months later the usage log shows two people: the analyst who built it and the owner, once, before a board meeting. The problem is not the dashboard. It sits in a place nobody goes.

Quick answer. Reporting gets read when it arrives where the reader already is, on the phone or in the inbox, on a schedule that matches the reader’s day, with one message per decision rather than one per hour. That takes a delivery layer with rules of its own: the first run of the day always sends, later runs only when something changed, every send is recorded, and each stream is independent so that one failure does not silence the rest.

Where the reader already is

More than 80% of hotel commercial teams still spend one to two days a week assembling reports by hand, according to the 2026 State of Distribution study by RateGain, NYU Tisch and HEDNA. Most of that time is not analysis. It is collecting figures from systems and pasting them somewhere the reader will look: a message, an email, a slide.

That last step is the one dashboards forget. In the groups we work with, a general manager looks at their phone all day and at a reporting portal about once a week. A purchasing manager does not open the accounting system to browse. So the daily summary goes to the phone, the supplier payment list goes to the inbox, and the portal is there for the day somebody wants to go deeper. Delivery is the product. The screen is where you go when the message raises a question.

A schedule that matches the day, not the server

The daily revenue summary goes out three times: before the morning meeting, around midday, and after the day is closed. The times follow the group’s own rhythm, when the night audits finish and when the tills export, rather than a round hour that suits the server.

Two rules govern what goes out. The first run of the day always sends, even when the data is incomplete, with the status of each source attached, because the morning meeting needs a signal. The second rule is duller and matters more: later runs send again only if something changed. A source that arrived late moves the figure, so a second message goes out. A run that found nothing new sends nothing. The manager gets one figure for the day, refreshed when there is a reason, rather than three identical messages that train them to stop reading.

What belongs in the morning message

The temptation is to send the dashboard. The right answer is to send the decision. A morning message that runs to two screens on a phone is a dashboard in disguise, and it will be skimmed the way the dashboard was ignored. Four things belong in it, and not much else.

Yesterday against plan and against last year: occupancy, rate, revenue by department, one line each, rounded the same way as on the screen.
The pace ahead: what is on the books for tonight and the next few days, so the message is about decisions still open rather than only about a day that is over.
The status of the sources: which property is complete, which is partial and why. Without that line the reader cannot tell whether to trust the rest.
One link deeper, to the screen that explains the movement, for the reader who wants it.

The send journal

Every message that goes out is recorded: which distribution, which run, which recipients, what was sent, whether it succeeded. This sounds like bookkeeping until the day a manager says the summary never arrived. Without the journal the conversation is about whether the system is reliable. With it, the conversation is about a phone that was off or an address that changed, and it takes two minutes.

The journal is also the only honest measure of whether reporting is used. A dashboard’s usage log tells you who opened it. A send journal tells you what every manager in the group had in their hand at eight this morning.

Independent streams

The revenue summary, the supplier payment list and the source monitor are separate distributions. Each runs on its own timetable, to its own list, over its own channel. They do not share a queue and they do not share a failure. If a property’s night audit runs late, the payables list does not care. If a messaging channel is down, the email streams are unaffected.

This is the difference between a reporting product and a report. A report is a thing you make. A reporting product is a set of promises about when things arrive, kept independently, with a record of each one.

A dashboard measures who came to look. A send journal measures what everyone had in their hand at eight in the morning.

Where YMME fits. The delivery half of YMME Score runs in production today: the daily summary to phone three times a day under the two rules above, the supplier payment list by email, a monitor on every source, every send recorded, each stream independent of the others. The screens are there for the day somebody wants to go deeper.