The same guest may be recorded by name on one reservation, under a different email from another channel, and again with passport details at reception. Over time, one person's stay history, preferences, communication permissions, billing details and loyalty records become scattered across profiles. Staff may choose the wrong profile, fail to recognize the guest or create unnecessary copies of personal data. Reliable profile management matches before creating a new record, sends ambiguous candidates for human review, explains which fields will survive a merge and records every change in an auditable way.

What you will learn in this article
  • Similar names alone do not prove two profiles represent the same person; channel IDs, membership numbers, verified contact details and document numbers should be assessed together.
  • High-confidence matches and candidates requiring human review should use separate thresholds, while risky profiles must be excluded from automatic merging.
  • Merging is more than copying fields; it must preserve reservations, folios, preferences, permissions and audit history while applying data-protection rules for access and retention.

Make the operational impact of duplicate profiles visible

A duplicate profile is two or more PMS records representing the same real person. The problem is not simply the number of database records. If a VIP note is on one profile, the latest stay on another and the correct phone number on a third, reception cannot see the guest's complete history. Revenue and CRM reports may count one person as several guests, distorting segmentation, repeat-stay and campaign metrics. Conflicting communication preferences across profiles also increase the risk of messaging the wrong person.

Start with metrics that make the impact measurable: potential duplicates, profiles created per new reservation, manual merge rate, incorrect merge cases and records created because an existing profile could not be found. The goal is not the lowest possible profile count but matching the right person to the right history. Overly aggressive cleanup can combine two different guests in one record and create a more serious problem than duplication.

  • Potential duplicates, confirmed duplicates and false matches were counted separately.
  • The new-profile creation rate was tracked by reservation source.
  • The effect of split profiles on loyalty, revenue and communication reports was measured.
  • The objective was defined as an accurate, current guest view rather than fewer records.

Search existing records before creating a new profile

The safest cleanup starts by preventing new duplicates instead of merging them after creation. When a reservation channel or central system supplies a trustworthy external profile ID, store it as the primary matching key. Oracle OPERA Cloud documents using profile-matching rules to associate data from integrated systems with existing records, while weighted matching may be unnecessary when systems share a reliable internal ID.

The reception screen should run a quick search before offering a new-profile action. Alongside the name, show distinguishing fields such as the final phone digits, masked email, birth year, nationality and latest stay date. A new record can be created when there is no result; when several candidates exist, the system must not silently choose one without user selection. Lead guests and accompanying guests must also remain distinct in group or agency bookings.

  • The external profile ID was stored as an immutable match together with its source.
  • Quick search and a potential-match warning were required before creating a record.
  • Distinguishing details appeared in search results in masked, comparable form.
  • Lead guest, accompanying guest, company and agency profile types were handled separately.

Use weighted matching rules instead of a single field

First and last names can vary because of Turkish characters, middle names, a name change, typing errors or a channel's use of uppercase. Phone numbers may arrive with or without a country code and email addresses may be mistyped. Name equality alone is therefore insufficient for automatic merging. OPERA's matching documentation shows that rules and weighted points can be configured for fields such as membership number, passport number, email, phone, address and city.

Rules should be tuned to the data source and profile type. A verified loyalty number can be a strong signal, while a shared family phone is weak on its own. When document numbers are used, compare document type and country as well, and prevent old or masked values from producing false matches. The normalization performed by each rule must be explicit: trimming spaces, normalizing country codes, case handling and Turkish-character conversion should not be a hidden black box.

  • Each matching field received a score based on its reliability.
  • Phone numbers, emails and names were normalized by defined rules before comparison.
  • Document numbers were evaluated together with document type and country.
  • Shared family contact details were not used alone for automatic merging.

Separate automatic merge and review thresholds

Not every potential match has the same confidence. Records below the low threshold can remain separate, those in the middle range can enter a review list, and only high-confidence candidates with several strong fields verified together should enter automatic processing. Oracle's profile merge rules similarly define lower and upper thresholds, routing middle scores to manual review and candidates above the upper threshold to a configured automatic process.

Automatic merging should start with a narrow scope. Protected, private, anonymized, different-type or financially active profiles should be excluded. Run a rule change against historical data in report-only mode first, then sample how many correct and incorrect candidates it creates. If the production error rate increases, the rule must be easy to stop without losing pending candidates.

  • Low, review and high-confidence thresholds were defined separately.
  • Protected, anonymized and different-type profiles were excluded from automatic merging.
  • The new rule was measured against historical data in test mode.
  • Rule versions, threshold changes and deactivation were logged.

Choose the primary profile and retained fields before merging

