Your guest data is scattered, and your agents have nothing solid to run on. Across a typical group, the same guest exists as many separate, unconnected records: one in each property’s PMS, one in the POS, possibly several more across the booking engine, OTA bookings, the wifi captive portal, and the spa or food and beverage point of sale. These records rarely agree. Names are spelt differently, phone numbers are absent, email addresses conflict, and loyalty identifiers (if they exist at all) live in a separate silo. Point an agent at data like that and it works from a broken picture: confident, and wrong. And connecting it yourself is a project most teams do not have the people to take on.
Identity resolution is what brings those records together into one authoritative profile that sits above the systems feeding it: the record every agent then runs on. This guide explains why the problem exists, how resolution works, and what a group should look for when evaluating a solution.
The fragmentation problem in concrete terms
Take a guest who has stayed five times over three years across three of the group's properties. In the first property's PMS they appear under two records: one from a direct booking made with a personal email address, and one from a Booking.com reservation that arrived with a proxy email address. At a second property, running a different PMS instance entirely, they exist again under a fresh record with no link back to the first. In the POS their name was entered by a bartender from a room charge: it is a phonetic approximation of the real name, with no email or phone attached at all. In the booking engine, they registered an account with a work email address, different from either PMS record. On wifi sign-up, they gave their mobile number but left the email field blank. In the spa system, their profile was created by a therapist during the first visit, with no room number and a slightly different surname spelling.
That is several systems across more than one property, a handful of records, and potentially more profile fragments if any system has created duplicates internally. None of them is wrong, exactly. Each captures a real interaction. But none of them tells you who this guest actually is, what they value, what they have spent across the group, or how often they stay. For any consumer of the record (your team, your CRM, or an agent asked to act on this guest) the data simply does not exist in usable form.
Multiply this across a group of five to thirty properties and tens of thousands of annual guests, several PMS instances among them, and the problem becomes structural rather than incidental. This is what any agent runs into the moment you point it at your guest data.
Why fragmentation happens
The fragmentation is not a failure of diligence. It is an architectural consequence of how hotel technology stacks evolved.
Different identifier schemes per system
Each system was built to solve a specific problem: reservations, billing, wifi access, food and beverage ordering. Each chose a primary key that made sense for its own use case. The PMS keys on reservation ID and room number. The POS keys on the room charge account opened at check-in. The booking engine keys on email address or account ID. The OTA keys on the booking reference. None of these keys is shared across systems. There is no universal hotel guest identifier that follows a person across touchpoints, because no one designed one when these systems were built.
Thin records, and no shared key to join them on
Reservations reach the property system quickly now. Most groups sit behind a channel manager that pushes each booking through close to the moment it is made, so the overnight batch import is no longer how most OTA bookings arrive. Speed was never the thing making this hard.
What arrives is thin: a name, an email address that is often a proxy, nationality, and meal board. Any point of sale transactions from earlier in the stay were logged against a room number rather than a person. So the systems end up holding the same guest under identifiers that have nothing in common, and delivering that faster does not produce a key to join them on. This is why real-time integration alone does not solve fragmentation, and why hotels who have just finished a channel manager project are often surprised to find the problem still there.
The OTA masked email problem
This deserves specific attention. Booking.com, and to a lesser extent Expedia and other OTAs, route guest emails through alias or proxy addresses: something like 2834567c5f1234@guest.booking.com rather than the guest's actual email address. This is deliberate. The OTA owns the direct relationship and has a commercial interest in keeping its channel opaque to the hotel.
The consequence is practical and significant. Email address is the most reliable single identifier for probabilistic matching, because most people use the same email address consistently across accounts. When the PMS holds a proxy address from an OTA booking and the booking engine holds the guest's real email from a direct booking, a naive email-match will find no link between them. Those two records remain separate even though they represent the same person. A well-designed resolution system recognises OTA proxy domain patterns (they are consistent and, in most cases, published) and routes those records toward fuzzy matching rather than exact email lookup.
What identity resolution actually does
Identity resolution has two complementary stages: matching and survivorship.
Deterministic matching
Deterministic matching works on exact keys. If two records share the same email address, the same phone number, or the same loyalty programme ID, they can be linked with high confidence without any further inference. Deterministic rules are fast and reliable, but they only work where common keys exist. As described above, that is less often than most hotels expect.
Probabilistic (fuzzy) matching
Probabilistic matching works on weighted evidence. A record with a name of “J. Harrison”, a mobile number of 07712 345678, and a stay in Cheltenham in October, matched against a record with “James Harrison”, the same mobile, and a booking engine account registered in Cheltenham: that is a strong match even without a shared email address. The system assigns a confidence score to candidate pairs and merges above a configured threshold, flagging borderline cases for human review rather than forcing an automated decision on ambiguous data.
The quality of fuzzy matching depends on the quality of the signals available. A hotel that collects mobile numbers at every touchpoint (including wifi sign-up and F&B ordering) will produce substantially better resolution than one that relies on name and stay dates alone.
Survivorship rules
Survivorship rules determine which value wins when merged records disagree. If two records hold different phone numbers, which one is canonical? Typically the answer is the most recently confirmed value, the most complete value, or the value sourced from the highest-trust system: a direct booking over an OTA reservation, for instance. Good survivorship logic is explicit and auditable. You should be able to see exactly why a given value appears on the Master Profile, and override it if necessary.
The Master Profile
The output of the resolution process is the Master Profile: a single, merged, deduplicated record for each guest that aggregates the best available data from every source. It is not a replacement for the underlying source records; those stay intact in their originating systems. The Master Profile is a layer on top, and it is the backbone the rest of the stack runs on: the authoritative view served to your team, your CRM, a guest app, and any agent (Claude, a revenue agent, a concierge assistant) through an open API. The agents will change every year. The layer they run on does not.
Resolution is not a one-time exercise. New records arrive constantly, guest data changes, and merge decisions made last quarter may need revisiting as new signals arrive. A live resolution system runs continuously, re-evaluating matches as data flows in from each connected system.
Where the resolved record ends up
There is a version of a “resolved guest profile” that is held by the OTA or the channel, not by the hotel. Booking.com has a highly resolved view of its guests: it knows their travel history, stated preferences, and cross-property spending patterns across thousands of properties. It uses that knowledge to serve personalised results and to price its commission leverage accordingly. The hotel that hosted those stays has none of it.
The question is therefore not only technical but strategic, and the OTA is not the only party that can trap the record. Most incumbent hospitality CDPs (Cendyn, Revinate, dailypoint, ireckonu, GuestXP) resolve the profile inside their own application suite, where it exists to make that suite perform. So the question to ask is not who owns the resolved profile, a word every vendor in this category now uses. It is what the profile is attached to: is it a layer that any tool can read and that survives you replacing the tools above it, or is it a feature of one application, resolved to serve that application, and gone from view when you stop paying for it?
This distinction matters most when the relationship changes: when a property loses preferred placement on an OTA, when commission rates shift, when a vendor raises its price or is acquired, or when a group wants to consolidate guest data across properties running different PMS systems. A group whose resolved record sits outside its applications can point any agent at it, and can change a CRM at one property without touching the record shared with the rest. A group whose guest intelligence lives inside a channel's or a suite's platform cannot do either.
What good resolution looks like and what to evaluate
When evaluating an identity resolution system, the questions to ask fall into three groups.
Data coverage
Does the system connect to every touchpoint in your stack: PMS, POS, booking engine, wifi, loyalty programme, OTA bookings? Resolution is only as good as the data it can see. A system that misses your POS data cannot link food and beverage spend to a guest profile. A system that cannot interpret OTA proxy email addresses will leave a large share of your OTA guest records permanently unlinked from their direct-booking counterparts.
Match quality
What is the system's approach to OTA proxy email addresses? How does it handle name variation: hyphenated surnames, common transliterations, title and prefix differences? How does it treat a false positive, where two genuinely different guests are merged, and a false negative, where two records that should be linked are not? Ask how each is defined, how it is measured, and how it is reported back to you once you are live. That is the standard we hold ourselves to: match decisions should be inspectable and their error rates visible in your own environment, rather than asserted in a sales deck.
Audit and control
Can you see why any given merge decision was made? Can you unmerge records if a merge was incorrect? Can you set survivorship rules that reflect the group's data priorities? Can you reach the resolved profile from the tools you already run, rather than only from inside one vendor's application? A resolved guest profile is only useful in practice if every consumer that needs it can read it through an open interface: your team at check-in or the bar, your CRM, and, increasingly, the agents a group is being asked to deploy, which can only act on the record beneath them.
Identity resolution across a hotel group, not one property
A property can share guest profiles across the hotels on the same PMS and still fail at group resolution. Shared profiles collapse duplicates inside one vendor’s file. They do not join a city-hotel stay to a resort stay on a different PMS, or either stay to a POS cover and an OTA booking that never entered that file.
Group resolution matches the same person across properties that do not share a database, and across systems that were never designed to share a key. The output is one Master Profile above those systems, not a cleaner card inside one of them. Putting every property onto one PMS is not that job. A single PMS still holds a reservation profile. See what a hotel master profile is, and is not. The neighbouring phrase is unified guest profile: same job, if the words mean one person across properties and systems rather than a prettier card.
False merges versus missed links: which failure hurts more
Two failures sit on either side of a match threshold, and they are not equal. A missed link leaves two incomplete pictures. A false merge joins two different people, so one guest inherits the other’s allergies, spend and stay dates. Prefer the missed link. Send borderline pairs to a person.
Merging two people is the failure that hurts. A missed link leaves two incomplete pictures; incomplete can be joined when a better signal arrives. A false merge writes the wrong person into the record every consumer then trusts. Bias the system against that merge, and keep a human on the cases the score cannot settle.
Continuous resolution versus a one-time cleanup
A cleanup project produces a clean file on the day it finishes. The next morning an OTA booking arrives on a proxy address, a bartender opens a cover under a phonetic name, and a direct booking lands on a work email the file has never seen. Within weeks the file is fragmented again.
Resolution has to run as records arrive, and to reopen last quarter’s matches when a new signal appears. A one-time cleanse is useful as a backfill. It is not the system that keeps the Master Profile true.
What agents need from a resolved profile
An agent pointed at five unlinked records will pick one and speak with confidence. What it needs is ground truth: one person, the evidence for the join, and a survivorship trail for any field that disagreed.
That record is not a campaign object. A hotel CDP resolves a profile so it can activate it inside the same suite. An identity layer resolves the person and stops. The comparison is set out in Hotel CDP vs guest identity layer. A hotel semantic layer then gives guest and stay a shared vocabulary; it does not decide which records are the same human. Loyalty tools fail the same way when they sit on unlinked copies.
Frequently asked questions
What is hotel guest identity resolution in one sentence?
Hotel guest identity resolution is the work of deciding which records across a hotel group's PMS, POS, booking engine and OTA bookings belong to the same person, then keeping one Master Profile above those systems. The profile is what the desk, a CRM and any agent then read, across the group rather than at one property. It is not a cleaner guest card inside one property system. Casa Layer builds that profile and holds it. The source systems stay the record of each stay and charge.
How does guest identity resolution work across PMS, POS, booking engine and OTA bookings?
A stay, a restaurant cover, a direct account and an OTA reservation usually arrive as four records with four keys. Resolution 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, name variants, dates, property, and scores the pair. Borderline pairs wait for a person. The joined record is the Master Profile. It does not live inside the PMS or the POS. Each source keeps its own row.
Why don't channel managers or POS to PMS posting fix guest identity?
A channel manager posts the reservation into the PMS close to the moment it is made. POS to PMS posting puts a restaurant or spa charge onto a room folio. Both are useful plumbing. Neither decides that the OTA stay, the direct account and the cover are one person, and neither works across two PMS instances in the same group. Speed of delivery is not a person key. The booking is still thin and the POS line is still a room number. Those pipes move transactions. Identity resolution says which transactions are the same guest.
What are OTA proxy emails and why do they break naive matching?
OTAs often give the hotel an alias rather than the guest's real inbox, typically a generated address on the OTA's own domain. That is a channel design, not a glitch: the OTA keeps the direct relationship. Naive matching treats email as the strongest exact key. Two stays of the same person, one direct and one via an OTA, then share no email and stay unlinked. A resolution system has to recognise those proxy domains and fall back to other signals, rather than concluding the guests are different people because the addresses do not match.
What is the difference between deterministic and probabilistic matching for hotel guests?
Deterministic matching joins records that share an exact key: the same real email, the same mobile, the same loyalty number. It is explainable. You can point at the key. Hotel data often has no such key. The OTA stay has a proxy address, the POS cover has a surname, the second property has its own PMS ID. Probabilistic matching scores those weaker signals together and proposes a join. Use deterministic matching as the backbone and probabilistic matching to extend coverage. Keep the threshold high enough that two different guests are not merged.
What is survivorship in guest identity resolution?
Survivorship is the rule that picks a winning value when two records for the same guest disagree. One file 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. Typical rules prefer the most recently confirmed value, the most complete value, or the value from the higher-trust source, a direct booking over an OTA reservation. The point is that the choice is explicit. You should be able to see why the Master Profile shows this phone number, and to override it.
Can two different guests be merged by mistake, and then what?
Yes. That is a false merge, and it is the failure to bias against. Two guests then share one profile: allergies, spend, preferences and stay dates get written onto the wrong person. An agent that reads that profile will treat the error as fact. A workable system lets you see why the merge happened, unmerge the records, and put the borderline cases in front of a person before they become canonical. A missed link is recoverable when a better signal arrives. A silent false merge is what last night's briefing already used.
Is hotel guest identity resolution the same as a hotel CDP?
No. A hotel CDP, the category that includes suites such as Cendyn and Revinate, typically resolves a guest profile so it can activate that profile inside the same vendor's marketing tools. A guest identity layer resolves the person and stops. The record is then readable by tools that vendor does not sell. The distinction is coupled against decoupled, not better against worse. If you expect to change a CRM or a PMS and keep the same person, you want the layer. That comparison is the subject of Hotel CDP vs guest identity layer.
Does guest identity resolution replace the PMS guest profile?
No. The PMS guest profile remains the reservation record that property system needs to check someone in and to reuse a name. Identity resolution does not replace it, and it does not require you to rip out the PMS. The Master Profile sits above that profile, and above the POS and the booking engine, so the same person is visible when the group runs more than one PMS. Casa Layer builds and holds that layer. We sell none of the applications it feeds. Your source systems stay the record of the stay.
What should we ask vendors about match quality and audit?
Ask how false merges and missed links are defined, measured and shown to you in your own data, not in a deck. Ask what happens to OTA proxy addresses, and whether those records are sent to fuzzy matching instead of dropped. Ask whether you can see the evidence for any given join, unmerge a bad one, and set survivorship rules. Ask whether the resolved profile is readable from the tools you already run, or only from inside one application. Match quality you cannot inspect is a claim, not a control.
What is the difference between identity resolution and a CRM?
A CRM is primarily a workflow and communication tool: it manages guest communications, marketing campaigns, and feedback loops. Identity resolution is the data infrastructure that makes a CRM useful. Without resolved profiles, a CRM operates on fragmented, duplicated data and its outputs are only as reliable as the underlying records. The two are complementary rather than competing; resolution sits below the CRM in the stack and feeds it clean data.
Can we just clean the data manually?
Manual deduplication is feasible at small scale, but it does not hold. New records arrive every day from OTA bookings, new direct bookings, and in-property transactions. A one-time cleanup reverts to fragmentation within weeks unless an automated process maintains the Master Profile continuously.
How long does identity resolution take to implement?
Connecting a first set of source systems (PMS, booking engine and POS) is most of the work, and a first group is typically live in three weeks rather than the six months a bespoke build runs to, because the resolution logic already exists and the work is mapping data formats between systems. Once the record is live, your agents read a profile that is already resolved. Rolling out across more properties and multiple PMS instances takes longer, particularly when historical data needs retrospective matching across years of accumulated records.
What about GDPR and data minimisation?
Identity resolution does not conflict with GDPR by default. The resolved profile sits within your own data environment; you control both the data and the processing. You will need a lawful basis for processing, typically legitimate interest or performance of a contract, and your privacy notice should accurately describe the data you hold and how you use it. The risk profile is quite different from sharing guest data with a third party or a channel.
Does identity resolution reduce OTA dependence?
Reduced OTA reliance is a secondary benefit; the primary gain is AI-enablement. A resolved guest record every agent can read gives each one the ground truth it needs to act, rather than a partial view rented from a channel or assembled inside one vendor's suite. Because the group understands its own guests directly, it depends less on OTA data and can segment more accurately for the campaigns it does run.