Why hotel operations starts every day in three different systems

The PMS has occupancy. The OTA dashboard has pickup. The F&B system has last night's covers. None of them talk to each other, so someone opens all three before the 9am briefing and reads the numbers out loud. This is the most common operations pattern we see in hospitality, not a technology problem, a data assembly problem. Here is what it costs, why it persists, and what a single morning board actually requires to build.

The operations manager at a 47-room boutique hotel in Amsterdam described her morning routine to us at the start of a discovery call. She arrives at 8:15. She opens the property management system and pulls the previous night’s occupancy, the ADR, and the RevPAR. She opens the OTA portal, two tabs, one for Booking.com and one for Expedia, and checks pickup for the next seven days. She opens the F&B system and reads out last night’s cover count and revenue. She writes the numbers into a shared Google Doc. At 9:00 she runs the morning briefing using that document.

The whole process takes thirty to forty minutes, depending on whether any of the systems are slow to load. She has done it every working day for four years.

When we asked her if she had ever tried to automate it, she said yes, twice. The first time, the PMS vendor quoted a custom integration at a cost that was not in the budget. The second time, a well-meaning IT contact set up a script that broke within three weeks when the OTA portal changed its layout. After that, she stopped trying.

Why this pattern is everywhere in hospitality

Every hotel we have spoken to has a version of this morning. The specific systems vary, some run Mews, some run Opera, some run Apaleo. Some have a channel manager in the stack, some manage OTA inventory directly from the PMS. The F&B tool might be a full EPOS, a light POS, or a spreadsheet someone maintains. But the pattern is constant: the data that matters for the morning briefing lives in two to four systems, none of them share it automatically, and someone assembles it by hand before the meeting.

This happened for a reasonable reason. Each system was purchased to do one thing well. The PMS is the source of truth for reservations and room revenue. The channel manager is the source of truth for OTA inventory and rate parity. The F&B system is the source of truth for food and beverage. Nobody bought them as a suite with a shared data layer, because that is not how hospitality software is sold. The integrations between them are limited, expensive, or both.

The result is that the assembly job, pulling the numbers together into one view, falls to a person. It always falls to the same person. And it happens every morning, before the working day has properly started, consuming the clearest thirty minutes of the day on a task that a computer should do.

What the assembly actually costs

Thirty minutes a day is one hundred and thirty hours a year. At a senior operations level, that is a meaningful slice of capacity spent on data retrieval rather than the analysis and decisions that require a human. But the time cost is only part of it.

The more expensive problem is the lag. By the time the morning briefing runs, the numbers in the document are between eight and twelve hours old. The PMS export was run at 8:20, capturing whatever state the system was in then. If a group booking came in at 7:00, the briefing knows about it. If a cancellation came in at 8:30, the briefing does not, it happened after the export.

For forward-looking decisions, yield adjustments, staffing calls, F&B prep, a twelve-hour-old number is often good enough. For reactive decisions, it is not. The channel manager might be showing parity issues that opened up overnight. The OTA pickup for a weekend that was looking weak three days ago might have recovered. The briefing document cannot show any of this, because it was assembled before any of it happened.

The operations manager who has done this for four years knows this. She compensates by checking the PMS again during the briefing, live, on her laptop. She checks the OTA portal if a question comes up. The briefing document exists, but the real data is still in the three tabs she opened at 8:15. The assembly was for nothing.

What the board we built actually looks like

We built an operations board for a 120-room independent hotel group with three properties. The brief was simple: the general manager should be able to open one screen at 8:55 and run a ten-minute briefing from it without any preparation.

The data sources were the PMS (Mews, connected via API), the channel manager (SiteMinder, also API), and the F&B system (a Square POS, with a nightly export into a Google Sheet as an intermediate step, because the Square API did not offer the granularity they needed). Three sources, not two and not four.

The board has seven tiles. Occupancy last night and occupancy same time last week. ADR last night and ADR same period last year. OTA pickup for the next seven days, with a colour flag if any day is tracking more than fifteen percent below the same point last year. Channel parity status, a single green or red indicator showing whether any rate parity issues are currently open on any OTA. F&B covers last night and revenue last night, both with a same-day-last-week comparison. And one free-text tile that the duty manager updates each morning with anything the board cannot show: a large group arriving, a maintenance issue affecting a floor, an event in the area that might drive late walk-ins.

The board refreshes every two hours overnight and every thirty minutes during the day. By 8:55 it is showing data that is at most thirty minutes old. The channel parity flag catches issues that would previously have been discovered mid-briefing when someone opened the channel manager to check.

What changed

The general manager told us, at the six-week review, that the briefing had gone from twenty-five minutes to twelve. Not because people were talking less, but because the first five minutes of every previous briefing had been spent reading numbers out loud while everyone else wrote them down. That time is gone. The board is on the screen, everyone can see the numbers, and the first question in the room is now “why is Tuesday pickup so low” rather than “what was Tuesday pickup again.”

The operations manager who had been running the thirty-minute morning prep stopped doing it in the first week. She said she felt slightly guilty about it for a few days, as if she was skipping something important. By the second week she was using the time to walk the property before the briefing instead, something she had not done regularly since the first year in the role.

The parity flag caught three open parity issues in the first six weeks that would previously have been found during a manual channel manager audit, or not found at all. Two were minor, one was a rate that had drifted fifteen euros below their floor on a high-demand weekend. The revenue recovered from correcting it was small but real, and it happened on a Tuesday at 9:05 instead of a Friday when someone finally ran the audit.

If your morning briefing starts with someone reading numbers out of three different systems, book a call. Bring the names of the systems your morning numbers come from. That is usually enough to scope whether a board is buildable and what it would take.