Maintain guest profiles without duplicates

Find the guest before creating a record

Open Guests → Guest list and combine the name with birth date, email, phone or booking number. One similar name is not a reliable match.

Open the best match and compare stays, room category, companions or company before changing anything. Do not merge family members merely because they share an address.

Search before creating. Use a combination of full name and birth date, email, phone, booking number or prior stay, then open the most plausible profile and compare its history. A name alone is weak evidence, especially for families, companies and common names. Treat formatting differences in phone or email as a reason to inspect, not automatic proof of a second person. If no candidate is reliable, create a new profile from current verified information. Do not use a customer hotel account or a familiar demo guest as convenient documentation data; examples and screenshots belong only in the isolated Hotel Nordlicht demo. The search is complete when the team can state which facts prove the selected profile belongs to this person or why a separate record is necessary.

Decide duplicate suggestions correctly

STRYK can flag potential duplicates during creation or editing. Use the existing profile only when the new stay clearly belongs to that person.

Update an existing profile only when the new information is verified and current. Conflicting data should be clarified rather than merged.

Treat the duplicate suggestion as a decision, not a cleanup shortcut. Use existing when several attributes prove the same person and stored details remain correct. Update existing only when identity is equally reliable and the guest has confirmed a newer email, phone, address or other field. Create separately when details are similar but identity is uncertain, such as two relatives sharing an address or two guests with the same name. Before accepting an update, list the exact fields that will change and preserve every unrelated verified value. After the decision, reopen the profile and booking: the new stay should appear once on the intended person, prior stays should remain appropriate and no unrelated booking may be attached. A wrong merge is more damaging than a visible, assigned duplicate investigation.

Maintain complete but minimal master data

Maintain names and verified contacts for operations. Birth date, nationality, address and document details depend on the configured check-in requirements and should not be collected speculatively.

Internal notes need a specific operating purpose and neutral wording. Guest photos appear only when the hotel photo mode is enabled and use protected access.

Maintain enough master data for the real operating and legal purpose, but no more. Verify spelling, salutation where used, email, phone, birth date, address and nationality from the guest or approved source. Distinguish unknown from not applicable and never fill an empty required-looking field with guessed values. Use the dedicated photo control only when hotel settings and purpose permit it; authenticated display, upload or camera capture belongs in the product, not an unprotected link. Internal notes should be factual, current and necessary for service, not subjective labels or a hidden archive of document data. Record the source or confirmation time for important changes according to hotel practice. Data quality means the next authorised colleague can use the profile safely, while an unrelated role cannot infer more about the guest than the stay requires.

Review stay history and booking links

Review current, upcoming and past stays. The main guest is not automatically every accompanying person; correct missing links in the booking rather than documenting them as notes.

After a duplicate decision, look for any stay that clearly cannot belong to the person. Company, private and group bookings need the correct contact; finance and POS data are permission-controlled.

Review booking relationships as part of identity. Open previous and upcoming stays and compare names, dates, company context, companions and contact history. A correct profile can legitimately contain several stays, but every stay must belong to the same person. When a guest supplies a new email, confirm identity using stable facts before updating the profile, then verify both the earlier and new booking still appear together. If an unrelated stay is present, stop communication and check-in actions that could expose another guest’s data, record the affected profile and booking numbers and escalate through the approved correction process. Do not repair a wrong relationship by copying details into a new shadow profile. The source profile and booking links must be corrected so reporting, messages, invoices and future duplicate detection all use one truth.

For a profile connection check, make a three-column comparison: stable personal identification facts stored in the profile, the data of the selected reservation and the current confirmation of the guest. At least two independent pieces of data must support your identity before you change your contact information or add a new residence. If the name matches, but the date of birth, phone or residence history contradicts, do not choose the convenient match. Mark the case for investigation and only assign the reservation to a certain person. After the investigation, document which fact was decided, which field changed, and who rechecked the relationship between the profile and the reservation. This prevents a mistaken email update from exposing someone else's messages, account, or check-in information.

Separate contact purpose and consent

Separate stay-related operational messages, legal obligations and voluntary marketing. A booking is not marketing consent, and marketing opt-out does not automatically block necessary stay messages.

Record only the consent decision that can be evidenced. Contact corrections do not automatically change consent, and the product workflow does not replace legal review.

Separate three contact purposes. Operational communication uses the booking relationship to deliver necessary stay information such as arrival details or an open action. Marketing requires the appropriate recorded consent and its own scope; a booking email or successful stay does not create permission for campaigns. Legal retention concerns whether specific records must remain under the hotel’s obligations and is not a marketing justification. Before using contact data, identify purpose, source, authorised role and current validity. Keep opt-in, opt-out and change evidence in the designated setting rather than a note that automation cannot interpret. If consent is absent or withdrawn, stop marketing use while preserving only the data still required for operations or lawful retention. This distinction lets a small hotel serve guests reliably without turning every profile into an uncontrolled address list.

Review deletion and anonymisation by their actual result

Before a privacy action, verify identity, scope, retention duties and approval. A profile linked to a booking is anonymised: personal details, document data, photo and notes are removed while an inactive record remains for booking integrity.

With no booking link, STRYK deletes the profile. Read the returned result, verify it in the guest list or historical stay and record the outcome in the approved privacy log without recreating removed data elsewhere.

Use the privacy action only after verifying requester identity, scope, retention obligations and internal approval. Reopen the exact profile and inspect booking links one final time because they determine the result. With at least one active booking relationship, STRYK anonymises the profile: personal name, contact, birth date, address, nationality, document details, photo and notes are removed, while an inactive anonymous reference preserves booking integrity. With no booking relationship, the guest record is permanently deleted. Read the returned result rather than assuming it. Reload the guest list and, for anonymisation, the historical stay: the stay remains accessible without personal details. For deletion, the profile no longer appears. Record only the outcome in the approved privacy log and never recreate removed values in notes, exports or side lists.

Review the profile across the workflow

Reload the profile, review visible details and stays, then open the affected booking. For messages, use the specific booking conversation rather than a free contact mode.

Hotel Nordlicht reviews person, contacts, stays and privacy state, plus the absence of a second active duplicate. Fix the source record rather than masking inconsistencies with notes.

Approve the saved profile across the workflow. Reopen guest detail, affected booking, check-in context and booking conversation. Core identity and contact details must agree, the intended stays must appear exactly once and no unrelated booking may be linked. If guest photos are disabled, no placeholder should imply a stored photo; when enabled, the authenticated control should display the approved image consistently. Confirm operational messages use the same booking and that check-in guest slots reference the intended profiles. For a privacy action, verify the actual deleted or anonymised result instead of the prior profile. Record the reviewer and any remaining exception with owner and deadline. The profile is complete when reception, booking, check-in, finance and communication use the same verified person without a conflicting spreadsheet, duplicate or hidden copy.

In the monthly profile quality check, look for a recurring pattern, not a mass export of personal data. Investigate the cause of duplicate warnings, missing stable IDs, conflicting availability, and profiles with an unexpected number of unrelated stays. For each result, open the source profile and relevant reservation, then only change verified data. The aim of the indicator is to improve the process: for example, a mandatory search before a new profile, a uniform phone format or a second check for a company group. Do not create a new shadow list with personal data for quality measurement. The success of the repair should be demonstrated by fewer uncertain connections and a more traceable duplication decision in the next sample.

Each sealed sample should be accompanied by a date, verification and source record, but the quality log should not repeat the entire personal data file of the guest.