Match Rate

Match rate is a restaurant CRM’s own report card. It measures how much of what happened in the dining room the system could attribute to a person. Ask about it before trusting any other guest number a platform reports.

What does a match rate measure?

A match rate measures successful joins. The denominator is the volume a restaurant produced, usually checks or covers for a period. The numerator is how much of that volume ended up attached to a guest profile. Three hundred of five hundred checks linked is a 60% match rate, and two hundred checks that belong to nobody.

It is narrower than identity resolution. Identity resolution is the whole problem of recognizing that several records describe one person. Match rate is the measurable outcome: did this check find its guest.

Why does match rate matter?

Match rate matters because every other guest metric is calculated over matched records only. It quietly sets the limit of what a restaurant can see about its own guests. Repeat rate, visit frequency, lifetime value, and campaign results are all computed on the matched share. A venue at 60% is describing its guests using three fifths of the evidence.

The distortion runs one way. Unmatched volume looks like absence, not like error. So a restaurant with a low match rate reads as having fewer regulars, lower guest value, and weaker campaigns than it really has. Nothing in a dashboard flags this. The numbers just come back smaller, and nobody has a reason to doubt them.

Can my POS or reservation platform tell me my match rate?

No, and the reason is structural rather than a gap in either product. A match rate needs both sides of the join at once. A point-of-sale system knows every check but not who booked. A reservation platform knows every booking but not what the table spent. Each reports its own volume accurately. Neither can report how much of it belongs to a known guest.

Match rate only exists once something sits above both systems and reconciles them. That is why it usually appears for the first time when a restaurant adopts a guest data platform. Operators are often surprised by the first number they see. Usually the match rate did not get worse. Nothing was measuring it before.

Why is my match rate low?

There is no universal good match rate, so the useful comparison is a venue against its own history, or against venues running the same service model. A 55% bar and an 85% tasting-menu room can both be performing as well as they can. Four things explain most of the gap:

• Reservation share. A venue where most covers are booked has records to match against. A bar or counter-service room does not, so its ceiling is lower no matter what platform it runs.
• Table naming. When the point-of-sale floor plan and the reservation book use different names for the same table, the join fails immediately. This is the most common fixable cause.
• What the POS sends, and for which orders. Dine-in checks almost never carry guest identity, whatever the product. Toast and Square can pass guest contact detail on off-premise orders, meaning delivery, takeout, and online, because those orders have an account behind them. A dine-in check is anonymous at source, so on-premise matching still runs on table and time. Lightspeed, SpotOn, Silverware, and Oracle Simphony send the check with no guest attached at all.
• Party behaviour. Split checks, transferred bar tabs, and one check covering two tables all break the one-reservation-to-one-check assumption the join depends on.

None of these are fixed limits, though not every platform lets you do much about them. Loyalist holds a match configuration per venue, so the join is tuned to how a specific restaurant runs its floor rather than to a default. Table-name mappings, the time window, and whether to match on email when the POS supplies it are all set per restaurant. Two venues in the same group with different floor-plan conventions end up with different configurations, and that difference is usually what separates a 60% venue from an 85% one.

How do you improve a match rate?

Three moves, cheapest first.

Map the table names. Most low match rates at reservation-heavy venues trace back to a floor plan that says T12 on one screen and Patio 2 on the other. You can rename tables in both systems, but the faster route is a mapping in the CRM that tells it those two names are the same table. Either way it recovers checks that were always joinable.

Widen the time window. The join allows a check to sit some distance from its reservation time, and that distance is a setting. Guests sit late and linger. A window drawn tightly around the booking time will orphan checks from parties that genuinely showed up.

Backfill. A match rate is the product of a rule, not a fact about the past. Improve the rule, rerun it against earlier dates, and history that was already in the building comes back. Operators rarely expect this part: raising a match rate works retroactively, so last quarter’s anonymous covers can become guest history this week.

Loyalist runs this join continuously, reports what did not land, and exposes the configuration behind it. The configuration is the part that matters. Most of the gap between 60% and 85% is settings nobody has looked at yet rather than data a restaurant never had.