Identity resolution is the process of deciding that two records, in two different systems, describe the same person.
It sounds like plumbing. It is actually the single decision that determines whether everything downstream is trustworthy, because every visit count, every lapse figure, and every audience is built on top of it.
Why it is hard
Because restaurant data is entered by tired people during service, and because guests are inconsistent about themselves.
The same person books as "Dave" at one concept and "David" at another, uses a work email for business dinners and a personal one for anniversaries, and gives their partner's phone number when their own has no signal in the building.
The signals, strongest first
Good resolution works down a ladder of confidence and stops at the first rung that genuinely holds.
- Same source ID. The same reservation platform's own identifier. Definitionally the same person.
- Exact phone match. The strongest cross-system signal in hospitality, because phone numbers are personal and rarely mistyped in a way that still validates.
- Exact email match. Strong, though shared household addresses are more common than people expect.
- Name plus one of the above. Raises confidence on an existing match; not a match on its own.
- Name alone. Not a match. Not ever.
Why a shared phone number is not automatic either
Two records with the same phone number are usually the same person. Usually.
They are also sometimes a couple who book with one mobile, or a PA booking for an executive, or — very commonly — the host stand's own number typed in to get past a required field.
That last one is worth checking in any export you receive. A single phone number attached to two hundred guests is not a data problem to be resolved. It is a placeholder, and merging on it would combine your entire Saturday into one person.
Confidence states, and why they should be visible
Resolution is probabilistic at the edges, and a product that hides that is lying to you comfortably.
What you want to see is the confidence level and the reasoning — matched on phone, matched on email, name matched but nothing else. Then a person can adjudicate the uncertain ones instead of discovering a bad merge six months later.
- Confirmed — a shared strong identifier. Safe to act on.
- Likely — good evidence, not conclusive. Usable with judgement.
- Possible — weak evidence. Confirm before acting.
- No match available — say so plainly rather than guessing.
Why the conservative choice is correct
Under-merging leaves you with two records for one guest. Annoying, visible, and fixable at any point.
Over-merging destroys two real histories and creates a person who does not exist, and you usually find out when a host greets someone by the wrong name at the door.
Prefer false negatives. Send the uncertain cases to a human queue and accept a slower, duller product. That trade is not close.