How a hotel group cut its morning ops check from 40 minutes to 7

A four-property urban hotel group. PMS across four sites, a channel manager, and an F&B POS, Katrin spent 40 minutes every morning before the 7:15 briefing pulling numbers from three systems. Here is what we connected, the six tiles we built, and the three outcomes, including a rate parity gap caught on a Thursday morning before it cost a peak weekend.

This is a case study from a build we completed in early 2026. The client is a four-property urban hotel group, mid-scale, city-centre locations, total of 310 rooms. We have anonymised the company name. The numbers are as close to real as we are able to share.

Before: 40 minutes before the 7:15 briefing

The revenue manager, we will call her Katrin, started every working day at 6:30am. Not because she needed to arrive that early, but because the data she needed for the 7:15am ops briefing took that long to pull together.

The group ran Protel Air as its property management system across all four hotels. Reservations, room status, check-in and check-out volumes, and occupancy were all in Protel, but split by property, requiring four separate logins to get a group view. The channel manager (SiteMinder) held the live rate inventory and OTA connectivity data: what rates were published on Booking.com, Expedia, and the direct booking engine, and whether parity was maintained across them. The F&B point-of-sale system (Simphony) tracked covers, revenue, and average spend per cover, but exported to a summary report only at end of day, the live figure required logging into the back office terminal on-site.

Katrin's routine was: log into each Protel instance for occupancy and ADR by property, check SiteMinder for rate parity across the four hotels and their OTA connections, call the F&B manager at one property for a verbal update on the previous evening's service, and then compile a summary in a shared Google Doc before the briefing. The Google Doc was reformatted manually for each meeting. On good days this took 35 minutes. On days when a property had a technical issue or SiteMinder had not refreshed correctly, it took longer.

What the process missed regularly: rate parity gaps that appeared between Katrin's morning check and the time a guest searched on a peak booking day, occupancy imbalances across properties that only became apparent when she compared all four Protel exports side by side (which she did not always have time to do), and F&B performance for any property she had not called. The group had four F&B outlets. She called one per morning, rotating.

What we built

The brief from the discovery call was clear: one screen, four properties, ready before 7:15. Katrin wanted to stop logging into systems and start reading the day.

We connected three sources: Protel Air (via the REST API, pulling occupancy, ADR, arrivals, and departures across all four properties in a single authenticated session), SiteMinder (via the Channel Manager API, pulling current rate inventory and parity status per property and OTA), and Simphony (via the reporting API, pulling covers and revenue from the previous service period, dinner from the night before, breakfast from that morning if the service had closed). The board has six tiles:

Group occupancy. Tonight's occupancy across all four properties, with a comparison to the same night last week and the same date last year. One number for the group, four numbers underneath. Katrin described this as the tile she had been manually assembling from four Protel exports every morning for three years.

ADR and RevPAR by property. Average daily rate and revenue per available room for the current day, each property side by side. Flags properties running more than 8% below their rolling 30-day average, the threshold the group uses as a prompt to review yield settings.

Arrivals and departures today. Check-in and check-out volumes by property, useful for staffing and housekeeping handoffs at the briefing. Pulled from Protel in real time.

Rate parity status. For each property and each connected OTA, whether the published rate matches the direct rate within the acceptable tolerance. Parity gaps flagged in red with the specific channel and property. Updates hourly from SiteMinder. The tile Katrin was checking manually every morning, now the only time she needs to look is when it shows red.

F&B last service. Covers, revenue, and average spend per cover from the most recently closed service period across all four outlets. The Simphony data Katrin had previously covered through a daily rotation of calls now appears for all four outlets simultaneously.

Maintenance open items. Count of open maintenance tickets by property and priority, pulled from the group's helpdesk. Not a replacement for the maintenance log, a conversation starter for the briefing when a critical item has been open for more than 24 hours.

Build time was seven days. Day one: discovery and source mapping, the Protel multi-property API required a different authentication pattern than the single-property setup, which took half of day one to resolve correctly. Days two and three: Protel and SiteMinder connections with validation against Katrin's manual exports for a ten-day back-period. Days four and five: Simphony integration and the maintenance helpdesk connection. Day six: Katrin reviewed the board with the general managers of two properties, the GMs requested the maintenance tile, which we had proposed in discovery but they had asked us to deprioritise; after seeing the rest of the board they asked us to add it. Day seven: live.

After: seven minutes, and a rate parity catch worth two weekends

The first morning after go-live, Katrin opened the board at 6:48am and was ready for the 7:15 briefing with time to spare. The briefing itself ran shorter, seven minutes of prep, a tighter meeting, property managers with the same data in front of them rather than waiting for Katrin to read out the numbers.

Three outcomes that were measurable within the first quarter:

Morning ops check: 40 minutes to 7. The daily ritual that had required Katrin to arrive 45 minutes before the briefing was replaced by a seven-minute board review. She now arrives at 7:00. The general managers described the briefing itself as qualitatively different: less time spent reporting the situation, more time spent making decisions about it.

A rate parity gap caught before a peak weekend, not after.In the third week after go-live, the parity tile flagged a rate gap at one property on a Thursday morning: Booking.com was showing a Friday and Saturday rate that was €28 lower than the direct booking engine, the result of a channel configuration error when the property updated its weekend packages. Under the previous process, Katrin's morning check covered parity once per day, if the gap appeared after she had checked and before she checked again the next morning, it ran for up to 24 hours. The parity tile updates hourly. The gap was corrected by 9:30 Thursday. The property's direct booking share for that weekend was the highest it had recorded in four months. Katrin said the correlation is not certain but the timing is notable.

F&B performance visible across all four outlets for the first time.The group had four F&B outlets. Before go-live, Katrin had a real-time picture of one per day on a rotating basis. After go-live, the previous evening's covers and revenue were visible for all four at the morning briefing. In the sixth week, the data showed that one outlet was running 30% fewer covers on Sunday evenings than the other three for the same number of available seats. The general manager had not flagged it, the pattern had been in the data for months, invisible because no-one had been looking at all four outlets on the same morning.

What made it work

The multi-property Protel authentication was the unexpected problem. Most Protel installations we connect are single-property; the multi-property API uses a different session model that required documentation we had to request from the vendor. This added half a day on day one. We now have that documentation for future builds.

The maintenance tile was the one we had proposed and the client had deprioritised, then added on day six after seeing the rest of the board. This happens often enough that we now mention it explicitly in discovery: certain tiles are easier to want after you have seen what the board looks like without them. The maintenance tile changes the briefing from a purely revenue conversation to an operational one. For a four-property group where a broken lift or a heating fault affects the day's reviews, that is relevant.