Golden Record

The phrase comes from master data management, where a golden record is the settled version of a customer or a supplier that the rest of a business reads. Hospitality borrowed it because a restaurant group runs the same problem at smaller scale. The reservation book, the point of sale, the reviews inbox, and the private-events system each hold a version of the same guest, and each one is accurate from where it sits. A restaurant CRM is the layer that decides which version the house goes with.

What does a golden record actually resolve?

A golden record resolves conflicts between values. Working out that several records describe one person is a separate job, and once it is done the platform is holding three phone numbers, two spellings of a surname, and two email addresses for a single guest. Something has to decide which of those a host reads at the door.

Two kinds of guest data behave differently at that moment. History accumulates, so eleven visits collected across three systems are eleven visits and none of them is discarded. Attributes compete, because a guest has one current mobile number, and two candidates mean one wins while the other is kept behind it as a secondary value. A golden record is a union of events and a decision about attributes, not a merged pile of everything.

Is a golden record the same thing as a guest profile?

They are largely the same object seen from two angles. Guest profile is the name for what an operator opens on screen, and golden record is the name for the fact that the values on it were chosen rather than copied in. Two neighbouring terms complete the set: identity resolution is the process that decides which records belong to one person, and match rate measures how much of a restaurant’s volume reaches a guest record at all.

The distinction is worth keeping because it locates the failure. A thin profile is usually a matching problem, meaning the records never came together. A wrong profile is usually a survivorship problem, meaning the records came together and the platform picked the wrong value out of them.

Which value should win when two systems disagree?

Survivorship rules decide, and the ones that work in hospitality are not the obvious ones.

• Contact detail the guest gave you outranks contact detail a platform issued. Some reservation platforms hand over a forwarding address rather than the guest’s own, so an email captured at the restaurant should sit ahead of a relayed one even when the relayed one arrived more recently.
• For phone and email, recency wins. People change numbers and jobs. The most recent confirmed value is the one a host should be dialling.
• For names, completeness wins. A walk-in recorded as “J. Smith” should not overwrite “Jennifer Smith” from a booking made last year. Keep the short form as an alias so the next match still succeeds on it.
• What a guest stated outranks what a system inferred. A birthday typed into a booking form beats a birthday appended from an outside dataset, and a stated allergy beats a guess drawn from ordering history.
• Money is summed, not arbitrated. Spend and visit counts come from the source systems and stay there. The point of sale remains the authority on what a check was.

Field-level provenance is what makes those rules usable. A record should be able to say where each value came from and when it arrived, because a manager who believes the phone number is wrong needs somewhere to look. A golden record with no provenance is just an opinion with better formatting.

Can my reservation platform or point of sale build a golden record?

Within its own data, partly. Resy, OpenTable, SevenRooms, and Tock all merge duplicate guest records they can see, so the profile you read inside one of them is already a resolved record for that platform’s own bookings. The same is true of a point of sale with a loyalty module. None of them can settle a booking against a closed check, a review, and an events enquiry at the same time, because those records sit in systems they do not read.

One boundary is worth knowing before you go looking for a single record per human being. A golden record is scoped to the restaurant group that collected it. The same guest dining with two unrelated groups is two golden records, held separately, and that is correct rather than a defect. Within a group it works the other way: a regular at one venue should arrive at a sister restaurant with the same record, which is the case a single-system guestbook cannot handle at all.