Guest 360 and the guest portal · one profile, allergies and magic links
Every guest has a single profile that recognizes the same person across bookings from your site, an agency and an OTA, with a reversible merge and masked emails treated for what they are. Allergies and preferences travel with the booking and are acknowledged by each department. The guest portal is entered through a magic link sent to a firm email address, and loyalty connects the guest to the points program the property already runs.
One guest, one profile
The same person books through your site, through an agency and through an OTA, and in many systems that becomes three records. Here the profile is single: capturing a guest looks for a duplicate by identifier (email, phone, document) before creating a new one, and records where each identifier came from. When two profiles really are the same person, a merge brings everything together and can be undone later, because a wrong merge happens and must not be a one way door. The relay email that OTAs generate is recognized as masked: it appears on the profile for what it is, never creates a phantom guest and is never a login for the portal.
Allergies and preferences reach the people who need them
Guest preferences and restrictions have a category and a severity, and the critical ones travel with the booking: when you record one, you indicate the departments that need to know (kitchen, housekeeping, service), and each department acknowledges receipt. The information does not get lost in a notes field: there is a list of pending propagations until everyone has acknowledged. An allergy is health data and is treated with that weight: it is masked in ordinary reading, and revealing the detail is a logged action with a trail, not a casual lookup. This data is never sent to an AI provider: the vertical's briefing refuses to assemble any text from person level data.
The guest portal: signing in with a magic link
- The guest receives the portal address in the confirmation email or in a QR code at check-in.
- On the access page, they type the email used on the booking and request an access link.
- If that email is a firm identifier on the profile (an OTA masked address never receives a link), an email arrives with the sign-in button. The link is valid for 30 minutes.
- Inside the portal, the guest sees their own bookings (with the property and the dates) and the quotes sent to them, and can accept whichever quote tier they prefer without calling the front desk.
The answer to a link request is always the same, whether the email exists or not: the portal does not confirm to a stranger that an address belongs to a customer of the property. And the session revalidates the email on every request: if the front desk removes or deactivates the identifier, access dies immediately. There is no password to leak and no account for the guest to manage.
Loyalty: the program you already run, not a second one
The Loyalty tab on the Hospitality screen shows, for the guest chosen in the selector, the Points and the Tier in the loyalty program your organization already has in the CRM. If the guest is not enrolled yet, the Enroll in the program button enrolls them on the spot. The vertical does not create a parallel hotel points program: it links the guest to the existing one, so that a second balance nobody would ever reconcile is never born. Crediting points for a stay is done through the system API, typically when the stay closes.
When a guest asks to be forgotten
The data subject can have their data exported and can be erased from the guest records. Erasure requires a reason and returns a report of what was done: the profile, the identifiers and the health data are deleted; bookings and quotes remain without identifying anyone, because they underpin occupancy and accounting; a signed waiver remains as evidence and simply loses its link to the deleted profile. Anything retained under a legal duty is listed along with the reason.