Data Enrichment

Enrichment is a term borrowed from consumer marketing, where it usually means buying data about people you already have on a list. In hospitality the same word covers something quite different and considerably more valuable, which is completing a guest record from the other systems in the building. A restaurant CRM that connects reservations, the point of sale, reviews, and private events is doing enrichment as a side effect of matching, before anyone spends money on an outside dataset.

Where does enrichment data come from?

From three sources, in descending order of how well they work for restaurants.

The systems you already run. Records of the same guest in different systems complete each other. A booking arrives with a name and a forwarded email address. A check from a point of sale that passes guest detail can carry the real email. A private-events enquiry usually carries a direct mobile number and a company. A review carries a display name and an opinion. Matching those records to one person fills in fields nobody had to acquire, and this is where most real enrichment happens.

Asking the guest. A one-question confirmation message or a short post-visit survey collects what no dataset holds: the occasion, the restriction, the preference, the birthday. It costs a message and it produces the only data a guest expects you to have.

Outside datasets. Consumer and business data vendors will append attributes to a list you send them. This is the version most people mean by enrichment and the one that works least well in a dining room, for reasons that are structural rather than a matter of picking a better vendor.

Does buying third-party data work for restaurants?

Rarely, and the reason is the match key. Consumer data vendors match on a full email address or a postal address, and restaurant guestbooks are weakest on exactly those two fields. A guestbook heavy with relayed booking addresses, first-name-and-mobile walk-in records, and name-only phone reservations gives a vendor very little to match against, so append rates come back low and the records that do match are often the guests you already knew most about.

The second problem is that the returned fields rarely change a decision. Household income bands and lifestyle segments do not tell a host anything they can act on at 7:45pm, and they do not make a campaign better than one built on visit history and spend, which the restaurant already owns.

There is one honest exception. Business data works, because a work email domain genuinely resolves to a company. For private dining, catering, and corporate accounts, knowing that an enquiry came from a large employer three blocks away changes how the lead is handled and who follows up. Groups doing real events volume get more from company data than from consumer data by a wide margin.

Which missing fields are worth filling?

Four, and they are all operational rather than demographic.

• A reachable mobile number. It is the strongest identifier a restaurant can hold and the one that makes future matching work, aside from being the channel guests answer.
• A real email address. Behind relayed and forwarded addresses there is a mailbox the guest actually reads. Recovering it from a check, a signup, or a survey response converts a contactable record into a marketable one.
• A corrected name. Merging “J. Smith” into “Jennifer Smith” sounds cosmetic and is not, because every later match and every piece of guest-facing copy depends on the name being right.
• Occasion dates. A birthday or anniversary is the one field that generates a reason to reach out without inventing a promotion.

Everything past that tends to be interesting rather than useful. The test to apply before adding a field is whether anyone would do something differently because of it.

What are the risks of enriching a guest record?

The main risk is that enriched data gets used in service, where being wrong is visible. A guest greeted for a birthday that is not theirs, or seated by a preference that belonged to a different Jennifer Smith, has just watched the restaurant be confidently wrong about them. Marketing data can be approximate. A record the floor reads cannot.

Three practices keep it safe. Store provenance per field, so the record says where a value came from and when it arrived, and a manager who thinks it is wrong has somewhere to look. Keep stated data ahead of appended data, so a birthday the guest typed in outranks one a vendor supplied. And treat appended contact detail as a separate consent question, because a phone number acquired from a dataset carries no permission from the guest to text them, and using it that way is both a legal exposure and the sort of thing guests notice.