Who Counts as a Guest in Your CRM

Every reservation that lands in your CRM carries at least one string shaped like a person: an email address, a phone number, a name, sometimes a date of birth. The natural assumption is that any string in that shape is a guest, and should become a contact record you can build a profile around, send email to, and merge with everything else you know about that person.

That assumption is wrong often enough to matter, and it fails in a specific, structural way that a plain deduplication pass never catches, because dedup only runs on contacts that already exist. GuestMaker's CDP has a layer that sits in front of that: the Identity Layer. Its job is narrower than it sounds. It doesn't try to work out who a guest is. It decides, for every identifier that arrives with a reservation, whether that identifier is even allowed to become a contact in the first place.

Two questions, not one

The mistake that motivated this layer is easy to describe, because we've seen it made. An older approach asked one question of every identifier: is this good or bad. One flag, one verdict. That's a reasonable instinct until you look at what "good" actually needs to cover, because it's really two separate questions wearing one label.

The first is identity. Can this value be used to recognize one real person, reliably enough that "these two bookings are the same guest" is a safe inference to make? A guest's own email address usually passes. A shared inbox a wholesaler uses across hundreds of different guests' bookings does not, no matter how legitimate the reservation behind it is.

The second is reach. Can you actually write to this value, and how far? Nothing at all. A transactional message only, a confirmation or a check-in link. Or full marketing, the kind of address you're comfortable dropping into a newsletter segment six months after checkout.

These two questions don't always agree, and a system that collapses them into a single verdict gets the disagreement wrong in a specific, predictable direction: it treats a failed identity check as license to kill reach too. That's the bug. An OTA-generated relay alias fails identity outright. It's not a stable way to recognize a person across separate bookings. But there's a real guest behind it, and that guest is still owed a confirmation email, whether or not the alias can ever be safely linked to anything else they've booked. Block on identity and reach dies with it, and the guest never gets their confirmation.

The fix is to keep the two axes independent all the way through the system, and require every rule to state its verdict on both, not one.

Four shapes, and what happens if you get them wrong

Sort what actually arrives in a reservation feed by these two axes, and a small number of recognizable shapes show up repeatedly.

The overwhelming majority, on the order of 97% of every identifier the system observes, is the boring case: a guest's own real address or number, good for identity, good for reach, no special handling required. That's worth stating plainly, because it's easy to design a whole system around the exceptions and lose track of the fact that they're exceptions. Most of what's in your CRM is exactly what it looks like.

The remaining share, roughly 3%, is where this layer earns its keep. Four shapes cover it.

An agency or tour-operator desk mailbox touches hundreds of different guests' bookings through one shared inbox. It fails identity, since you can't tell one guest from another behind it, and it fails reach, since it isn't a person you should be emailing directly. The reservation and the guest are still stored in full. No contact record gets created from that address, and it never gets used to merge guests together.

An OTA relay alias, the kind Booking.com mints fresh for every reservation, looks like junk and isn't. It fails identity for the same structural reason, it can't be traced across separate bookings, but it passes reach, at least for the length of the stay. It should receive the booking confirmation, the pre-stay information, the check-in message. It stops receiving anything after that, because the alias itself goes dead at checkout on its own.

A placeholder, the sort of value front desk staff type in when a guest doesn't hand over a real email (something in the shape of "noemail@gmail.com"), fails both axes. Without a rule catching this specifically, every guest at a property who declines to give an email collapses into one fictional contact who has apparently stayed hundreds of times.

And then there's the normal case, which is most of what's left once the other three are filtered out.

Within that filtered 3%, the OTA relay alias is by far the largest share, on the order of 79% of it. Agency and tour-operator mailboxes come next, around 8%. Role accounts, the info@ and reservas@ style addresses that are a desk rather than a person, are a similar order of magnitude, around 6%. What's left, institutional addresses, malformed phone numbers, a hotel's own domain showing up as if it were a guest, a document field carrying the wrong value, each make up a small fraction on their own.

Six pieces, in order

The Identity Layer isn't a single rule. It's a pipeline, and each piece exists because the one before it isn't sufficient by itself.

Observations come first. Every reservation, contact, or guest record that asserts something about a person gets logged. This is the evidence base everything downstream reasons from. Not a judgment yet, just a record that something was claimed.

Identifier judgment turns observations into a verdict. Each email, phone number, document, or name gets scored on evidence: how often it's been seen, how many distinct names are attached to it, whether the pattern looks exclusive to one person or shared and promiscuous across many.

Identifier rules turn judgments into a durable, two-tier ledger. Platform-wide rules catch the obvious and common cases, the shapes described above, applied to every hotel group. Tenant-specific rules capture what's particular to one group: its own contracted agencies, its own domains, its own front desk habits.

The gate is where rules get applied, at the moment data comes in. This is the part worth being precise about, because it's the part people worry about most. The reservation is always saved in full. The guest record is always saved in full. The only thing the gate can withhold is the contact record, the thing that would let this identifier be searched, segmented, and mailed to as if it belonged to a known person. No booking data is ever lost. The system just declines to invent a person who probably isn't there.

Contact merge is the downstream engine that unifies duplicates once real contacts exist. It's covered in more depth in the golden record that unifies a guest's history across every property; described generically, clear cases merge automatically, ambiguous ones go to a queue for a person to review, and every merge is reversible.

Guest and reservation-guest merge handles travel companions, the people on a reservation who aren't the one who booked it. They link to their own contact records where the evidence supports it, with one guardrail worth naming directly: two people who share a single email address on the same reservation, a couple booking together is the obvious case, do not get collapsed into one person just because they share an inbox. Sharing an address on one booking is not the same claim as being the same person.

The part that's hard to show a hotel group

There's a property of this system that makes it a genuinely awkward thing to demonstrate, and it's worth naming rather than glossing over: a rule that works destroys the evidence that justified building it.

Before a rule exists to catch, say, a specific wholesaler's shared inbox, every reservation through that channel creates a new fictional contact. That's visible. It shows up as a spike in contact counts, as a "guest" who's apparently stayed at your property dozens of times, as a segment that's quietly wrong. It's a problem you can point at and show someone.

Once the rule is in place, that channel stops creating contacts. The spike doesn't happen. The fictional guest never gets created. And because it never gets created, there's nothing new to show as proof the rule is doing anything. The value sits entirely in what never got dirty in the first place, and data that never got dirty doesn't appear in any report you'd run to check on it.

That's not a reason to distrust the system. It's a reason to measure it differently than you'd measure most CRM features. You won't see this layer's output on a dashboard, because its output, by design, is the absence of a category of bad row. If you want to see it working, the honest way is to look at what it used to catch before the rule existed, and trust that the same shape of thing is still arriving and no longer landing.

Where this sits

This layer runs before anything else in your CRM touches a guest. It doesn't resolve identity across properties (that's what the golden record downstream is for) or tell you whether a guest has arrived yet, or summarize what you know about them. Those are jobs for the rest of what a customer data platform does. Those are later questions, and they only get good answers if the population of contacts feeding them was sound to begin with.

Treat it as the gate it is. What gets through is what the rest of your CRM is built to trust.