Multi-property hotel management: an owner's governance checklist

Multi-property hotel management is running several hotels under one set of rules: who may see and change each property, who approves a group-wide rate or policy change, how guest data and agency contracts cross properties, and one shared definition behind every report. The owner writes those rules before the software applies a default.

The group report does not match the sum of its properties, and nobody can say which number is right. The cause is rarely the software: nobody wrote down who may change a rate across the group, whose approval a group-wide policy needs, or which occupancy formula the group total uses. This article gives you the governance layer of multi-property hotel management: the visibility map, the approval rule, the legal questions around shared guest data, the contract structure for agencies, and the definitions that make group totals trustworthy. The permission setup itself belongs to the PMS user roles and permissions setup checklist.

What does multi-property hotel management actually change?#

It changes who decides, not just who logs in. Running several properties from one system turns everyday choices, such as a rate change, a report definition or a shared guest profile, into group-level decisions that need a named owner.

Single-property habits break quietly. A general manager who could edit any rate now reaches every property. A report saved with local filters becomes the group's default. A receptionist can search every guest in the group, not just the ones in front of them.

Separate three layers before anything else: visibility, what a person can see; authority, what a person can change; and approval, what needs a second person. Software arrives with defaults, and a default is a decision made by whoever installed it, not by the owner. Write the rules on one page first; retrofitting authority onto accounts that already exist is slower and more error-prone than starting with it.

The business day is the unit of consolidation. A group total only works if every property closes its day the same way, in the same order, before the group report runs; the mechanics are covered in how one hotel business day fits together. At the same time, decide what stays local on purpose. A group does not have to centralize housekeeping rosters or breakfast orders to be well governed.

Who should see which property in the group?#

The owner decides the visibility map, property by property and role by role, before accounts are created; otherwise the software applies whatever default it shipped with.

Separate reading from changing. A group revenue manager usually needs to read every property's rates and pickup; a property general manager usually needs to change only their own hotel. Shared services such as finance, central reservations and group sales need cross-property reading plus a narrow, named write.

Name exceptions instead of widening roles: the person, the property, the reason and the end date. Ask each role one question: what is the worst thing this person could do by mistake, and does the setup stop it before it reaches a guest or a rate? Agency and corporate portal users are part of the map too: they see their own bookings, not the group's book.

Leaver handling and periodic access reviews belong to the permissions checklist, not to this page.

Who may change a rate or a policy across the group?#

A change that reaches every property should be proposed by one person and approved by another, with a record; a change to one rate on one date at one hotel can usually stay local.

Classify changes by reach: one rate on one date; a rate floor for a season; a policy such as cancellation, child or pet rules that flows into contracts; a report definition. The rate floor is the governance object, not the individual rate. Individual rates move inside the floor; the floor moves with a signature.

Policy changes are contract changes. If an agency agreement refers to the hotel's cancellation policy, the contract owner belongs in the approval. Record four things for every group-wide change: what changed, who proposed it, who approved it and when it takes effect. Add how it can be undone.

Name a deputy for each approver. A rule that stops when one person is on holiday will be bypassed within a month. Keep the wording of the rule identical to the wording on the screen, so a manager can map the rule to the button they are pressing.

Can a hotel group share guest profiles between its properties?#

That is a legal question before it is a software one, and the answer depends on who the data controller is; ask counsel and record the answer as group policy.

Türkiye's personal data law is Law No. 6698 (Resmî Gazete, 7 April 2016) (opens in a new tab). It defines the controller as the person who decides the purposes and means of processing, so the first question is whether the group is one controller or each property is its own. The same law requires processing for specified, explicit and legitimate purposes, limited and proportionate to them, and kept only as long as the law or the purpose requires. A dinner preference recorded at one property is not automatically a legitimate purpose at another.

Whether sharing a profile across properties counts as a transfer under the law's transfer articles is not something this article can settle; treat it as a question for counsel, with the group's structure in front of them. Guest identity data collected for KBS, the guest identity notification, is not a recognition asset: Law No. 1774, Articles 9 and 14 (opens in a new tab) provides that, without a court order, no one other than the authorised official bodies may make use of the identity notifications.

A workable middle ground is a written purpose list, field by field, agreed with counsel: a group profile exists only where the guest was told and the purpose is on the list. Decide first, configure second. A group-wide guest search switched on because it was easy to enable is the wrong order of events.

How should agency and corporate contracts work across several properties?#

One agreement can cover several properties, but each property must be able to see exactly what it has committed to, and only named people should be able to accept a request that spans the group.

Separate the contract from the rate set: one agreement, one rate set per property, one validity window, one place where all three are stored. Decide allocation or free sale per property, in writing, before the season starts, and say who may change that decision mid-season. Name who may accept and who may decline a group or series request that spans properties, and what the property manager is told when it happens.

A quote should show its working: the hotel's net, each rule that fired and the final price, so a property can check a booking it did not make. Travel agents and corporate clients book through their own portals and see their own bookings; the group sees the whole picture. Charges that land on a master account and are routed later need the same terms everywhere, which is where folio, posting and routing terms matter.

AI Otel's hotel operating system is built to run single hotels and groups from one login, with travel agents and corporate clients booking through their own portals. It is built and working, ahead of launch.

How do you keep group reports comparable across properties?#

Fix one definition per measure, write it down, and make every property report against it; a group total is only as trustworthy as the weakest definition inside it.

The usual culprits are few and predictable: the occupancy numerator and denominator, the date basis (business date or calendar date), the currency and the exchange rate used, the treatment of out-of-order rooms, and the treatment of complimentary and house-use rooms. Published statistics have the same problem: the Ministry of Culture and Tourism's accommodation bulletin (2025) publishes an occupancy column without stating its definition. If a national table needs a footnote, a group table does too.

Keep a definitions register: one line per measure, the formula in plain words, the owner of the definition and the date it last changed. Reconcile on a fixed rhythm: run the group report and the sum of the property reports for the same day, and investigate every difference rather than adjusting it away. Change a definition only with a date and a note, and either restate history or mark the break on the chart. Ask each property to close its business day before the group run, so the group number is never a mix of closed and open days. What each property should produce daily is covered in what a general manager's daily report should contain.

What goes on a one-page group approval matrix?#

One row per recurring decision, with one owner, one approver, a deputy and one place where the decision is recorded; if a decision is not on the page, it has no owner.

Keep it to decisions that recur. A matrix that lists every possible action becomes a document nobody reads. Add a row the second time a decision appears without a home; that is the signal it needs one. Publish it where property managers can find it, and use the same words as the software screens so the rule maps to a button. Review it once a season, and after any change of group structure, new property or new agency agreement.

The matrix is a governance document, not a permission list. Turning it into accounts and roles is the permissions checklist's job.

What to do next#

Write the two documents before the next account is created: a one-page approval matrix with one owner and one approver per recurring decision, and a definitions register with one formula per measure. Everything else in this article hangs off those two pages: visibility follows the matrix, group-wide changes follow the approver column, guest data follows the policy your counsel signs off, and group totals follow the register. Then configure the system to match, and review both pages once a season. If you want to see how a single system can carry this structure, request a briefing.