Guest profiles in hotels: what to record for repeat guests, and what never to record

A hotel guest profile is a record of a returning guest's stay history and stated preferences, kept as personal data under Türkiye's KVKK (Law No. 6698). Keep only fields with a stated purpose, never record health, religion or opinions, limit who reads the profile, set a retention period, and answer the guest when they ask what you hold.

A guest checks in for the third time and the desk asks, again, whether it is their first stay. The fix looks like a profile. The catch is that a profile is personal data, and most hotel profiles carry fields nobody can justify. After reading this you will know which fields to keep, which to refuse, how to merge duplicates, who reads what and when, and how to answer a guest who asks what you hold about them.

What is a hotel guest profile, and what does recognition actually require?#

A guest profile is a record tied to one person that holds their stay history and the preferences they have stated. Recognition is what the desk and the room do with it, and it needs three things, only the first of which is a database field.

Start by separating the two records. A reservation is a contract for dates and a room; a profile is the memory that survives across stays. Confusing them is why some hotels have excellent reservation data and no recognition at all.

The profile is personal data under the Personal Data Protection Law (KVKK, Law No. 6698, Official Gazette 7 April 2016, No. 29677), so it needs a purpose, a minimum field set, a retention period and limited access. Article 4 requires processing for specified, explicit and legitimate purposes, and data that is relevant, limited and proportionate to those purposes, as the consolidated text of Law No. 6698 on the Mevzuat Bilgi Sistemi (2026-11-02) states. A profile built in case it is useful fails this test on its own.

Article 10 requires the hotel to inform the guest when the data is collected: who the controller is, the purpose, to whom data may be transferred, the method and legal basis of collection, and the guest's rights. This is not paperwork after the fact; it shapes what you may collect in the first place.

The trade-off is real. A thin profile that staff actually read beats a rich one nobody maintains, and every extra field costs maintenance time and legal exposure. Recognition is also not the same mechanism as a points program: points buy a repeat stay with a reward, recognition buys it with memory, and memory is what the profile holds. We cover that distinction in loyalty programs for independent hotels: points, perks or recognition.

Which fields are worth keeping in a guest profile?#

Keep the fields that change what happens at the next stay, and drop the rest. Each item on the list below passes one test: somebody will act on it before or during arrival.

Contact and language come first: full name as written on the identity document at check-in, one phone number, one email address, preferred language of correspondence. Identity itself is checked in person at the desk; the profile holds the contact route, not a document image.

Stay history makes recognition possible: arrival and departure dates, room number and room type, number of nights, and how the booking came in (direct, agency, online travel agency, walk-in). This is what makes a duplicate visible and what lets the desk say welcome back with confidence.

Then come preferences the guest actually stated: floor, bed type, pillow, quiet room, away from the elevator. Record the preference, not your interpretation of it. Service preferences belong in the same group: late check-out habit, breakfast time, a preferred greeting form, a preferred newspaper. Only what the guest said out loud or wrote down.

Contact rules protect the stay and cost almost nothing to keep: do not call the room after a certain hour, confirm by email rather than by phone. Resolved complaints are the last field worth having: what went wrong, what fixed it, and what to do differently next time, one line written by the person who resolved it, with a date.

What to leave out even here: free-text note boxes with no owner and no review date. If the field has no owner, it will eventually hold something the hotel cannot defend.

Which guest details should never be recorded?#

Never record special categories of personal data, opinions about the guest, or anything the hotel cannot explain a purpose for. A dietary or medical note collected before arrival may reveal health or religious information, which can make it a special category under KVKK. Treat such notes with caution, and confirm with a legal adviser how to handle them.

Article 6 of Law No. 6698 treats data on a person's health, religion or other beliefs, dress, and biometric and genetic data, among others, as special categories whose processing is prohibited except in the cases the law lists, such as the person's explicit consent, as the Mevzuat Bilgi Sistemi's text of Law No. 6698, Article 6 (2026-11-01) (opens in a new tab) sets out. The practical consequence is uncomfortable: nut allergy, diabetic, does not drink, fasts in a particular month, vegan for religious reasons. These are not neutral preferences. If the kitchen needs the information for one stay, keep it as a short-lived service note tied to that reservation, with the guest's knowledge, and let it expire.

Opinions and judgments are the second problem: difficult, complainer, big tipper, do not upgrade. These are personal data about the guest, they are indefensible if the guest asks what the hotel holds, and they quietly steer decisions the guest never sees.

