A guest checks in for the fourth time in two years. The front desk greets them like it is the first visit, because on the screen it is. There is no stay history attached to the record, no note about the room they always ask for, no flag that they book direct every time. Somewhere else in the same database sit three other versions of this person, each holding a piece of the story.
Nobody escalates this. No report turns red. The guest does not complain, they just notice that a place they have chosen four times does not seem to know them. Then they book the next stay wherever is cheapest, because you gave them no reason not to.
Duplicates are created, not inherited
The assumption is usually that bad data arrived from somewhere. A messy import, a previous system, a staff member who did not care. Occasionally that is true. Far more often the property is generating duplicates every week through completely normal operations, and has been for years.
Here is where they come from in practice.
Every channel writes its own record
A booking through an OTA arrives with a masked or aliased email address. The same person booking direct arrives with their real one. The system has no reason to connect those two records, so it does not. Book once through each of three channels and you have three guests.
Nobody searches before they create
A phone reservation comes in at a busy moment. Creating a new profile takes four seconds. Searching properly for an existing one takes thirty, and only works if you guess the spelling. Under pressure, staff create. This is not a training failure so much as a design failure, because the system made creating easier than finding.
The matching rule is set too tight
Most systems will merge on an exact email match and nothing else. Real guests do not cooperate with that. They book with a work address one trip and a personal one the next. They change jobs. They use a partner's account. Every one of those is a new person as far as the matching rule is concerned.
Migration multiplies whatever you already had
This is the one I see cause the most damage, because it turns a slow problem into a sudden one. When a property moves between systems, guest records get loaded in bulk. If the duplicates were not resolved beforehand, they do not just carry over. They frequently multiply, because the load creates fresh records wherever the new system cannot confidently match against the old.
That backlog is the clearest example I have of what unresolved data actually costs. Nobody at that property was careless. The records had simply drifted for years, and once they drifted far enough, the work of matching them became large enough that nobody wanted to start.
What it actually costs you
The frustrating part is that none of these show up as a line item. They show up as things that never happened.
- You pay commission to re-acquire guests you already have. A returning guest sitting in your database as a first timer never enters a win-back segment. They see your OTA listing instead of your email, and you pay to bring back someone who was already yours.
- Recognition fails at exactly the wrong moment. The value of a fourth stay is that you can act on the first three. Split across four records, nobody can.
- Your repeat rate is wrong, and so is everything built on it. If a quarter of your returning guests are counted as new, your direct booking performance looks worse than it is and your acquisition cost looks better. You then make budget decisions on both.
- Marketing gets blamed. Campaign performance looks soft because the segments underneath it are wrong. The response is usually to change the campaign, which does nothing, because the problem was never the campaign.
- Guests get contacted more than once. Three records means three copies of the same pre-arrival email, which reads as sloppy from a property selling attention to detail.
A duplicate is not a data problem until someone tries to make a decision with it. Then it is every problem at once.
Fixing the records is the easy half
Deduplication is a solved problem. Any competent operator can merge records over a few sessions. The reason properties do it twice in three years is that merging treats the symptom and leaves the cause running.
If you are going to do this once, do it in this order.
- Measure before you touch anything. Count records, count unique email addresses, count unique phone numbers. The gap between those numbers is your real duplicate rate. Do this first or you will never know whether the work helped.
- Decide what makes two records the same person. Email alone is too tight. Name alone is far too loose. Something like surname plus phone, or surname plus card token, catches most real matches without merging two different people who share a common name. Write the rule down before you apply it.
- Fix the intake path. Make searching faster than creating. Require phone number at booking. Map the fields your OTA connection writes into so channel bookings land in the same shape as direct ones. If you skip this step, you are scheduling the same cleanup for next year.
- Merge, and keep an audit trail. Merges are difficult to reverse. Export before you start and record what was combined.
- Set a hygiene rhythm. Twenty minutes a week catching new duplicates while there are five of them, rather than a full project once there are four thousand.
None of this requires new software. Most properties already own the tools. What is usually missing is a written matching rule and an owner, and the absence of those two things is why the same cleanup gets paid for repeatedly.
If a migration is anywhere on your calendar
Do this before, not after. A migration is the single worst moment to discover your duplicate rate, because the implementation timeline is already set and nobody has budgeted days for reconciliation. Cleaning first also shrinks the load, which shortens the cutover.
The property that resolves duplicates two months ahead of a system change spends a week on it. The property that discovers the problem during data load spends a month, and does it while running a hotel.
Where to start this week
Pull a guest list export. Count total records, then count unique email addresses. If the second number is meaningfully smaller than the first, you have your answer and you did not need a consultant to find it.
Then take one specific guest you know has stayed several times and search for them properly. Try the surname on its own. Most of the time, the picture becomes very clear very quickly.