Guest profiles & notes

Every booking tells a venue who is coming, and DineGlobe keeps that knowledge where the venue can use it: a guest profile per venue, built automatically from bookings, with service notes, tags and consent evidence attached. Profiles are strictly venue-scoped — two venues that share a guest’s email each see only their own record, and nothing ever merges them. What you can see on a profile is decided by your role on the server, not by the screen you have open. This page explains how profiles form, what they hold, which note categories are restricted, and what each role may see.

How a profile forms

A profile is created the first time a booking at your venue carries an email address. The booking command looks for the oldest matching profile with that email in this venue only; if one exists it is reused, otherwise a new profile row is created with the guest’s display name, email, phone number (E.164), preferred language and the booking source. A walk-in or phone booking taken without an email creates no profile at all — the reservation stands on its own with its frozen contact snapshot (see below), and nothing is invented for it.

Profiles never span venues. This is a deliberate design decision (ADR-017): there is no cross-venue CRM, no automatic identity merge, and no “same person elsewhere” lookup. If the same guest books at two of your venues, each venue keeps its own independent record and its own history.

The booking’s frozen contact snapshot

Each reservation freezes its own copy of the guest’s contact details at booking time: display name (required), email (required), phone (optional, E.164) and the guest’s free-text requests to the venue (up to 1000 characters, the “Anything the venue should know?” field). The snapshot is dated history: later profile changes do not rewrite old bookings, and the guest’s private booking portal reads the snapshot, never the live profile.

What a profile holds

Field	Where it comes from
Display name, email, phone	The booking that created the profile
Preferred language, source	The booking that created the profile
Visit, no-show and cancellation counts	Counted live from this venue’s reservations and completed visits
Last visit stamp	The most recent completed visit at this venue
Tags	The venue’s own tag vocabulary (see below)
Notes	Encrypted service notes with provenance (see below)
Consent records	The append-only consent ledger (see below)

Searching guests

Guest search is a staff act that needs reservations.read on the venue. The search text (2–120 characters) matches an exact email (case-insensitive), an exact phone number, or a fragment of the display name; up to 20 matches come back. The search is pinned to one venue — you cannot search the organization, and another venue’s guests do not exist for this query.

Your role decides what each result contains. Fields are withheld entirely, not blanked:

Role	What search returns
Owner, org admin, manager, host	Identity fields, visit/no-show/cancellation counts, last visit, tags, and decrypted note bodies
Door	Identity fields and the counts only — never notes, tags or the last-visit stamp
Finance, read-only	Identity fields only

Door staff therefore see that a guest is a repeat visitor with two no-shows, but nothing about why. That split is the point: arrival data helps the door, while service context stays with service roles.

Service notes

Notes carry one of four categories: GENERAL, DIETARY, ACCESSIBILITY or ALLERGY. Three of them — DIETARY, ACCESSIBILITY and ALLERGY — are restricted service data: reading a note in one of these categories writes an audit event recording who read and which categories were involved. The audit records field names only, never a note body. GENERAL notes are ordinary service data.

Every note body is encrypted at rest (AES-256-GCM); the plaintext never touches storage, logs or the audit ledger. A note body is 1–1000 characters. Writing notes needs reservations.write — host and above. Each note stamps its provenance: who created it, when, and optionally which reservation it belongs to. That optional link must point at the same guest’s own reservation in the same venue; anything else reads as a plain not-found, with no hint that the reservation exists elsewhere.

There is no note edit or delete command in the pilot. A correction is written as a new note, so the record of what was known and when stays intact. Notes also never reach the guest portal, and a verified deletion request erases them — see Privacy, retention & deletion.

Tags

Each venue owns its tag vocabulary, and a profile can carry tags from that vocabulary. Tagged labels appear in search results for service roles only (active tags only, sorted by label). One honest limitation: the pilot ships the data model and the read path for tags, but no command writes tags yet — so a fresh venue simply shows none. When tag writing arrives, it lands inside the same role checks described above.

Consent records

Consent is a ledger, not a flag. Each row records a purpose, whether consent was granted or withdrawn, and the evidence around it:

Purpose	Meaning
BOOKING_SERVICE	The transactional consent implied by making and servicing a booking
MARKETING	Marketing consent — never granted implicitly by anything in the product
PRIVACY_RIGHTS_REQUEST	Consent context for the privacy-rights workflow itself

A row also records the channel (for example at_venue), the policy version reference it was taken under, the source (for example staff_attestation), and optional evidence text — which is stored only as a SHA-256 hash, never verbatim. Recording evidence is a host-and-above act: the staff member is attesting that the guest said this. The ledger is append-only; a change of mind is a new row, never a rewrite of the old one. Booking a table is booking-service consent and nothing more — no row of the system ever turns a booking into marketing consent.

What guests themselves see

The guest’s own view is the private booking portal described in Guest self-service links. It shows that one booking — status, time, party, cancellation terms — and nothing else. Staff notes, tags, counts, consent rows and profile internals are absent from the guest’s page by construction, not by hiding.

Where you do this

Guest search, note writing and consent evidence live in the “Guest notes, tags and history” panel on the operator console at https://dineglobe.com/app/panels. Refusals read like the rest of the product: a venue, guest or reservation you cannot see is a plain NOT_FOUND, and a role gap is PERMISSION_DENIED. The full vocabulary is in Error codes & fixes, and the role-by-role split is summarized in Roles & what they can do.