One dashboard for the whole chain: resort owners no longer need to call each manager

Part 1: How a multi-property owner collects figures today

Let us start by describing the current situation accurately. In most multi-property portfolios in Vietnam, getting a picture of performance goes through four stages, and all four take up the time of people who should be doing something else.

The four stages of the collection loop

• Calling each property manager. Usually at the start of the week or before a meeting. The manager stops what they are doing, opens the system, adds things up and replies. The answer is correct at that moment, but it is not stored as data that can be checked against next time.
• Waiting for the periodic report. The monthly report usually arrives in the second week of the following month, after accounting has closed the books. It serves settlement well and serves operational decisions poorly.
• Stitching the reports into one summary. This is usually done by a specialist in the portfolio office, copying figures from several files into one. Every copy is a chance for error, and there is no path back from a cell in the summary to the source document.
• Asking questions back when a figure looks odd. This is where the loop closes: the owner asks, the property explains, the office corrects the sheet. One figure can take several days to go round this cycle.

Three hidden costs of this loop

• Delay turns operational information into historical information. A property whose bookings for next month are falling is something you need to know this week, not after the month has closed.
• Management time shifts from operations to reporting. For a resort in peak season, that is a real cost.
• The relationship between owner and management is set on the wrong axis. When every figure has to go through a round of explanation, the conversation easily slides from "what do we do next" to "where did this number come from".

Part 2: Three kinds of misalignment that make a consolidated table impossible to compare

The most frustrating thing about this problem is that it is invisible: each component report passes every internal check of its own. The distortion only appears when you add them up. The three types below cover almost every real-world case.

Type 1 — Timing misalignment

• Different day-close times across properties. A lodging property's business day ends with the night audit. A resort with a bar open until 2 a.m. will close later than a city hotel. If that cut-off is not standardised, revenue for every day is partly shifted, and the shift does not cancel out at the start and end of the period.
• Management reporting periods out of step with accounting periods. The weekly report runs from Monday, the monthly report follows the calendar, the accounting period follows the book-closing date. Three different rhythms, yet they are often quoted interchangeably in the same meeting.

Type 2 — Metric definition misalignment

• The denominator of occupancy. The convention to apply consistently: exclude rooms withdrawn from service long term, retain rooms that are temporarily unsellable. A resort renovating a row of villas without removing them from total rooms will make its own figures look worse; a property that removes too much will make its figures look better. Neither is intentional, and both make the ranking meaningless.
• The scope of average daily rate. Are house-use rooms included, are complimentary rooms under a contract included, are villas sold as all-inclusive packages included — each choice produces a different number.
• Revenue before or after deductions. This is where two properties can differ significantly without it being visible in the table.

Type 3 — Chart-of-items misalignment

• Revenue departments split differently. One property separates the spa from the leisure group, another combines them; one puts conference revenue under food and beverage, another keeps it separate. On consolidation, the portfolio's revenue structure becomes a picture that cannot be read by department.
• Money collected on behalf of third parties mixed into revenue. Attraction tickets, transfers, tours booked for guests — the property's share is only the commission. Lumping it in creates phantom revenue at portfolio level.
• Inter-property transactions not flagged. When one property sells a service to a guest of another property in the same portfolio, that item must be identifiable so it can be eliminated on consolidation — otherwise the portfolio counts its own revenue twice. This topic connects directly with our article on hotel chain accounting under Circular 99.

Part 3: One portfolio needs one shared master data set

The solution to all three kinds of misalignment does not lie in the reports but in the layer beneath them: shared master data. The idea is very simple — take the definitions out of each individual property and put them in a single place, so every property draws from there instead of building its own.

Six things that must be shared across the portfolio

