Running 3–5 small hotels at once: one account, no more driving between properties

The previous two instalments of the DiOwner series went deeper into one property: the first covered how to read revenue, occupancy, ADR and RevPAR straight off your phone, the second how to control revenue leakage with figures you can trace. This instalment changes direction: instead of going deeper into a single hotel, it goes wider across several. This is the position of a group of owners that keeps growing in Vietnam — someone who opened a second property because the first one worked, then a third and a fourth, and at some point discovered that the hardest part is no longer running any one of them.

The hardest part is seeing all three at the same moment, against the same yardstick. This article is written for the owner of three to five small properties — mini hotels, guesthouses, homestays, serviced apartments — usually self-managed, with no analytics team, and spending much of the week on the road between sites. One thing to settle at the outset, because it runs through the whole article: the problem is that the figures arrive late and are not built to the same definitions; it is not the people managing each site. Three spreadsheets kept carefully by three careful people still will not add up to one picture, and the reason is entirely technical.

Part 1: What an owner of a few small properties has to do today to know where things stand

Describe the situation accurately before discussing remedies. For someone with three to five properties, keeping abreast of the business is usually a combination of the four activities below, running in parallel and repeating every week.

Four things that keep repeating

• Calling or messaging each site. How many rooms are still free tonight, how much came in today, was there any incident. The answers arrive scattered through the day, each site phrasing things its own way, and none of it is retained as data you can compare against next week.
• Waiting for the month-end report. What arrives is a summary, usually in the middle of the following month. It is enough to know how last month went, but far too late to do anything about last month.
• A different spreadsheet layout at each site. One records revenue by calendar day, another by duty shift; one separates room charges from services, another merges them; one deducts rooms under long-term repair from the room count, another does not. Every sheet is perfectly coherent within itself.
• Adding it all up by hand. This last step is usually done by the owner, in the evening, on a fourth spreadsheet — and it is the step that generates the most error, because it adds together figures that do not share a definition.

Three consequences of working this way

• The figures arrive too late to steer by, only late enough to record. Learning that property B has slipped after the month has closed makes that information purely historical.
• Properties cannot be compared with one another. When two sites calculate occupancy two different ways, 78% and 74% say nothing about which one is running better.
• Site managers spend time producing reports instead of selling rooms. Every time the owner asks, someone has to stop work, open the book and add it up again — and none of that effort produces a single night of revenue.

Part 2: Why three correct spreadsheets still will not add up to one picture

This is the heart of the article and also the part most often skipped, because it does not look like a problem — each spreadsheet is clean on its own, and whoever produced it can explain every line. The discrepancy only appears at the moment they are added together.

The five most common breaks in definition

• 1. Different day cut-offs. An accommodation business's working day ends at the night audit, not at 24:00. If property A closes at 2am while property B totals by calendar day, everything arising after midnight lands on two different days at the two sites. At month end the difference does not cancel itself out, because it sits at the opening and closing boundaries.
• 2. Different denominators for occupancy. Whether a room under long-term repair belongs in the sellable room count is a choice, and two sites may choose differently. The convention worth standardising on: exclude rooms withdrawn from service long term, retain rooms temporarily unsellable — either convention works, provided the whole portfolio picks the same one and does not change it midway.
• 3. Different names for revenue items. At one site "services" includes in-room drinks, at another they are separate; one puts money collected for a shuttle operator into revenue, another keeps it out. Add them together and the total is simultaneously overstated and understated, with nobody able to point to where.
• 4. Different handling of money received in advance. A deposit held for next month is booked in the month of receipt at one site and in the month of stay at another. This is what makes high-season revenue across a portfolio inflate and then deflate in ways nobody can account for.
• 5. Booking source entered afterwards instead of at the time. When the source of a booking is filled in while writing the report rather than when the booking is taken, channel mix becomes an estimate — and three people's estimates are three different answers.

These five have one striking thing in common: not one of them can be fixed by preparing reports more carefully. They follow from each property defining its own yardstick. Removing the discrepancy means moving where the definitions live — taking them out of the individual spreadsheets and putting them somewhere shared. That is the subject of the next section. The same way of looking at the stage between the folio and the ledger was set out in the article on hotel accounting under Circular 99.

Part 3: One portfolio needs one shared set of lists

"Portfolio" here means the simplest possible thing: the set of properties belonging to one owner or one group of owners. For a portfolio to be viewed as a whole, the five things below have to be identical at every property. This is a precondition, done before any talk of software or dashboards.

Five things that have to be shared

