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.
Frequently asked questions
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.