What a hotel master profile is (and why the PMS one is not it)

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 guest card inside one property system is the stay that system already holds. A Master Profile is the person that stay belongs to, sitting above the stack.

One record per real guest

A hotel master profile is one record per real guest. The guest card inside one property system is the record the PMS keeps for the stay it was told about. Both get called a profile. They are different objects.

The card sits under the stack, inside the system that took the reservation. The Master Profile sits above that system, and above the point of sale, the spa and the booking engine. Hotels that want the guest relationship back need it there. The card remains the stay. The person those stays belong to sits above it.

What a PMS guest profile actually is

The guest profile is 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. The guest card inside one PMS stays the stay. The Master Profile is the person above that card. Casa Layer 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.

Master Profile versus “single guest view”

“Single guest view” is marketing language for a screen. A dashboard, a campaign audience, a desk widget: one tool assembling what it can see and calling the result the guest. A Master Profile is not a view. It is a record. One person, durable, sitting above the systems that feed it.

A single guest view can be true inside the tool that painted it and still be a fragment. The neighbouring category words (single guest view, 360-degree view, unified guest profile) describe an interface or an activation. They do not decide whether the restaurant cover, the spa booking and the OTA stay are the same person.

What a Master Profile must include to be useful

For a hotel group, a useful Master Profile is not a richer reservation card. It has to be one person, not one booking. Guest identity resolution is the work of deciding which records belong together when the same guest arrives as a direct stay, an OTA stay, a work email and a married name.

It has to reach past the reservation: point of sale, spa, table booking and the booking engine each hold a valid fragment, and some guests never appear in the PMS at all. It has to work across properties that do not share a PMS instance. It has to survive a change of system, because a profile attached to the PMS is migrated rather than pointed at a new feed. It does not have to replace those systems. Source systems stay the record of what happened. The Master Profile is the person those events attach to.

Master Profile and the semantic layer: the order of work

A hotel semantic layer is a shared vocabulary. That work starts after the person has been decided. If you keep the stack, the first job is the person. The Master Profile is that job.

The order is easy to invert. Two systems can agree what a guest is and still be talking about two people. Resolve the person, then give that person a vocabulary.

When a PMS guest profile is enough

A single property, one PMS, no separate POS identity, no spa book of its own customers, no sister hotel, and no plan to change the property system: in that house the PMS guest profile is the relationship. Calling that file a hotel master profile is not dishonest. It is just a small house.

The moment a second property, a second PMS instance, an outlet that does not share the reservation key, or an agent that needs the person rather than the booking appears, the reservation profile is a fragment again. A well-maintained PMS guest profile remains necessary. It is the stay system of record. It becomes a Master Profile only when the hotel’s whole relationship with the guest actually lives there.

Frequently asked questions