No. Casa Layer is the guest identity layer under your PMS, booking, POS, spa and OTA systems. It sits under the stack: connecting to tools you already run, resolving the same guest across those sources, and giving staff one clear view of guest context. Your systems of record stay where they are.
You do not rip out the PMS, rebuild the front desk, or move messaging and CRM work into Casa Layer. Reservations, payments and campaigns keep living in the products that already own those jobs.
What stays in place
Treat these as systems of record for their own work:
PMS for reservations and stay operations
Booking and OTA tools already in use
POS, spa, F&B and related tools already in use
Marketing tools such as Marketing and Guest Journey CRMs, where bound, as destinations for curated people lists. They are not replaced by Casa Layer
Casa Layer’s job is resolved guest identity and the read surfaces around it, not owning the operational applications above.
How connection works
When a hotel joins Casa Layer, the model is additive:
You approve which systems Casa may reach, under credentials you issue and can revoke.
Casa connects those sources and brings guest-related history into your Property Group.
Identity resolution builds Master Profiles across those sources.
Staff keep working in the PMS, POS, booking, spa and other tools they already know.
Where helpful, staff open Guest Lookup as a Chrome overlay for context, or read Master Profiles and Tables in Casa Layer.
Every connection live today reads only. You decide what each system can share.
Sources and destinations
It helps to keep two ideas separate:
Sources contribute guest fragments into Casa Layer. Examples of connected-class providers include PMS, table booking and reputation management systems. Exact providers vary by hotel: check what is connected in your workspace, or ask your Casa contact.
Destinations can receive curated people lists when a Table destination binding is in place, for example Marketing or Guest Journey CRMs. Destinations do not turn Casa Layer into a CRM.
Guest Lookup is an overlay
Guest Lookup floats beside allow-listed browser tools so staff can search Master Profiles without leaving the desk workflow. It is deliberately non-modal: typing in the PMS does not depend on it. If Guest Lookup is closed, the desk still works the way it works today.
Guest Lookup is available where your workspace enables it. Rolling it out across managed shared machines is a separate IT conversation with Casa.
Open API and agent tools
Casa Layer exposes an open API and agent tools (read-only today) so partners, internal tools and agents can read the same guest context operators see. Protocol and endpoint detail lives on docs.casa-layer.com.
What Casa Layer is not asking you to do
Retire your PMS, CRM or messaging suite
Migrate staff onto a new system of record
Assume write-back or invented sync behaviour
Treat every logo on a marketing page as live in your tenant
Related reading
What is Casa Layer?
Understanding Master Profiles
Using Guest Lookup (Chrome extension)
FAQs
Will Casa Layer change our check-in flow?
No. Staff keep the PMS workflow. Guest Lookup is optional context beside that workflow.
What if we change PMS later?
Because Casa Layer sits under the stack as a connected identity layer, replacing a source system does not mean Casa was that PMS. Connection scope is re-agreed for the new source during onboarding.
Can we connect only some properties first?
Yes in principle. Tenancy is Organization → Property Group → Properties, with optional property drill-down. Exact rollout sequencing is an onboarding decision with Casa.
Are marketing tools replaced?
No. Where connected, tools such as Klaviyo or Mailchimp remain destinations. Casa Tables are ops containers, not ESP segment builders.