Multi-property: one dashboard for several hotels, without mixing their cash drawers or folios

The owner of two or three hotels lives a daily contradiction: they want to see the whole group on one screen, while each hotel still needs to run as if it were the only one that existed. A poorly designed dashboard solves one side of the problem and breaks the other, and the controller usually pays that bill at month end.

Why mixing properties is easier than it looks

When a hotel group grows, it almost always starts by copying whatever worked at the first property: the same system, the same account, sometimes even the same username and password to “keep things simple”. It works fine with one property. As soon as there are two, any configuration shortcut becomes a risk: a discount applied at the wrong hotel, a shift close that adds up sales from two restaurants, a guest folio that shows up at the wrong property.

The problem is not really technical; it is a permissions design problem. A system built for one hotel does not distinguish between “seeing everything” and “operating everything”, and that distinction is exactly what a multi-hotel group needs from day one.

The three layers a group needs to keep separate

For multi-property to work without friction, it helps to think in three separate layers, each with its own rule.

Cash: never mixed

Each hotel in the group has its own cash drawer, its own shift close and its own cash. One hotel’s cash page (Cash and shift close) should never show another’s movements, not even to the group’s general manager, who sees the consolidated view in a separate report, not in the daily operation of each drawer. Mixing cash between properties is not a convenience; it is an internal control problem that sooner or later produces a discrepancy nobody can explain.

Folio: always tied to a single property

A guest’s folio belongs to the property where they are staying. If the same guest later stays at another hotel in the group, a new folio opens at that property; the old one is not reused. A room charge (Room charge) posted by mistake to the wrong property creates a double problem: the guest sees a charge they do not recognize, and the hotel that actually earned it does not get credited.

Permissions: by role and by property, at the same time

A server at Hotel A does not need to see anything from Hotel B. A food and beverage manager at one property may only need to see their own. The owner and the corporate controller are the only roles that genuinely need to cross properties, and even then at different levels: one to consolidate figures, another to step in and operate if needed.

What is worth consolidating

Strict separation of cash and folio does not mean the group has to fly blind property by property. Some information does gain value when consolidated, as long as consolidating stays clearly different from mixing.

• Total group sales per day, adding each property as a separate line, not as a single figure with no breakdown.
• Food and beverage revenue per occupied room (/blog/como-se-calcula-el-consumo-de-alimentos-y-bebidas-por-habitacion-ocupada) for each hotel, side by side, to compare real performance between similar properties.
• Food cost as a percentage of sales, by property, to spot whether one is losing margin against the others.
• Shift closes by revenue center, grouped by hotel, so the corporate controller can review all of them without logging into each system separately.

Comparing properties: the trap of comparing apples to oranges

Comparing two hotels in the same group is tempting and risky at once. A twenty room boutique hotel (Boutique hotel) and a one hundred fifty room resort (Resort) share neither size nor guest type, and comparing their absolute sales leads to the wrong conclusions. What can fairly be compared are the relative metrics: consumption per occupied room, average ticket, the share of room charges over total sales. Those numbers travel well between properties of different sizes, because they are already scaled.

The comparison also has to respect the type of operation. An all inclusive hotel (All inclusive) measures its restaurant differently from a city hotel where the guest pays for every item separately, and putting both in the same table without that note confuses more than it clarifies.

What a well designed dashboard looks like

A well thought out multi-property dashboard has a clear hierarchy: first the group, then each property, then each revenue center. The user should be able to enter at the group level to see the big picture, and drill down into a single property when something catches their eye, without losing track of where they are standing.

1. Group view: consolidated sales for the day, compared against the same day last week, with one row per property.
2. Property view: the full detail of that hotel, as if it were the only one in the system, with its own cash drawer and folios.
3. Revenue center view: the level where the captain and the food and beverage manager work every day, without seeing anything from other properties.
4. Alerts configurable by property, not only by group, since a reasonable threshold for a one hundred fifty room resort does not work for a twenty room boutique hotel.

An illustrative example with numbers

The figures below are made up to show the calculation; they are not data from any real group. Picture a group with two hotels: one with 30 rooms and one with 80, both with their own restaurant.

If the owner only looked at total sales, Hotel B would look better for selling more than double. But comparing revenue per occupied room, Hotel A captures more from every room night sold: 150 versus 115. That difference is what the corporate controller should investigate, not absolute sales, which only reflects the size of each property.

When the group grows: what to check before adding a third hotel

Every new hotel added to the group multiplies the risk of mixing cash and folios, if the foundation was not solid from the second one. Before opening a third property, it is worth checking these points.

• Confirm each property has its own shift close and nobody can see another’s cash without explicit corporate permission.
• Check that guest folios are fully separated by property, even if the same guest stays at more than one hotel in the group.
• Write down which roles are allowed to cross properties and which stay locked into their own, before someone requests it “urgently” and it becomes a permanent exception.
• Test the consolidated dashboard with real data from the first two properties before onboarding the third, to catch mixing issues before they become three times harder to fix.

It is worth taking the corporate team’s training as seriously as each property’s own training. A corporate controller who never learned to read the consolidated dashboard ends up asking each manager for separate reports by email, which brings back exactly the manual work multi-property was supposed to remove. Training is not a one time event: it is worth repeating every time a new property joins, because the dashboard changes shape with each hotel that enters the group.

What to do this week

1. Check whether any user can see more than one property’s cash without explicit corporate permission.
2. Confirm that guest folios are separated by property and not reused between hotels.
3. Compare revenue per occupied room across every hotel in the group, not just total sales.
4. Write the list of roles that genuinely need to cross properties and why, and the list of those that do not.
5. If the group is about to grow, test the consolidated dashboard with the current properties before adding the next one.

Inn Restaurant keeps cash and folios separated by property and consolidates the metrics worth seeing at the group level, with permissions that respect each hotel. The page for chains and groups (Chains and groups) explains how it is set up, and the fifteen minute demo (contact) is the best place to see it with your own properties.