• The accounting day boundary set by the night audit. One cut-off time, written into your internal rules, applied to every property and every report. Changing it midway makes every like-for-like comparison meaningless.
• The room type list. It is normal for each property to have different rooms, but the way they are grouped should be shared: single, double, family, dormitory. Only with shared groups can average rate be compared across sites.
• The revenue item list. One code per revenue type, shared across the portfolio, and abolish the "miscellaneous" box entirely. Keep three groups clearly apart: the property's own revenue, cost of selling through intermediary channels, and money collected on behalf of third parties.
• The booking source list. Direct booking, online channel, returning guest, walk-in — one set of codes, recorded at the moment the booking is taken rather than filled in later.
• The formula behind each metric. Occupancy, average daily rate, revenue per available room — one formula each, written down once, used across the portfolio. This is the cheapest thing to standardise and the most expensive thing to leave unstandardised.

The encouraging part is that none of these five requires investment. They are one internal meeting and one page of rules. What does require investment lies elsewhere: making sure that, once agreed, those definitions are enforced automatically rather than depending on somebody remembering them. That is what a cloud AI hotel management software shared across the portfolio can do and three separate spreadsheets cannot: the shared lists live in one place, every property draws from them, and nobody has to remember anything.

Part 4: Why an owner needs a read-only app, not a login to the operational system

This is where we believe the real difference lies, and it is also the point least discussed in the market. Almost everything offered to the market is a full operational management system — built for the front desk, housekeeping, the cashier, the accountant. The default answer to an owner's needs is to give them an account inside that same system, usually an administrator account. That approach has four practical problems.

Four problems with giving an owner an operational login

• The owner has to learn the operational trade before they can read a figure. Those screens are designed for someone doing the job eight hours a day: room plans, arrival queues, open folios. The owner needs five numbers and has to pass through three levels of menu to reach them.
• The fear of clicking the wrong thing is real. An account with write permission can, in principle, change live data. Many owners therefore never open the system, or open it and only dare to look — and end up back on the phone asking.
• The operational system was not built for a phone screen. It is a tool used on a desktop at the front desk. Yet the moment an owner most needs the figures is while travelling, before a meeting, or at home in the evening.
• Permissions by ownership scope are not the operational system's job. When a portfolio has a partner who has invested in some properties but not all, what you need is "this person sees exactly these three properties" — a concept belonging to ownership, not to an operational role.

How a read-only app answers that

• Read-only by design, not by configuration. DiOwner has no screen that edits operational data. That is what lets an owner open the app without a second thought, and equally what lets the operations team be confident their figures are not being changed from outside.
• It shows only what the owner has to decide on. Revenue and its source mix, occupancy, average daily rate, revenue per available room, receivables — for each property and for the portfolio, on one screen.
• Built for the phone from the start, because that is the device the owner carries between sites.
• Permissions by property. Each co-owner sees exactly the properties they hold a stake in — transparent with your partners without opening the whole system to them.
• Figures read straight from the live system, with no summarising step. There is no intermediate sheet between the source data and the screen, so there is nowhere for re-keying errors to arise.

Details of each screen and each metric are on the DiOwner product page for DiCloud. The point to keep here is simply the division of roles: the operational system serves the people doing the work, the read-only app serves the person making investment decisions — two audiences, two designs, one source of data.

Part 5: Six questions you should be able to answer in three minutes each morning

A portfolio of three to five small properties does not need an elaborate dashboard. It needs exactly six answers, every morning, without calling anyone. Below is the set we suggest, in the order worth reading them.

The six questions

• 1. How many rooms are still free tonight at each property? This is the only one you can act on within the day — open up rates, push the channels, call your regulars.
• 2. How much did the portfolio take yesterday, and where did it come from? The source mix matters more than the total, because the total states the result while the mix states the cause.
• 3. What is each property's average daily rate compared with last week? Rate falling while occupancy does not rise is a signal to revisit your selling policy.
• 4. Which property has drifted furthest from its own figures for the same period last year? Comparing a property with itself is always fairer than comparing it with another — particularly when the properties differ in size and location.
• 5. How much is outstanding in receivables, and is any of it overdue? At a small property, one forgotten receivable can equal a week's profit.
• 6. How much money received in advance are you holding? This is money that has reached the account but is not yet yours. Without separating it, healthy cash flow is easily mistaken for healthy trading.

If those six questions need someone else to answer them, then even at a few minutes each the larger cost is elsewhere: an owner only asks when something looks wrong, and by the time something looks wrong it is usually late.

Part 6: Comparing properties fairly

Once the whole portfolio is visible on one screen, the natural reflex is to rank it. This is the easiest place to draw the wrong conclusion, because small properties within one portfolio are usually very unlike each other: different room counts, different locations, different guest mixes, different opening dates.

