Privacy by Design: Your Staff See What They Need. Nothing More.
We're built different. Because the housekeeper doesn't need your guest's credit card number to clean a room.
Most platforms show everything to everyone who logs in.
When a housekeeper opens their tablet, a server checks an order, or a maintenance contractor glances at a screen, what do they see? In most hospitality and operations software, the answer is too much: guest emails, phone numbers, payment details, booking totals. Data that has nothing to do with getting the job done. Calisto is built differently.
Built Into the Architecture
This isn't a permission toggle or a checkbox in settings. The data model itself separates commercial records from operational ones. Operational staff records don't contain financial data, because it was never placed there.
Global Privacy Laws Are Tightening
GDPR in Europe, CCPA in California, LGPD in Brazil, PDPA across Asia: regulators worldwide are raising the bar on who can access personal data and why. The safest data is data that simply isn't in the wrong place to begin with.
Fewer Hands, Fewer Risks
Every person who can see a guest's phone number is a potential data exposure point. Not because your staff are untrustworthy, but because limiting access is simply better practice. Calisto enforces this automatically.
Two records. One transaction. Each built for a different audience.
Every booking in Calisto creates two distinct records: the Booking and the Reservation. They're linked, but they serve entirely different purposes and reach entirely different people.
The Commercial Record
The full financial and identity picture, visible only to the people who need it: admins, finance, revenue managers, and owner statements.
- · Confirmation code, guest name, email, phone
- · Payment details, total value, balance due
- · Booking source (direct, OTA, corporate, proposal)
- · Financial history and folio linkage
Who sees this: Admins · Finance · Revenue managers · Owner reports
The Operational Record
The fulfillment-focused view: everything the team needs to deliver the service. Nothing they don't.
- · Asset assignment, dates, and status
- · Guest first name only (for personalization)
- · Special requests, notes, occupancy count
- · Check-in/out status, cleaning tasks, key management
Who sees this: Front desk · Housekeeping · Servers · Field staff · Kiosks
Rule of thumb: If the person fulfilling the service doesn't need the data to do their job, it belongs on the Booking, not the Reservation.
What this looks like across your team
The same principle applies across every vertical. Different industries, same architecture.
Hotels & Short-Term Rentals
A housekeeper opens their task list and sees "Room 214, King, Departure clean, 2 guests." They don't see the guest's email, phone number, or what they paid per night. The room gets cleaned. The data stays protected.
Result: Operational efficiency without data exposure
Restaurants & Food & Beverage
A server sees "Table 6, 2 adults, 1 child, nut allergy noted." They can personalize the experience. They can't see the billing account, the corporate booking reference, or the guest's contact information.
Result: Personalized service, contained information
Wellness & Clinical Spas
A therapist sees the appointment, treatment type, and client preferences. Billing, insurance details, and contact information are handled separately by admin staff, not visible at the treatment level.
Result: Clinical professionalism with proper data boundaries
Golf Clubs & Experience Operators
A starter or guide sees "8:12am, John S., 4 players, cart requested." The member number, account balance, and contact details stay where they belong: in the financial record, not on the course sheet.
Result: Smooth operations without unnecessary access
A permission toggle is not the same as architectural separation
Most platforms handle this with access controls: hide certain fields from certain roles. It sounds similar. It isn't.
Field-Level Permissions
The data is still in the record. It's just hidden in the UI. A misconfigured role, a shared login, or a developer query can expose it. The risk doesn't disappear; it's just masked.
One Big Record
When a single record holds everything (identity, payment, operational notes), the blast radius of any access mistake is the entire record. There's no clean boundary between what's sensitive and what's not.
Calisto Architecture
Booking and Reservation are separate data structures. Operational records don't contain financial fields, because they were never designed to. You can't expose what isn't there.