Why hotel loyalty programmes miss repeat guests

Most hotel loyalty programmes fail at recognition, not rewards. The points catalogue can be generous, the tier names can be sharp, and the member still arrives as a stranger, because enrolment is a separate event from staying, and the stay is stored as unlinked copies. A programme sitting on those copies treats a four-stay guest as a one-stay member, then buys them again as acquisition.

This is a category correction, not a product tour. Loyalty is good at earning and burning. It is weak at deciding whether this arrival is a person the house already knows. That decision has to happen before anyone segments, emails, or scores a member. The layer that makes it is an identity layer, not another campaign tool.

Resolution does not move guest data out of the systems that run the hotel. It works out which records are the same person and keeps the answer in a layer of its own. Casa Layer builds that Master Profile and holds it. We will not tell you the record is yours the way most of this category does. What is true is narrower and testable: nothing is sold on top that traps the record, you issue and revoke the credentials, cancel and every copy is deleted within 30 days, and the profile survives a PMS switch.

Enrolment is a separate event from staying

A stay can complete without a membership number ever being attached to it. The guest booked through an OTA, walked in, or used a work email the programme has never seen. The loyalty tool only knows the people who opted in, under the identifier they typed on the join form.

That join form is usually an email address. So the programme’s idea of “this member” is the address they enrolled with, plus whatever the PMS later wrote onto that same row. A second stay that arrives under a different address, a different property instance, or no address at all does not increment the member. It opens a new person.

This is why adding a richer rewards ladder does not fix recognition. Rewards assume a stable member ID. Most independent and mid-market programmes inherit the identifier scheme of the system they sit on. If that system keys on reservation or email, the programme keys on reservation or email. The guest who stayed four times without presenting the same key four times is, to the programme, four people, or one person and three strangers.

Chain programmes that force a member ID at every stay are stronger here, and that strength should be conceded. They made recognition a condition of earning. Most group programmes bolted onto a PMS did not. They made earning a condition of joining, and joining optional.

The address the programme can see is often not the guest’s

Booking.com is explicit about this, and the policy is a real one, not a glitch. On its current partner help page it states that it does not share private email addresses, and that both the property and the guest “will only ever see an anonymous alias ending in @guest.booking.com or @partner.booking.com.” It tells partners to keep communication on Booking.com platforms, the extranet and the Pulse app. It will not share personal information with either party. The same page says you can send messages from the time of booking until seven days after checkout or cancellation.

That is a privacy and security design, and it works as designed. The hotel can talk to the guest about this stay. It cannot treat the address on the reservation as a durable identifier for the next one.

The Connectivity API is just as plain. The reservation details Booking.com tells providers to show a property include the booker’s “alias email address.” A current example payload uses feature.794761@guest.booking.com. The field is labelled as the email supplied by the booker, used by Booking.com to send the confirmation. What lands in the PMS is a constructed alias on Booking.com’s domain, not the address the guest would type into a loyalty form.

A programme that matches on email will not join that stay to the member who later books direct, or who enrolled with a personal address at check-in. The records are both true. They do not share a key.

Capturing a real address at the desk still helps. It does not, on its own, stitch the OTA stay that already wrote a proxy into the PMS to the member row that holds the real one. That is a match problem, not a capture problem.

The programme sits on copies the other systems do not share

Even when the email is real, it is not the only copy.

The PMS keys on reservation and room. The POS keys on the room charge opened at check-in. The spa system keys on the appointment. The booking engine keys on account or email. None of those keys is shared. A loyalty ID, if it exists, often lives in a silo the POS and the spa never read.

So the same guest can be a member in the programme, a folio in the PMS, a cover in the restaurant, and a treatment in the spa, with no join between them. Property B, running a different PMS instance, has no read on property A. The programme that only sees the member table cannot count the bar spend, the spa visit, or the stay at the sister hotel.