• The accounting date, tied to the night audit. One cut-off for the whole portfolio, written down as a policy and kept unchanged from period to period. If a property has a genuine operational reason to close later, that exception must be documented and taken into account when comparing.
• The list of revenue and expense departments. Use one department structure following industry practice, so that every property's income statement can be stacked on top of the others.
• Room types mapped to standard groups. Each property has its own product, but it must be mapped to a common set of groups so average rates can be compared.
• Guest source and sales channel codes. One code set for the entire portfolio, assigned at the moment the booking is taken — this is the precondition for any meaningful source-mix analysis at portfolio level.
• The formula for each metric. Occupancy, average daily rate, revenue per available room, total revenue per available room. One formula per metric, written down and issued.
• The convention for eliminating internal transactions. How transactions between properties in the portfolio are flagged, so consolidated figures are not double-counted.

This is also where the underlying platform decides everything. When the properties all run on the same multi-property hotel management software, the master data lives in one place and is enforced automatically; every property has to use the same codes, the same groups and the same formulas, regardless of whether anyone remembers to. When properties run on different systems, shared master data can still be built, but it has to be maintained through human discipline — and discipline wears down over time.

Part 4: Why owners need a dedicated read-only app, not an account in the operations system

This is the part we most want to explain in detail, because it is where the market has left a gap. Almost every solution on offer is a full operations management system — built for front office, housekeeping, reservations, cashiering and accounting. The default way to handle the owner's needs is to give them an account in that same system. It is a reasonable answer technically and an unreasonable one in human terms.

Five reasons an operations-system account is not the answer

• It forces decision-makers to learn operational workflows. Operations screens are optimised for people who use them eight hours a day. A board member needs five numbers before a meeting, not the room status map of every property.
• Write access creates unnecessary risk. An account that can change live data is an operational risk, even if its holder never intends to change anything. Removing write access altogether makes that risk disappear by design, not by configuration.
• Operations systems are not built for phones. Owners and board members need the right figures while travelling, while abroad, or ten minutes before a meeting.
• Permissions by scope of ownership are a different concept from operational roles. Operations systems assign permissions by job function. An investment portfolio needs permissions by "who owns which part" — two completely different axes.
• An owner's presence inside the operations system is easily read as surveillance. A separate read layer, showing exactly the agreed set of metrics, keeps the conversation at the governance level rather than the transaction level.

How a dedicated read-only app for owners solves the problem

• Read-only by design. DiOwner has no screen that can change operational data. That is both peace of mind for the user and a commitment to the management team that their figures are not being interfered with from outside.
• Shows the governance layer. Revenue and source mix, occupancy, average daily rate, revenue per available room, receivables — for each property and for the whole portfolio.
• Figures read directly from the live system. There is no intermediate spreadsheet between the source data and the screen, so the number in the app and the number in the system are the same, and can be traced back to the source document when needed.
• Permissions by property and by role. Each board member and each co-investor sees exactly their own scope — transparency with partners without opening up the whole system.
• Proactive alerts. When a metric crosses a threshold you have set, the app speaks up instead of waiting for someone to open it.

The full list of screens and metrics is on the DiOwner product page. The key point is the division of roles: the operations system serves the people doing the work, the read-only app serves the people making investment decisions — two audiences, two designs, one single data source.

Part 5: Multiple legal entities and multiple owners in one portfolio

This is a feature that large portfolios almost always have, and it is where the spreadsheet approach collapses fastest. A five-property portfolio may span three legal entities, two of the properties may have their own co-investors, and one may sit in a joint venture with a foreign partner.

Four things that must be kept clearly apart

• Legal-entity boundaries and management boundaries do not coincide. Financial statements are prepared by legal entity, under the accounting regime. Management reports are prepared the way the owner looks at the portfolio — by region, by brand, by property type. A portfolio needs both, and one cannot stand in for the other.
• Viewing scope follows ownership share. A co-investor in two properties should see only those two properties. This is a requirement both of security and of propriety in the partnership.
• Internal transactions between entities in the portfolio. They must be flagged so they can be eliminated in management consolidation, while still remaining on each entity's own books.
• One set of metrics for every party. When the owner, the co-investors and the management team all look at the same screen, calculated with the same formulas, meetings move from reconciling figures to discussing options. This is the biggest value a shared system delivers, and it is hard to see on a feature list.

