Identity Resolution

Identity resolution is the hardest technical problem in guest data, and it sits underneath everything else a restaurant CRM does. Before a platform can tell you who your regulars are, it has to work out which records belong to the same human being.

What signals does identity resolution use?

Identity resolution works from shared signals. Phone number is the strongest, because guests reuse one number across years and platforms. Email is next, then name similarity, then payment and behavioural signals such as the same card or the same table on the same weeknight.

Name matching on its own is unreliable and never enough. “Jenna Smith”, “Jenna Smyth”, and “J. Smith” may be one guest or three, so a name is used to support a match rather than to make one. In practice a record with no phone and no email usually cannot be resolved at all, which is why capture at the door matters as much as any algorithm.

Why does the same guest show up twice?

Duplicate profiles are normal, not a sign something is broken. Four causes account for most of them:

• A different email per platform. A guest books with a work address on one platform and a personal one on another.
• Masked or relay addresses. Some reservation platforms hand over a forwarding address rather than the guest’s own. Two bookings by the same person can arrive with two different masked addresses, and neither is the real one.
• Name-only records. Walk-ins, phone reservations, and paper notes often arrive with a name and nothing else.
• Two groups, two guestbooks. Guest records are scoped to the restaurant group that collected them. The same guest dining at two unrelated groups is genuinely two profiles, and that is correct rather than a defect.

Can my reservation platform do identity resolution?

Only within its own data. Resy, OpenTable, SevenRooms, and Tock each maintain a guest record built from bookings made on that platform. Those records are accurate within their own scope. What none of them can do is resolve a booking against a point-of-sale check, a review, or a private-events enquiry, because those records live in other systems.

The practical result is that a restaurant running two reservation platforms has two partial guestbooks and no way to tell that a guest appears in both. Resolving across systems requires something that reads all of them. That is the job a guest data platform exists to do.

Should duplicate profiles be merged automatically?

Mostly not, and the reason is asymmetry. A missed merge leaves two thin profiles, which is a small loss. A wrong merge combines two different people into one record, blends their spend and preferences, and can send one guest a message about the other’s visit. That damage is hard to unwind and embarrassing in service.

So the sound approach is to detect aggressively and merge conservatively. Loyalist works this way: it clusters likely duplicates using several strategies, from exact email and phone matches through to fuzzy name similarity, then presents them for review instead of merging silently. Automatic merging is available for the high-confidence strategies and is off by default, which is the right setting for a guestbook a team has to trust in the room.