Free-text boxes are where both problems start: no owner, no review date, no purpose. If a free-text field exists, write down what may go into it and who reviews it. Document images do not belong in the profile either; identity is checked in person at the desk and handled under the hotel's own procedure, not stored as a picture attached to a preference record.

Do not store conclusions. Derived data such as travels with family or likely to book the spa is still personal data, and it is the hardest kind to explain on request. The rule of thumb: if you cannot explain the field to the guest in one sentence at the desk, the field should not exist.

How do you merge duplicate guest profiles?#

Match on an identifier the guest confirms, merge into the older record, and log the merge. Never merge on a name match alone.

Duplicates come from channels, not from careless staff: a direct booking, an agency booking with a different spelling, an online travel agency booking with a masked email address, a walk-in. Each one creates a new record if nobody searches first. The check before creating a record: search by phone and email before searching by name. A name search returns too many rows to be a decision.

For the merge itself, keep the older record's stay history, take the newer record's contact details, keep the earliest creation date, and note which record absorbed which. A merge is a data operation: log who merged, when, and what moved, so the change can be undone and explained later.

Test the merge by opening the profile and reading the last three stays. If the guest can still be asked whether it is their first visit, the merge did not work. Set a rhythm for this work: a monthly duplicate report reviewed by reservations, not a cleanup project once a year.

Who reads the profile, and at which moment?#

Three moments matter: reservations at booking, the desk before arrival and at check-in, and housekeeping before the room is prepared. Each needs a different slice of the profile, not the whole file.

Reservations reads contact rules and stay history, and checks for a duplicate before saving anything new. The desk, the day before arrival, reads one line: what to do differently this stay. Put that line at the top of the profile and hold it to one sentence.

The desk, at arrival, uses the name and the greeting form, and confirms the preference rather than announcing it: we have you on a high floor again, is that still right. Confirming also catches a preference that has gone stale.

Housekeeping receives the room-setup fields only: pillow, bed, floor, extra items. Never the guest's history or complaint notes. A printed housekeeping list carrying complaint notes is a data leak on a trolley.

Access by role: front office, reservations and guest relations see the profile; housekeeping sees the setup fields; everyone else sees nothing. Review the access list when staff leave. The test of the whole system is simple: the guest does not have to repeat themselves. If they do, the profile failed at the reading stage, not the writing stage. Pair the profile with a request log, so that what the guest asked for during the stay is closed and visible, not buried in a note; see hotel guest request management: log, assign and close each one.

How long do you keep a profile, and what do you tell the guest?#

Keep it only for the period the relevant legislation or the purpose requires, then erase, destroy or anonymize it. Tell the guest at collection, and answer when they ask what you hold.

The law sets a rule rather than a number of years: personal data is kept only for the period set by the relevant legislation or needed for the purpose, and the controller erases, destroys or anonymizes it once the reason for processing no longer exists, on its own initiative or at the person's request, as the consolidated text of Law No. 6698, Articles 4(2)(d) and 7 (2024-06-01) (opens in a new tab) requires. Two clocks run in parallel: fiscal and identity records have their own statutory periods; the preference profile does not inherit them. Do not let the longest clock set the profile's life.

Write the period down per field group, with your legal adviser, and put a review date on it. Forever is not a retention policy. Decide in advance what happens to a dormant profile after a set number of years without a stay: deleting is a decision, and keeping by default is also a decision, just an unexamined one.

The information notice at collection must cover the controller's identity, the purpose, to whom data may be transferred, the method and legal basis of collection, and the rights the person holds under Article 11. When a guest asks what you hold, Article 11 gives them the right to ask whether their data is processed, to request information, correction or erasure, and to object to an outcome against them produced solely by automated analysis, per the Mevzuat Bilgi Sistemi's consolidated text, Article 11 (2024-06-01) (opens in a new tab). Answer from the profile itself, not from memory. Confirm the response window, the written form of the answer and the escalation path with your adviser; this article's job is the procedure, not the deadline. For the wider setup, see KVKK for hotels: notices, consent, staff access and retention and guest data requests under KVKK: a front office procedure.

What to do next#

Open your current profile screen, list every field, and write the one sentence you would say to a guest explaining why that field is there. Fields you cannot finish the sentence for should be deleted, or moved into a short-lived service note tied to a single reservation. Do this before adding anything new: the profile that survives is the one staff read, and the one a guest can be shown without embarrassment.