Multi-Property Hotel Reporting: How Management Companies Build a Single Morning View

Running morning reports across 8, 15, or 30 properties is a fundamentally different problem than running them for one. The data is more dispersed. The timing windows are tighter. The people who need the output are further from the properties. And the cost of getting it wrong — or late — compounds with every property you add. Here's how it actually works, and where the process breaks down.

How the scale problem changes the reporting problem

At a single property, a revenue manager can log into the PMS, pull the relevant views, and build the morning brief with a reasonable amount of effort. It takes time, but the scope is contained. One system, one property, one destination.

At a hotel management company running 10 properties, the math changes fast. If each property takes 30 minutes to report on, that's 5 hours of reporting work happening somewhere every single morning. Usually, it's distributed — a property-level manager pulls local data while someone at the portfolio level tries to build a consolidated view on top of it. The portfolio-level work can't start until the property-level work is done, and it requires its own assembly step on top of that.

The result at most mid-market operators isn't a clean pipeline. It's a series of dependencies — one person waiting on another's export, a portfolio spreadsheet that gets updated in pieces rather than all at once, and a final view that exists somewhere between version 3 and version 4 of a shared Google Sheet.

The three scale stages — and what changes at each one

What a multi-property morning reporting process actually looks like

Let me walk through how this typically runs at a management company with 12–15 properties, because it's representative of the 8–20 range where I see this problem most often.

The property-level layer

Each property runs its own reporting process. A property-level revenue manager or front desk manager exports a daily close from the PMS every morning. In most cases, this is a scheduled export — the system generates it automatically, and the file lands in an inbox or shared folder. Sometimes it's manual: someone logs in and pulls it themselves.

The file format varies. OPERA Cloud exports look different from Mews exports. If you're running a mix of platforms — which is common in any company that's grown through acquisition — normalizing those formats into something comparable is its own problem.

The portfolio-level layer

Someone at the corporate or regional level collects the property-level outputs and assembles them into a single portfolio view. This step typically happens in Google Sheets or Excel. Each property gets a row. Key metrics — occupancy, ADR, RevPAR, pickup vs. prior day — are compiled. Exceptions are flagged. Budget and prior year comparisons are added.

This assembly step is almost always manual. It requires someone to open each property file, copy the relevant figures, paste them into the consolidated sheet, check the formulas, and distribute the result. If one property is late, the whole portfolio view waits. If someone is on vacation, the process becomes ad hoc.

The distribution step

Once assembled, the portfolio brief goes out — usually by email, sometimes via a shared link, occasionally through a morning standup or Slack message. Leadership at the management company level sees the consolidated view. Regional managers see the properties in their cluster. Property-level managers receive their own portion back as confirmation.

The whole process is supposed to be done by 8am. In practice, it's usually done by 8:30am on good days, later when anything goes wrong.

A sample portfolio morning brief

This is roughly what the output looks like when the assembly process works well. When it's built by hand, getting to this view takes 45 minutes to an hour every morning. When it's automated, the same view exists in the inbox before anyone sits down.

Where the manual process breaks down

The friction points are predictable once you've seen enough of these processes. Late or missing property exports cause cascading delays. Format inconsistencies between PMS platforms require manual cleanup before the numbers can be compared. Version control becomes a problem when multiple people are working in the same spreadsheet at once. And there's always the question of whether the figures in the portfolio view match the figures in the source system — a question that's hard to answer with confidence when assembly is manual.

The deeper issue is that the manual process can't really scale. It's held together by individual effort, tribal knowledge, and the assumption that the person doing it will be available every morning. When that breaks — vacation, turnover, sick day — the whole process breaks with it.

How automation changes the architecture

The automation approach for multi-property reporting works from the same scheduled exports that the team is already pulling. The difference is that an automation layer handles the collection, normalization, and assembly — not a person.

The source systems don't change. The format of the brief doesn't change. The distribution doesn't change. What changes is that the assembly step — the one that required human effort every morning — no longer requires it.

The ROI math for a management company

The numbers are straightforward. If 10 properties each require 30 minutes of property-level reporting every morning, that's 5 hours of daily assembly work. At a fully-loaded $35–50 per hour for the staff involved, that's $175–250 per day, or $45,000–$65,000 per year, allocated entirely to report assembly.

That figure doesn't include the portfolio-level assembly that happens on top of the property-level work, or the time spent on rework when figures need to be corrected. In most management companies, the true reporting cost is closer to one full-time role spread across two or three people who each think it's just part of their job.