A merge button alone is not enough. Profiles should open side by side with differences in name, contact, address, identity, membership, preference, consent and notes highlighted. The oldest record should not automatically become primary; prefer the profile containing verified, current fields. OPERA Cloud's manual flow supports selecting the primary profile, adding or removing profiles to merge, and reviewing the attributes retained in the resulting profile.

For conflicting fields, show source reliability and the update time. A new phone verified at reception may be more current than one received from a channel years earlier, while an old communication preference must not overwrite a new value without the guest's authorization. The pre-merge summary should clearly show transferred reservation and loyalty links, retained fields and audit records that will remain.

  • The primary profile was suggested with a reason, not forced on the user.
  • Source, verification and update time were shown for conflicting fields.
  • Communication permissions were not overwritten like ordinary phone or email fields.
  • The confirmation screen previewed the resulting profile and transferred relationships.

Preserve reservation, folio and history relationships

A profile merge affects not only text fields but every relationship linked to the profile. Past and future reservations, stay statistics, preferences, memberships, comments, invoice links and accounts receivable must remain consistent with the resulting profile. Oracle documents that reservation history, statistics and profile details are updated and, where appropriate, accounts from several profiles can be combined in the resulting profile. The process must therefore not run before its financial effects are checked.

Old profile IDs should not be forgotten entirely. Keep an alias or redirect so a message arriving from an external system under an old ID resolves to the resulting profile, without appearing to users as two active profiles. After merging, check a sample reservation, open folio, invoice recipient, loyalty points and guest preferences, then verify that the next channel update does not create the duplicate again.

  • Past and future reservation links were verified on the resulting profile.
  • Open folio, invoice-recipient and accounts-receivable effects were checked before processing.
  • Old profile IDs were retained as redirects for integration matching.
  • Tests confirmed that a new channel update did not recreate the duplicate after merging.

Manage accuracy, access and disposal together for data protection

Merging profiles is a processing activity that reorganizes personal data. The general principles of Turkey's data-protection law require data to be accurate and current where necessary, processed for specified, explicit and legitimate purposes in a relevant, limited and proportionate way, and retained only as long as needed. Reducing duplicates may improve accuracy, but merging different people creates new risks for both accuracy and unauthorized access.

Merge permissions should be role-based, sensitive fields masked and activity logs retained, including views. The Turkish Data Protection Authority's security guidance calls for appropriate technical and organizational measures to prevent unlawful processing and access and to safeguard data. Fields whose retention purpose has ended must not remain forever merely because they moved from a duplicate profile. The deletion, destruction or anonymization policy must also apply to the resulting profile, and an anonymized record must never be merged back into an identifiable personal profile.

  • Profile-merge permission was limited by job role and a second-approval rule.
  • Unnecessary sensitive fields were masked on the comparison screen.
  • Retention and disposal periods were reassessed after merging.
  • An anonymized profile was not relinked to an active personal record.

Log every merge and prepare a correction plan

Merge history should show the user, time, primary and source profile IDs, match reason, rule version and retained fields. Oracle's Changes Log can track activities such as profile creation and updates with the user, date, time, activity type and change description. The hotel should likewise distinguish automatic actions under a service-account name from manual actions by a real user.

In many systems a merge may not be reversible with a simple undo button. Instead of promising an undo, prepare a correction procedure: create accurate profiles, let authorized staff separate incorrectly transferred relationships, update affected integrations and assess whether the data-security incident process is required. Monthly quality checks should track incorrect merges, age of pending candidates, accuracy by rule and the rate at which duplicates reappear.

  • Primary and source profile IDs were stored together in the change log.
  • Automatic and manual actions were distinguished by different user types.
  • A data and integration correction procedure was documented for incorrect merges.
  • Match accuracy, pending candidates and duplicate recurrence were reported regularly.
Short answers

FAQ

Should guest profiles with the same name be merged automatically?

No. Name similarity is only a supporting signal because different people can share a name. Several strong fields such as a verified external ID, membership number, contact details or document information should be evaluated together.

Is reservation history deleted when guest profiles are merged?

A well-designed process does not delete history; reservations, statistics and related records move or link to the resulting profile. Open folios, invoices, accounts receivable, memberships and integration IDs require separate checks.

Can an incorrectly merged guest profile be undone?

It depends on the PMS architecture, and not every system offers one-step undo. That makes pre-merge review, detailed logging and a correction procedure for authorized staff to separate incorrect relationships essential.

Sources and updates

Operational recommendations should be adapted to the property's own conditions. Information about PMS and channel workflows was checked against the official documents below on 26 September 2026.