None of those systems is wrong. Each captured a real interaction. The failure is architectural: there is no record above them that says these interactions are one person. A loyalty tool pointed at that estate will report members, stays and points with confidence, and still miss the guest who keeps coming back.

A four-stay guest looks like a one-stay member

Take the shape, not a named house.

Stay one arrives from Booking.com. The PMS writes a proxy address. The guest does not join.

Stay two is direct, six months later, at the same property. They enrol at check-in with a personal email. The programme creates a member with one stay.

Stay three is at a second property in the group. New PMS instance, new profile, no member ID passed. The programme never sees it.

Stay four is a walk-in to the restaurant, paid on a room that was booked under a partner’s email. The POS has a surname and a table. Nothing to join on.

The group has hosted this person four times. The programme has a one-stay member and three unlinked records. Acquisition spend then goes out to people who already sleep there, because the campaign tool was fed the first-party list the programme thinks it has, not the people who have already stayed.

That is the commercial cost. Not a weak points catalogue. A list that under-counts the guests it already paid commission to house.

Resolve before you segment

The fix is not a better join form. It is matching on more than email, across properties, before anyone builds a segment.

Deterministic matching joins records that share an exact key: a hashed real email, a phone number, a loyalty number the guest actually presented. It is high confidence and you can explain any given merge. It fails on the OTA alias and on the POS row with no email.

Probabilistic matching uses weaker signals together: name variation, mobile, stay overlap, property, a work email next to a personal one. It extends reach at the cost of certainty. Merging two different people is a worse failure than missing a link, because the guest who inherits someone else’s allergy note finds out the hard way. A serious system runs deterministic matching as the backbone and probabilistic matching to widen coverage, with a threshold set high enough that two guests do not collapse into one.

OTA aliases should be treated as a known pattern, not as an email. Route those records toward fuzzy matching rather than exact email lookup. A well-designed resolver recognises the published proxy domains and does not pretend feature.794761@guest.booking.com is a person.

Resolution has to run across properties, not only inside one PMS. A group programme that cannot see property B cannot recognise the guest who used property A. And it has to run continuously. New OTA bookings arrive every day. A one-time cleanup reverts to fragments within weeks.

Do this before you segment. A segment built on unlinked records is a mailing list of ghosts and doubles. The loyalty tool should consume the resolved person, not invent one of its own.

Loyalty should read the Master Profile, not own it

The output of that work is the Master Profile: one merged record per guest, sitting above the systems that feed it. Source records stay in the PMS, the POS, the spa and the booking engine. The profile is the layer on top.

The loyalty programme should read that profile. It should not become the system of record for who the guest is. A programme that owns the identity graph will do what a packaged marketing suite does: couple the resolved person to the points engine, the email module and the vendor’s own exit. You can usually export a flat list of members. You can rarely take the match keys and the evidence with you.

Ask what the profile is attached to. Is it a layer any tool can read, including a loyalty tool you might replace, or is it a feature of the loyalty application, resolved to make that application perform?

Casa Layer builds the Master Profile and holds it. We sell none of the applications the record feeds, so there is nothing here for it to be locked into. Your team, your CRM and the loyalty tool you already run can read the same profile through an open REST API. Agents read it the same way. The agents will change. The layer they run on does not.

Four tests replace the worn sentence about owning your data.

Can you read the full record from the tools you already run, rather than only from inside the vendor’s application? Can you see the identity graph and the match keys, or only the collapsed member row? If you switch your PMS or your loyalty tool, does the record survive intact? Can you enforce a consent decision or a deletion, and prove afterwards that it happened?

Our answer to the third is the one that shows the coupling. Replace the CRM, the PMS or the loyalty tool and the resolved record is untouched, because it never lived inside any of them. Cancel, and every copy is deleted from our systems 30 days after cancellation. Your own systems stay the record throughout. Revoking the credentials you issued closes everything we can reach.

That is the mechanism. Let loyalty then do the job it is actually good at: earning, burning, and talking to a member the house can already recognise.

Frequently asked questions