A guest books a room through an OTA, has dinner at the hotel, books a spa treatment under a different email and returns direct six months later. To the guest, that is one relationship. To the hotel’s systems, it can be four different people.
The property management system (PMS) knows the stay. The point of sale knows the restaurant spend. The spa system knows the treatment. Each holds a valid part of the guest, but none necessarily knows that the parts belong together. Some guests never appear in the PMS at all because their entire relationship with the hotel happens in its restaurants, spa, golf course or events.
That is the problem operators are trying to solve when they look for a hotel master profile. They want one durable record for the real guest: one that brings those fragments together, works across properties and survives a change of PMS. The term already has legacy meanings in hotel software, such as a parent sales account or a guest profile inside the PMS, but neither is the cross-system guest record operators and agents increasingly need.
The company-parent meaning
In OPERA, master can describe a relationship rather than a person. A master sales account can sit above subsidiary Company, Travel Agent or Source profiles. Negotiated rates can pass down through that hierarchy, while room-night and revenue production roll up into the master account. That is a sales-account hierarchy. It is doing real commercial work.
It is also why a search for hotel master profile often lands on account documentation. The operator wanted one guest across three properties. The docs describe a company and its subsidiaries. Both uses of master are real, but they are not the same thing.
What a PMS guest profile actually is
The other thing people mean is the guest profile: the record the PMS keeps so a repeat reservation can be made without retyping the name, the email and the preferences. Guest is its own profile type. When sharing is switched on, those profiles can be seen across the properties in a chain. When auto-merge is switched on, some of that system’s own duplicates can be collapsed.
That is still a profile inside one product. It knows what that PMS was told. It does not automatically know the point-of-sale room charge under a misspelt name, the spa booking with no room number, or the direct booking made on a work email while the OTA stay arrived on a proxy address. Sharing the profile across properties helps only where every property is on that system and the share is switched on. A group running one PMS in the city and another at the resort still has two profiles.
A well-maintained guest profile is necessary. Calling it a hotel master profile in the sense operators now mean just inflates a reservation profile to the size of the problem.
Why the PMS profile is not it
Three gaps sit between a PMS guest profile and one record per real guest.
First, scope. The profile lives where the reservation lives. Point of sale, spa, table booking and the booking engine each hold their own fragment, keyed for their own job. Nothing in the PMS contract says those fragments must join.
Second, identity. The same person arrives as several records, even inside one PMS: a direct booking and an OTA booking, a married name and a passport name, a personal email and a work email. Guest identity resolution is the work of deciding which of those records are the same person, and which value wins when they disagree. A PMS guest profile stores what it was given. It does not do that work across the stack.
Third, attachment. A profile that lives inside the PMS is attached to the PMS. Change the system and you are migrating profiles, not pointing the same record at a new one. Hotels that want the guest relationship back, rather than rebuilt after every rip-and-replace, need the record to sit above the systems that feed it.
What Casa Layer means by Master Profile
Casa Layer’s Master Profile is one record per real guest. It is assembled from the PMS, the point of sale, the booking engine and the other systems a hotel already runs. It sits above those systems rather than inside one of them, so a group can point the front desk, a CRM or an agent at the same person.
Casa Layer builds that record and holds it. It is not a company parent, and it is not a guest profile inside one PMS. It is not a CRM, a PMS or a messaging product. The layer is the product. We sell none of the applications the record feeds, so there is nothing here for it to be locked into. Your own source systems stay the record throughout. Replace the CRM at one property or the PMS at another and the resolved person is untouched, because the person never lived inside those tools.
That is a different claim from ownership. What is true, and testable, is narrower: the record is not inside any one supplier’s product.
Vocabulary is the next step, not the first
A hotel semantic layer is a shared vocabulary, so guest and reservation mean the same thing to every agent. That work starts after the person has already been decided, or after the stack has been replaced so that only one person-record exists.
If you keep the stack, the first job is the person. The Master Profile is that job. Once it exists, a vocabulary has something to talk about. Until it exists, the most careful definition of guest is still a word with several referents.
Frequently asked questions
What is a hotel master profile?
In the software hotels already run, a hotel master profile is usually one of two things: a company parent in a rate-share hierarchy, or a guest profile inside a single PMS. Neither is one record per real person, sitting above the PMS, the point of sale and the booking engine, that anything in the house can be pointed at.
Why does master often mean a company, not a guest?
Because the older use is a sales-account hierarchy. A parent shares negotiated rates with subsidiaries and rolls revenue up. Travel-agent and source accounts work the same way. That is real commercial work. It is not one person across the stack.
Is the guest profile in the PMS a master profile?
It is the record the PMS keeps so a repeat reservation can be made without retyping the name and the preferences. It knows what that system was told. It does not automatically know the point-of-sale charge, the spa booking or the OTA stay that arrived on a proxy address, and it is attached to the PMS.
How is Casa Layer's Master Profile different?
Casa Layer's Master Profile is one record per real guest, assembled from the PMS, the point of sale, the booking engine and the other systems a hotel already runs. It sits above those systems rather than inside one of them. Casa Layer builds that record and holds it. We sell none of the applications it feeds.
Where does the Master Profile sit?
Above the systems that feed it, not inside the PMS, the point of sale or the booking engine. Replace the CRM at one property or the PMS at another and the resolved person is untouched, because the person never lived inside those tools. Your own source systems stay the record throughout.