Duplicate guest profiles in the PMS: why they appear, how to merge them and what to keep

A duplicate guest profile is a second record for a person the hotel already has. Duplicate guest profiles in the PMS appear when names are typed differently, when channel vouchers arrive in another format, and when the desk creates instead of searching. Merge by comparing document number, date of birth and contact details, moving the history, and logging the decision.

A guest walks up to the desk for her third stay this year and is greeted as a first-time visitor, because her two earlier stays sit under two other spellings of her name. The history that would have told the desk who she is was never lost; it was split. This article explains how duplicates appear, the entry rules that prevent most of them, a safe merge routine with a named owner, and what must survive the merge.

How does one guest become three records in the PMS?#

Most duplicates are made at the keyboard, not by the software: the same person is typed differently each time a reservation is created, and each channel adds its own version.

Case and characters split records first. "MEHMET YILMAZ", "Mehmet Yilmaz" and "Mehmet Yılmaz" are three different strings to a database, and a dotless ı typed as a plain i is enough to hide a guest from a search. Name order and titles do the same: "Yılmaz Mehmet", "Mr Mehmet Yilmaz", or a middle name entered once and dropped the next time.

Channel records arrive in someone else's format. An agency voucher or an online reservation carries its own name order and is often cut to the field length the channel allows, and the desk accepts it as a new profile. Quick entry under pressure finishes the job: at two in the morning it is faster to type a surname and press create than to search first. Shared or malformed contact details add a quieter cause, one e-mail used by a family or a company, or a phone number typed without the country code, so the search that should have found the guest returns nothing. Group and rooming lists create one record per room from a list that spells names its own way, which is why sending rooming lists and guest lists without creating a second record deserves its own procedure.

The cost is not the extra row. Stay history, preferences and consent records end up in different places, and the guest is treated as new.

For example, one guest may sit in the system like this:

Three records, one person, and no single one of them tells the truth about him.

Which entry rules stop most duplicates before they exist?#

One written rule for names, one for contact details and one habit, search before you create, prevent more duplicates than any cleanup can remove.

Decide the name format once: a surname field and a given-name field, no titles inside them, no middle name in the surname field, Turkish characters written properly. Put it in the front-office procedure and in new-staff training. Then search before create, and search on a number rather than a name: phone, document number or e-mail. A name search returns too many rows to be useful, which is exactly why people stop doing it.

Keep one mobile number in one format, with country code and no spaces; one e-mail per person where possible, and never overwrite a personal address with a shared one. For vouchers and channel reservations, match the incoming name against existing records by surname plus arrival date, then attach the reservation to the profile you found. If you are unsure, put the reservation on a temporary record and merge after departure. Keep group lists as received, but enter the guests from them into existing profiles rather than letting the list create the record. What you record on the profile matters as much as how you create it: see what to record for repeat guests, and what never to record.

Write the rule where people see it. A one-page sheet taped at the desk works better than a policy in a folder nobody opens.

What should you compare before merging two records?#

Compare identity, not names: a merge is safe only when at least two independent fields agree and nothing contradicts.

The fields that identify a person are document type and number, date of birth, mobile number, e-mail, nationality and address. Two of these agreeing is a working threshold; one is not. A name is not evidence. Common names repeat, fathers and sons share a name, and transliteration can make two different people look identical on screen.

Run the contradiction test: two stays on the same night in two different rooms means two people, not one guest with two records. Watch shared contact details, because a family e-mail or a company phone can make two different guests look like one person. Check the document type too: an identity card number and a passport number are different identifiers and can both belong to the same person, so a mismatch there is not proof of two people. When the evidence is thin, do not merge. Link the two records with a note and let the next stay settle it; a wrong merge costs more than a duplicate.

What is a safe merge routine, and who may do it?#

Merge in a fixed order: choose the surviving record, move the parts, close the other with a pointer, and write down who did it and why.

Choose the survivor by evidence, not by age: the record with the verified document number and the longest history, not the most recently created one. Move, do not copy: stays, notes, preferences and open items move to the survivor, and nothing is duplicated, or the merge has simply created a new problem. Close, do not delete: the losing record keeps its identifier and a pointer to the survivor, so an old voucher number, invoice reference or e-mail still resolves to a person.

Two pairs of eyes for the risky ones: any merge that touches an open balance, a consent record or a document number gets a second check by a named person. Name who may do it: a front-office manager and a deputy, working under their own logins. Not every user, and never a shared login, because the log is only worth something if it names a person. Record the merge: date, both record identifiers, the fields you compared, the evidence, and the person who decided. That entry is what lets you reverse a wrong merge. Note what each record contained before the merge, so the reversal is a restore and not a guess.

What must you keep when two records become one?#

Keep everything that proves what happened and what the guest agreed to; stay history, the consent trail and documents already issued are not the hotel's to discard at merge time.

Stay history moves to the survivor: nights, rate, room and spend, so the guest's value and pattern are visible at the next check-in. When the two records disagree on preferences, keep the most recently stated one and note its date; do not average them and do not guess which is true. Each consent record is tied to a date, a purpose and a text. Keep both, and make sure the surviving record shows a consent that covers the processing that continues; if it does not, ask the guest again.

An open guest bill is settled or transferred deliberately, with a note. It is never merged silently, and a closed bill stays with its own record. Documents already issued, including invoices, e-invoices and guest identity notifications, stay exactly as they were sent; a merge does not rewrite a document. Notes and complaints keep their substance, lose the duplicates, and keep a date on every note carried over.

How do you run a quarterly cleanup without creating new problems?#

Work from a list the system produces, not from memory: exact matches on phone, e-mail and document number first, then near matches on surname plus first initial.

Build the list on a fixed date each quarter, so the cleanup is a routine and not a reaction to a bad arrival. Sort by last stay date: recent duplicates matter most, because they affect the next arrival, and a pair that has not stayed since 2019 can wait. Cap the session at twenty to thirty merges per person. Attention drops after that, and a careless merge is worse than a duplicate.

Give the list one owner and one checker, and log every merge in the same file, so the quarter's work is auditable in one place. Measure two numbers: how many duplicate records you closed, and how many new ones appeared since the last cleanup. The second number tells you whether the entry rules are working. Feed the cause back: if most new duplicates come from one channel or one shift, fix the matching rule or the training there, not only the records. Do not turn the cleanup into a data project; it is a maintenance task with a start and an end, and it sits inside the broader task of cleaning hotel data before any AI project.

What does a merge change for privacy and retention?#

A merge concentrates more data about one person in one place, so the retention clock and the consent trail have to be handled deliberately.

Retention runs from the last stay, not from the merge date. Merging two old records must not extend how long the hotel keeps them. At destruction time the merged record goes as one, and the pointer left on the closed record must not keep personal data alive in the system. A guest asking what the hotel holds about them should get one answer: a merge makes that easier, a duplicate makes it wrong.

Merging does not create a new legal basis for processing. The surviving record must show a consent that covers the processing that continues, and if it does not, the guest is asked again. Sensitive notes about health, religion or similar should not exist at all; if they do, a merge is the moment to remove them, not to consolidate them. Your own retention periods and destruction duties depend on your registration and scale, so confirm them with a legal adviser rather than copying another hotel's table. For the underlying schedule, see building a retention and destruction table for guest records.

What to do next#

Write the one-page entry rule this week and put the first duplicate list on the calendar for this quarter. The parts fit together in that order: prevention at the keyboard, evidence before a merge, a fixed routine with a named person, a log that allows a reversal, and a retention clock that follows the guest's last stay rather than the day you tidied the database.