Part 6: Properties run by a third-party management company — where to draw the data boundary

Many owners hold the asset but hand operations over to a professional management company. This model is entirely normal and increasingly common in the resort segment. Problems only arise when access to data is not clearly agreed in the management contract from the outset.

Three things the data section of a management contract should include

• The owner has real-time, read-only access to the operational data of their own property. This is a clause to have from day one, not something to ask for after a dispute arises. Setting it at read-only level is also how the management company's operating authority is protected from interference.
• The data belongs to the property, not to the management company. When the management contract ends, guest history, booking history and revenue history must stay with the property. This is a valuable intangible asset and is very often forgotten until handover.
• The set of metrics and their formulas are agreed in writing. If the management company reports to its own internal standard while the owner measures against the portfolio's master data, every discussion about performance starts with an argument about the numbers.

Part 7: Seasonality that differs between regions — how to read it correctly

A portfolio with a beach resort, a city hotel and a highland property will never share a single seasonal curve. That is a characteristic, not a problem — but it breaks every naive comparison.

Four principles for reading figures when seasons are out of step

• Compare each property with itself in the same period last year before comparing properties with each other. Each property's trend over time is more reliable information than its ranking at a single point in time.
• Read rankings against each property's own season, not the portfolio's. A beach resort at 55% occupancy in the middle of its low season may be doing better than a city hotel at 70% in the middle of conference season.
• See the phase difference as a coordination advantage. When one property is in its low season just as another is at its peak, the portfolio has room to coordinate seasonal staff, sales campaigns and even cash flow — something a single property does not have.
• Set alert thresholds per property, not one threshold for all. A shared threshold will sound constantly at the property in its low season and stay silent at the one sliding in the middle of its peak season.

On-the-books forecasting, and its limits

• It is based on the bookings already in the system for upcoming dates, with 30-, 60- and 90-day horizons, plus an optional custom date range. This is a statistical forecast built on actual on-the-books data, not an artificial-intelligence model — we say this clearly because naming it correctly lets users know how far to trust it, and because a mislabelled forecast is more dangerous than no forecast at all.
• At portfolio level, its greatest value is spotting unusual phase shifts — a property whose advance bookings for next month are well below its own usual pattern, while the other properties look normal.
• The limit you need to know: a forecast based on rooms already booked will always come in below reality in markets where guests book close to arrival. It tells you the guaranteed floor, not the ceiling.

Part 8: Summary table — where multi-property portfolios get stuck and how to handle it

Part 9: What DiOwner shows today, and what it does not yet show

This section is written to prevent mistaken expectations — which matters especially for a readership of owners and boards, who will make decisions based on these very numbers.

Running on live data

• The revenue and source-mix layer for each property and for the whole portfolio, updated in real time from the live operations system.
• Occupancy, average daily rate and revenue per available room, calculated with a single formula, using the convention of excluding rooms withdrawn from service long term and retaining rooms that are temporarily unsellable.
• Receivables and ageing, with threshold-based alerts — a key group of metrics for portfolios with many travel-agency and corporate contracts.
• On-the-books forecasting with 30-, 60- and 90-day horizons.
• Consolidation done properly: rooms are added up across the whole portfolio before dividing, so consolidated figures reflect true scale instead of being skewed by the smaller properties.

Still on the roadmap

• Gross operating profit per available room (GOPPAR) — Coming soon. This metric requires operating costs to be collected to the same standard at every property, so it is not yet part of the live set of metrics. The income-statement structure that leads to it is covered in full in our article on the USALI standard.
• A consequence to bear in mind when reading rankings: a ranking by revenue per room is not a ranking by profit. A property that leads on revenue can still come last on efficiency if its cost structure is much heavier.