Guest profile details

Who this is for: anyone who works a guest profile — Front Desk, Manager, Owner. Reading needs frontdesk.guest.read, editing frontdesk.guest.write, and revealing a masked value its own narrower permission. Where: Front Desk → Guests → any guest

A guest profile carries more than a name. It opens on five tabs, one per kind of fact: who they are (Profile), how to reach them (Contacts), what they showed you (Identity documents), how they like to stay (Preferences), and when they have been here (Stays).

Everything except the name is optional. A walk-in at two in the morning gives a name, and Nerve will not stop you creating the profile with nothing else on it.

Title, nationality and source region#

These three sit on the Profile tab, and each one is a choice from a list your organisation controls (see Reference data).

One object, one form, one Save. The three dropdowns are reference lists — rename an entry there and it reads differently here, on every profile at once.

• Title — how the guest is addressed on correspondence and registration cards.
• Nationality — seeded from the ISO country list and used by statutory guest reporting. It is the country on the document, not where the guest lives.
• Source region — the market this booking is counted under. It is deliberately not derived from nationality: a German passport arriving through a Singapore office is Singapore-market business, and only you know that.

Title and nationality are also on the New guest form, because they are what the person in front of the clerk is saying right now. Source region is not — it is a judgement made later, by whoever is looking at where the booking came from.

Catatan

If a guest was filed under a list entry your property has since retired, the profile keeps showing that entry's name. Nothing silently blanks. You can only pick from live entries when you edit.

Contacts#

A guest used to have exactly one email address and one phone number, which is the wrong shape for the guests a hotel actually bills. The Contacts tab holds as many as you need, each tagged with what it is for — mobile, work, billing, emergency, or whatever types your property has defined.

One table, one row per entry — including the profile's original email and phone, which read "On the profile" under Used for. They are the same kind of fact, so they are not kept in a separate block.

One contact per kind is the primary: the address a confirmation goes to, the number the desk calls. Use the star to promote another one; marking a new one primary replaces the current one, so you never have to demote the old one first.

Every value is masked, and revealing one is written to the audit log. A fourth phone number is not less personal than the first.

Identity documents#

Record a passport, KTP, KITAS or whatever else your jurisdiction asks for from the Identity documents tab. Each one carries a type, the number, an optional issuing country and an optional expiry date.

The number is never on screen at rest — only its last four characters, which is enough to confirm you are looking at the right document and not enough to reproduce it.

The number is treated as sensitive personal data throughout:

• It is encrypted before it is stored. Nobody reading the database sees it.
• The screen shows only the last four characters.
• Reveal shows the full number, and every reveal is written to the audit log with your name, the property and the document — never the number itself.

Revealing is its own permission, frontdesk.guest.iddoc.reveal, separate from the permission to record a document. Both sit on the Front Desk role by default, because a clerk checking a guest in genuinely needs to read the document back. The split exists so a property that wants the stricter arrangement — the whole shift records documents, only a duty manager reads one back out — can have it by editing the role, without giving up the ability to record.

Removing a document is a real delete. Use it to correct a mistyped number, and to satisfy an erasure request.

Scans of the document#

A number is what a clerk reads back over a counter. What most properties are actually required to hold is the document — the photograph of the KTP, the passport page. Expand Scans on any document row to see what is attached, and to add more.

Both sides of a document, because that is how a KTP or a passport is actually captured at a counter. Images or PDF, up to 5 MB each.

Scans get the same treatment the number gets, and a little more, because a photograph of a passport discloses strictly more than the passport number:

• the file is encrypted with the same key as the number, and the list you see above carries only the filename, size and date — never the image;
• opening one needs the same frontdesk.guest.iddoc.reveal permission, and is written to the audit log as its own event.

The viewer says so on the screen. Looking at a guest's passport photograph is an event, not a page view.

Penting

Delete a scan as soon as the reason you captured it has passed. A retention rule you keep is worth more than an archive you cannot justify.

Preferences#

The Preferences tab is the guest's standing requests — the things a returning guest should not have to ask for twice.

A name and a value, where the value is free text and may run to a paragraph — "after 11:00, she works mornings" is the useful version of "late".

Use Add preference to create one, the pencil to edit, the bin to remove. A preference name is yours to invent: this is not a reference list, because what a house tracks about its regulars is not a vocabulary anybody else can supply.

Changes are recorded on the audit log by name only — what was changed, never what it said. A note about a guest's sleep or diet is personal data, and the audit trail is not the place to copy it.

Stays#

The Stays tab is this guest's history with the property, and the Guests list summarises it in a column: how many stays are still ahead of them, and how many are behind. A cancelled booking counts as neither — a stay that did not happen is not history.

Merging guests#

When two profiles turn out to be the same person, Find duplicates on the profile finds the candidates. Merging keeps the survivor's details and re-points every stay. Contacts and identity documents stay with the profile they were recorded on — check the survivor after a merge and re-record anything that mattered on the losing profile.

Who can do what#

Permission	Lets you	Held by default
frontdesk.guest.read	Open a profile and see it, masked	Front Desk, Manager, Owner
frontdesk.guest.write	Edit the profile, contacts, documents, scans and preferences	Front Desk, Manager, Owner
frontdesk.guest.contact.reveal	Reveal an email address or phone number	Front Desk, Manager, Owner
frontdesk.guest.iddoc.reveal	Reveal a document number, and open a scan	Front Desk, Manager, Owner
frontdesk.guest.merge	Merge two profiles	Manager, Owner

The Read-only role deliberately holds none of these. It can read reservations, but a guest profile is where the personal data is, and "read-only" is not the same as "may see everything".

What's next#

• Reference data — the lists behind the title, nationality, source region and contact type dropdowns