A guest stays at the city hotel, eats in the restaurant, books the spa under a different email, then stays at the resort six months later. To the guest that is one relationship. To the group’s systems it is often four people.
Operators then get sold a unified guest profile. Sometimes it is a prettier card in the property management system. Sometimes it is a marketing list wearing a 360 label. Sometimes it is the real thing: one person-record that stays true across properties and systems.
Casa Layer calls that durable record a Master Profile. Guest identity resolution is the work that builds it. The three terms are not interchangeable.
The phrase vendors use, and what must be true underneath
Unified guest profile is sales language. It promises one guest. The work underneath is narrower and testable.
For the phrase to mean anything in a hotel group, four things have to be true. It is one person, not one booking and not one campaign audience. It is true across properties, including properties that do not share a PMS instance. It is true across systems, including fragments that never reach the reservation. And it is durable: when two source values disagree, a rule picks a winner you can see; when you change a tool, the person is still there.
If any of those fails, you have a profile. You do not have a unified guest profile. A vendor can still put the words on a slide.
A unified guest profile is not a PMS guest profile
The PMS guest profile is the reservation record. It exists so a repeat stay can be made without retyping the name, the email and the preferences. When sharing is on, properties on that system can see the same card. When auto-merge is on, some of that system’s own duplicates collapse.
That is still one product’s file. It knows what that PMS was told. It does not automatically know the restaurant cover under a misspelt name, the spa booking with no room number, or the direct stay on a work email while the OTA stay arrived on a proxy address.
Sharing across a chain helps only where every property is on that system. A city hotel and a resort on different PMS instances still have two people. Putting every hotel onto one PMS is a migration, not a unified guest profile.
A well-maintained PMS guest profile is necessary. It is the stay system of record. Calling it unified inflates a reservation card to the size of the group problem.
A unified guest profile is not a CRM contact
A CRM contact is the person as that CRM knows them. It is a workflow record: campaigns, notes, consent flags, the last email opened. It is not one person across the stack.
The CRM inherits whatever identity it was given. If the PMS sent one row and the booking engine sent another, the CRM has two contacts, or one contact missing half the stay. Cleaning inside the CRM does not join the point-of-sale cover that never reached it.
A Master Profile sits above the CRM rather than inside it, so replacing the CRM does not cost the resolved record. Casa Layer builds that record and holds it. We sell no applications on top of it, so there is nothing for it to be locked into; your own source systems stay the record throughout.
A unified guest profile is not a guest 360 in a marketing suite
Guest 360, single guest view, 360-degree profile: category language for a screen. One tool assembling what it can see and calling the result the guest.
A marketing suite can resolve a profile so it can activate it inside the same vendor’s email, upsell and reputation tools. That is a legitimate product. It is also a campaign object. The comparison is set out in Hotel CDP vs guest identity layer.
The test is simple. If you change the email tool, is the person still there? If the restaurant cover and the OTA stay never entered that suite, is the view still calling itself 360?
A unified guest profile, if the words are doing any work, is the person that view would have to read. One is a window. The other is the person the window is supposed to open onto.
What unified requires across a hotel group
Three requirements, and they are not optional for a group.
Cross-property. A group is not one hotel with a shared login. Properties that do not share a PMS instance do not share a person. Shared profiles inside one chain database cover the properties on that system. They do not join a city stay to a resort stay on a different instance, or either stay to a cover that never entered that file.
Fragments outside the reservation. Point of sale, spa, table booking, the booking engine, a wifi portal: each holds a valid part of the guest. Some guests never appear in the PMS at all, because their whole relationship is a restaurant, a spa or an event. A profile that only unifies reservations is a unified booking file.
Survivorship. Two records for the same guest will disagree. One has a personal email, the other a work address. One has last year’s mobile, the other a number confirmed at check-in this morning. Survivorship is the rule that picks a winner, and lets you see why. Without it you have a stitch, not a record: two phones, two emails, and an agent that picks one at random.
A single property, one PMS, no separate outlet identity, no sister hotel: in that house the PMS guest profile may already be the relationship. The moment a second property, a second PMS instance or an outlet that does not share the reservation key appears, the reservation profile is a fragment again.
How a unified guest profile gets built
Identity resolution is the work. It decides which records across the group’s PMS, point of sale, booking engine and OTA bookings belong to the same person, then keeps one Master Profile above those systems.
It looks for a shared exact identifier first: a real email, a phone number, a loyalty ID the guest actually presented. Where those keys are missing or fake, it weighs weaker signals together. Borderline pairs wait for a person. A missed link is recoverable. A silent false merge is what last night’s briefing already used.
This page is not that essay. The matching, the OTA proxy-address problem, and why a one-time cleanup does not hold, live in guest identity resolution for hotel groups. What matters here is the output: one person, not a cleaner card inside one property system.
A hotel semantic layer then gives guest and stay a shared vocabulary. It does not decide which records are the same human.
Unified guest profile and Master Profile: same job, different words?
Often, yes. When a buyer means one person-record true across properties and systems, they are asking for what Casa Layer calls a Master Profile.
The words still do different jobs.
Unified guest profile is the category phrase. Vendors use it for a stitched view, usually inside one activation tool. It describes an outcome on a slide.
Master Profile is Casa Layer’s name for the durable record that outcome would have to read. One person, sitting above the systems that feed it, not inside the PMS, the CRM or the marketing suite. Casa Layer builds that record and holds it. We sell none of the applications it feeds, so there is nothing for it to be locked into; your own source systems stay the record throughout.
Identity resolution is the work that produces it. The phrase, the record and the work are three things. Collapsing them is how a prettier PMS card ships under the same label.
A loyalty profile is a fourth thing again: a member row, keyed on enrolment. Loyalty programmes miss repeat guests because they count members, not people. The loyalty tool should read the unified record, including guests who never enrolled.
What to demand before you accept unified
Ask for the mechanism, not the word.
- Is it one person, or one booking, or one campaign audience?
- Does it include fragments that never reach the PMS: point of sale, spa, table booking, the booking engine?
- Does it work across properties that do not share a PMS instance?
- When two source values disagree, can you see which value won and why?
- If you change the system the profile lives in, is the person still there?
- Can the desk, the CRM and an agent read the same record, or only the suite that painted it?
- Can you unmerge a bad join, and are borderline pairs held for a person?
- Does the loyalty tool read this record, or does the loyalty tool own a second one?
If any answer is no, it is a profile with a unified label.
Frequently asked questions
What is a unified guest profile in a hotel group?
A unified guest profile in a hotel group is one person-record that stays true across properties and systems. It is not a prettier guest card inside the property management system, and it is not a marketing list wearing a 360 label. Unified means those fragments have been decided to be one person, including stays that never shared a PMS instance. Casa Layer calls that durable record a Master Profile. Identity resolution is the work that builds it.
Is a unified guest profile the same as a Master Profile?
Often the buyer who says unified guest profile is asking for what Casa Layer calls a Master Profile: one durable person-record above the stack. The words still do different jobs. Unified guest profile is neighbouring marketing language for a stitched view, usually inside one activation tool. A Master Profile is the person that view would have to read. Casa Layer builds that record and holds it. We sell no applications on top of it; your own source systems stay the record throughout.
Does a unified guest profile live in the PMS?
No. The PMS guest profile is the reservation record that property system needs to check someone in. Sharing it across a chain lets properties on the same system see the same card. That is still a profile inside one product. A group running a second PMS instance still has two people. A unified guest profile sits above the PMS rather than inside it, and above the point of sale and the booking engine as well. Source systems stay the record of what happened. The profile is the person those events attach to.
Can you have a unified guest profile without identity resolution?
No. Identity resolution is the work of deciding which records belong to the same person when the same guest arrives as a direct stay, an OTA stay, a work email and a married name. Without that work you have a stitch of whatever one tool can see, not one person. A semantic layer can define what a guest means and still point at several disconnected records. The matching itself is the subject of the guest identity resolution guide.
Is a unified guest profile the same as a single guest view?
No. 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 unified guest profile is not a view. It is a record. A single guest view can be true inside the tool that painted it and still be a fragment. Guest 360 is the same category language. It describes an interface or an activation. It does not decide whether the restaurant cover, the spa booking and the OTA stay are the same person.
What should you demand when a vendor promises a unified guest profile?
Ask whether it is one person, or one booking, or one campaign audience. Ask whether it includes fragments that never reach the PMS, and whether it works across properties that do not share a PMS instance. Ask whether the person is still there if you change the system the profile lives in, and whether the desk, the CRM and an agent can read the same record. If any answer is no, it is a profile with a unified label.
How does a unified guest profile differ from a loyalty profile?
A loyalty profile is a member row, keyed on enrolment, usually an email the guest typed once. OTA stays arrive with an alias rather than that email. The programme counts members, not people. A unified guest profile is the person the loyalty tool should read, including guests who never enrolled. Point the programme at the Master Profile. The record should outlast that decision.