Casa Layer is the guest identity layer under your PMS, booking, POS, spa and OTA systems. It sits under the stack: connecting to the systems you already run, resolving the same guest across those sources into one Master Profile, and making that identity available wherever staff and tools need guest context.
It does not replace your property systems. Reservations stay in your PMS, payments stay in your POS, and campaigns stay in your marketing tools. Casa Layer gives you one resolved view of the guest underneath them all.
Why guest records fragment
Most hotels already run a capable stack. The gap is not missing data. It is that the same person appears as a slightly different record in each system.
A returning guest might exist as:
a reservation guest in the PMS
a customer in the POS
a booking or OTA profile with a different spelling or email
a spa or F&B note that never reaches the desk
Staff then ask questions the guest has already answered. Ops and commercial teams struggle to trust lifetime context when it is split across sources. Casa Layer closes that gap with one resolved guest identity under the systems of record you keep.
How it works
Your workspace centres on a Property Group that owns one or many Properties. Guest identity is resolved across the Property Group by default, with the option to focus on a single property when needed.
Connected sources such as PMS, table booking and reputation management send guest-related records into Casa Layer. Every connection live today reads only. You decide what each system can share under credentials you issue. Marketing tools such as Klaviyo and Mailchimp can be bound as destinations when you need them; they are not replacements for your ESP.
Across those sources, matching guest fragments become one Master Profile: the resolved person record staff and tools use when they want the guest, not only what one system knows. Each Master Profile can carry attributes drawn from member source records, with provenance so you can see which source contributed a field. Source records remain source records. Resolution does not pretend one PMS row is the whole truth.
What you use day to day
Operators typically meet Casa Layer through:
Master Profiles in the Casa product for group-scoped guest identity
Guest Lookup, a Chrome overlay that surfaces front-of-house context while you work in existing browser tools
Tables, group-scoped lists of people for operations work. Tables are not marketing segments; campaign audiences stay in downstream tools
An open API and agent tools (read-only today) for partners and internal consumers. Detail lives on docs.casa-layer.com
What Casa Layer is not
Not a rip-and-replace PMS. Reservations stay in your property system of record.
Not a CRM or messaging product. Inbox, campaigns and pipeline work stay where they already live.
Not another place to run guest messaging or loyalty. Casa Layer resolves identity under your stack, so changing a PMS or CRM later does not erase the resolved guest layer you have already connected.
Related reading
Do we have to replace any of our systems?
Understanding Master Profiles
Using Guest Lookup
Technical reference: docs.casa-layer.com, especially Data model
FAQs
Is Casa Layer another login that replaces the desk workflow?
No. Guest Lookup is a staff overlay. Your PMS and other tools remain the places staff work day to day.
Do we need to migrate historical guests manually?
No. Connecting a source includes bringing relevant history into Casa Layer for identity resolution. Exact backfill scope is agreed per source during onboarding.
Can partners and agents use the same guest context staff see?
Yes, through the open API and agent tools (read-only today). Detail is on docs.casa-layer.com.