Four rules for comparing

• Do not compare absolute revenue. A 30-room property naturally takes more than a 12-room one. That figure says nothing about the quality of the operation.
• Compare with per-room metrics. Revenue per available room folds both rate and occupancy into one number, so it compares across properties of different sizes. How it is calculated and what it means was set out in detail in the first article of the DiOwner series.
• To consolidate, add the rooms first and divide afterwards. Portfolio occupancy has to be total room nights sold divided by total room nights available, not the arithmetic mean of the percentages. Averaging percentages gives a 12-room property and a 30-room property the same weight — and produces a figure that exists nowhere in reality.
• Compare against the same period before comparing against each other. Each property's trend over time is more reliable information than its rank against the others at a single moment.

Part 7: Forecasting across several properties — from rooms already booked, not from guesswork

With one property, an owner can still get a feel for whether next month will be busy or quiet. With three to five properties in different locations that feel stops working, because each has its own rhythm.

How the forecast works, and its limits

• The basis is rooms already booked. The forecast in DiOwner is calculated from the bookings already in the system for the days ahead, on 30, 60 and 90-day horizons, with a free date range as an option. This is a statistical forecast built on actual on-the-books data, not an artificial-intelligence model — we say so plainly, because naming it accurately is what lets you judge how far to trust it.
• Its greatest value is in comparison across properties. When one property holds markedly fewer forward bookings for next month than the others, that is a signal to intervene early — whereas by month end there is nothing left to intervene in.
• A limit to be aware of: a forecast based on rooms already booked will always run below actual results in markets where guests book close to arrival. It tells you the floor with confidence; it does not tell you the ceiling.

What DiOwner does not yet show — stated plainly to avoid wrong expectations

• Gross operating profit per available room (GOPPAR) — Coming soon. This metric requires operating costs to be gathered to the same standard at every property, so it sits on the roadmap rather than in the set of metrics running today. What is running today is the revenue and receivables layer.
• So do not read a revenue ranking as a profit ranking. A property leading on revenue per available room can still come last on profit if its rent is markedly higher.

Part 8: Summary table — what trips you up across several properties, and how to handle it

Part 9: A five-step plan for an owner of 3–5 properties

The order below is deliberate: the first three steps are internal, cost nothing and can be done this week; only the last two involve tools.

Three internal steps

• Step 1 — Fix a single accounting day boundary at the night audit, tell the duty staff at every property, and write it as one line in your internal rules.
• Step 2 — Build one shared set of lists: room type groups, revenue items, booking sources. One working session with the people running the properties is enough, and it is better done together so each site understands why the change matters.
• Step 3 — Write down the formula for the three metrics you will compare on, together with the convention on rooms withdrawn from service. Post it where everyone can read it; it ends most of the arguments that would otherwise follow.

Two steps about tools

• Step 4 — Bring the properties onto one operational platform. Not necessarily all at once; one at a time is fine, provided the shared lists from step 2 are ready so that each new property can use them from day one. A safe way to move the data was set out in the article on migrating from spreadsheets to management software.
• Step 5 — Open a separate reading layer for the owner and any investing partners, with permissions matching each person's ownership scope. This step only means something after the four above; putting a dashboard on top of data that has not been standardised merely lets you see the wrong numbers faster.

Conclusion

An owner with three to five small properties is not short of figures — they have too many figures and no shared yardstick. Three things decide the outcome, in this order: one accounting day boundary for the whole portfolio; one shared set of lists so that every property calls the same thing by the same name; and a separate reading layer for the owner, kept apart from the screens used by the operations team. The first two are internal conventions, achievable this week at no cost. The third is where a properly designed tool makes a real difference.

On that footing, DiCloud — an online AI hotel management software — acts as the shared operational platform for the small properties, while DiOwner is the read-only layer for the owner: one source of data, two interfaces for two roles. That is also how we understand the term multi-property hotel management software: not a screen with more charts on it, but one shared set of lists plus a separate reading layer for the person making decisions. All of it sits within the total hotel management solution from DiHotel Solutions Corps.

If your portfolio includes a resort, a 4–5 star hotel, several legal entities, or a property run by an external management company, the companion piece on the DiHotel Blog addresses exactly that tier: one dashboard for the whole chain — several owners within one portfolio, seasons that peak at different times in different regions, and where the data boundary with a management company should sit. At that tier the operational work is handled by DiHotel, the AI hotel management software — the original platform for 4–5 star hotels, resorts and chains — while the smaller properties in the same portfolio run on DiCloud, and a single DiOwner app reads the figures from both platforms.