One guest record: the discipline behind recognition

Why do hotels end up with duplicate profiles?

Profiles are created wherever a guest first appears: the desk, a channel booking, a restaurant reservation, a corporate assistant’s email. If the creation form does not search existing records, a new profile is the path of least resistance.

Channel bookings are a common source. The OTA sends a name and a phone number; the PMS creates a record; the guest later books direct with an email address. Now there are two profiles and no shared identifier.

The fix is not a periodic cleanup. It is a match rule at the point of creation, a visible “possible duplicate” prompt, and a merge process that someone owns.

What belongs in a guest profile?

A profile should be the minimum needed to recognise and serve the guest, plus the history that makes recognition useful. Everything else belongs somewhere with a narrower purpose.

• Identity: name, contact details, preferred language, identity document reference where lawful
• Consent: marketing preferences, communication channel, consent date and source
• Preferences: room, floor, pillow, dietary, accessibility and service notes
• History: stays, outlets visited, spend patterns, complaints resolved
• Commercial: membership tier, corporate account, negotiated rates
• Sensitive notes: restricted to named roles, with access logged

If a field has no owner and no use, it is a liability. Collect less, and keep what you collect current.

How should duplicates be merged?

A merge is a data operation with financial consequences: points, stored value, folio history and negotiated rates may all be attached to either record. It should never be a one-click guess.

A workable process is: candidate detection with a match score, human review of the evidence, a merge preview showing what will be kept, a merge action that preserves both histories, and a log that allows an authorised user to understand what happened.

• Never merge automatically on name alone.
• Preserve both stay histories and the earlier creation date.
• Reconcile points and stored value explicitly, with a report.
• Log the merge, the user, the source records and the resulting record.

Who should be allowed to see what?

A front desk needs enough to greet and serve. Sales needs commercial history. Finance needs billing and credit. Marketing needs consent and segmentation. None of them need the same view.

Role-based access should be narrow by default. Sensitive notes, complaint history and payment details should be permissioned separately from the basic profile, and access should be logged.

How do you keep profiles from decaying?

Guest data ages quickly. Email addresses change, preferences shift, consent expires. A profile that is not refreshed becomes a source of wrong assumptions.

Capture at the point of service is the only sustainable method: confirm contact details at check-in, note a preference when the guest expresses it, record consent when it is given, and review the profile at each stay rather than in an annual campaign.

• Prompt for confirmation of email and phone at check-in
• Capture preferences as structured fields, not free-text novels
• Record consent source and date, and honour withdrawal
• Review dormant profiles on a defined cycle

What should you measure?

Measure the things that change behaviour, not the size of the database.

• Duplicate rate: profiles merged per hundred new profiles created
• Profile completeness: percentage with a verified contact and consent
• Recognition rate: repeat guests whose profile was used at check-in
• Outlet attach: share of in-house guests with an outlet charge
• Complaint resolution: repeat complaints from the same guest

How should guest records change with property size?

In a 10–60 room property, recognition usually lives in the heads of a small team. Staff know the repeat guest, the preferred room and the complaint from last spring, but that knowledge is not in the system and leaves when the person does. The design task is to capture the few things the team will actually maintain: a verified phone and email, language, a structured room or floor preference, dietary needs and consent. A long free-text notes field is where good intentions go to die. Profile creation happens at the desk and through OTA bookings, so the search-before-create rule matters even here; two profiles for one guest are as easy to produce in a 40-room property as in a 400-room one. One person, usually the front office lead or the owner, should own merges and review them. The aim is not a marketing database. It is enough continuity that a returning guest is not asked the same questions twice, and enough discipline that the record is still accurate at the next stay.

Between 60 and 250 rooms, the guest is served by more people in more places. The desk, reservations, the restaurant, the spa and the sales office all touch the record, and each needs a different view of it. That is when role-based access stops being a formality: a restaurant host needs the allergy note, not the credit limit, and the sales office needs the corporate rate, not the complaint history. Interfaces also start to matter. If the POS and the PMS hold separate guest records, recognition at the outlet depends on someone re-keying a name. The property should decide which system is the operational source of truth and sync a governed subset outward, rather than letting each department keep its own list. Consent deserves the same discipline: channel, date and source recorded per guest, with withdrawal honoured everywhere it was shared. A named owner for duplicate merges and a 30-day review of the duplicate rate will do more than an annual cleanup campaign. The review should look at merged records, not only the count.

Above 250 rooms and in resorts, the record has to work across outlets, buildings and sometimes properties. A guest may stay in one hotel, dine in another and book a spa under a membership number, and the group wants that recognised without exposing the whole profile to every user. Identity matching, merge governance and access rules become central functions, not desk habits. The field model should be owned centrally and kept narrow, because every optional field added at group level becomes a maintenance obligation at every property. Retention rules also multiply: a jurisdiction may require identity data to be deleted on a schedule while financial records are kept longer, and sensitive notes need separate permissioning and access logging. The measure of success is not database size. It is whether the profile changes what the team does at check-in or in the outlet, and whether the guest sees continuity rather than being treated as new. The property should also be able to see which fields the centre actually uses, because unused fields are cost without benefit.

Decide the boundaries before choosing fields. First, what the record is for: service continuity, commercial history or marketing, because each purpose justifies different data and different retention. Second, the source of truth for identity and stay history, and which systems receive a subset. Third, who may see sensitive notes, and how access is logged. Fourth, the consent model, including how withdrawal propagates to every system that received the data. Fifth, the merge policy: who reviews candidates, what evidence is required and how the audit trail is kept. Then set the minimum field set that the team will maintain at the point of service, and resist the urge to add fields because they might be useful. If the answer to any of these is unclear, the field set is probably too broad for the first release. The boundary condition is legal: retention, cross-border transfer and identity-document rules vary by jurisdiction, and a group standard has to leave room for a local obligation. A profile that cannot be lawfully kept is not an asset.

• Which fields will the team maintain at the point of service?
• Which system is the source of truth for identity and stay history?
• Who reviews duplicate candidates, and what evidence is required?
• How does a consent withdrawal reach every system that holds the data?
• Which data must be deleted or kept under local law?