Commercial teams acting on one profile.

Commercial teams already have tools that act on a guest list: a loyalty programme, a CRM, a campaign engine, sometimes a revenue agent. Each tool is doing real work. Each one also tends to keep its own copy of who the guest is.

The job is not to replace those tools. It is to stop them acting on different people. A campaign, a tier and a desk recognition should attach to the same guest.

Most hotel loyalty programmes fail at recognition, not rewards. Enrolment is a separate event from staying. OTA stays arrive with an alias rather than the member email. PMS, POS, spa and booking-engine copies of the same person do not share a key. The programme counts members. It does not count people.

A CRM pointed at those fragments inherits them. It will message the records it has. It cannot join a four-stay guest who looks like a one-stay member. A richer points ladder does not fix that. Rewards assume a stable person.

This page will not invent a return figure for pointing commercial tools at a resolved record. The mechanism is the claim: one person, read by the tools you already run.

The programme should read the Master Profile rather than own it. Casa Layer resolves the person and stops. Loyalty keeps the points engine. The CRM keeps the campaigns. Change either later and the resolved record carries on, because it never lived inside them.

Casa Layer builds the Master Profile and holds it. We sell no applications on top of it, so there is nothing here for it to be locked into: no messaging suite, no loyalty product, no CRM of our own. Your own source systems stay the record throughout.

You decide what Casa Layer can do in each system, under credentials you issue and can revoke. Every connection live today reads only.