Lapsed Guest

Nothing happens when a restaurant guest lapses. A subscription business gets a cancellation and a retailer gets an unsubscribe, while a restaurant gets a silence that looks exactly like a guest who is between visits. Any system reporting lapsed guests is therefore reporting the output of a rule somebody configured. That rule normally lives in a restaurant CRM, because running it at all takes visit history assembled from the reservation book and the point of sale together.

When is a restaurant guest actually lapsed?

A guest is lapsed once they pass a threshold the restaurant sets, and there are two ways to draw it.

A fixed window applies one number to everybody: no visit in ninety days, or a hundred and eighty, and the guest moves into the lapsed set. It is simple, it is comparable across periods, and it is wrong at both ends of the book. Ninety days calls an anniversary couple lapsed every single year, and it misses a bar regular who came twice a week for two years and has now been gone for a month.

A relative window measures each guest against their own interval, so lapsing means a gap several times longer than the gap that guest normally leaves. This matches how an operator thinks about it. A maître d’ does not need a policy to know that the Tuesday couple has been missing. What it needs is enough visits to establish a rhythm, and most guests in most restaurants never get there.

The workable answer is usually both at once. Guests with enough history to have a cadence get measured against it, and everyone else gets a fixed window with a longer number than instinct suggests. Choosing that fixed number from the venue’s own distribution of return intervals beats choosing it from an industry article, because a wine bar and a destination tasting room have nothing in common on this axis.

How many visits does it take before you can call a guest lapsed?

At least two, and the reason is that one visit gives you no interval to compare against. A guest with a single visit ninety days ago might be a local who did not enjoy it, a visitor from out of town who is never coming back, or somebody who eats out four times a year and is exactly on schedule. The record looks identical in all three cases.

This is why the population usually described as lapsed is really two populations that need separating. First-timers who never returned are an acquisition problem, and the useful window on them is measured in weeks rather than months. Established guests who stopped are a retention problem, and they are the more valuable group by a wide margin, since the restaurant already knows what they liked and roughly what they spent. Reports that merge the two make the lapsed list large, undifferentiated, and easy to ignore.

Why does my lapsed list include guests who came in last week?

Because the record that lapsed and the guest who returned are not connected. Three causes account for most of it.

• Duplicate profiles. The guest came back and booked with a different email address, or through a platform that supplies a masked forwarding address. A second profile started collecting visits while the first one kept ageing.
• Unmatched visits. The guest returned as a walk-in, sat at the bar, or was somebody else’s guest at a six-top. The check exists and never joined to their profile, so their last-visit date is stale rather than wrong.
• Venue scope. In a group, a guest who has switched to the sister restaurant across town reads as lapsed at the first venue and active at the second. Both statements are true, and only one of them should trigger a win-back.

The practical consequence is that a lapsed list is a report on record-keeping as much as on guest behaviour. A venue with a low match rate will generate a lapsed list padded with people who never left, and sending that list a note about how much you have missed them is the fastest way to lose a team’s trust in the data.

Can my reservation platform tell me who has lapsed?

Partly. Resy, OpenTable, SevenRooms, and Tock each hold a last-visit date built from bookings made on that platform at that restaurant, and sorting on it is a reasonable first pass. The limits are structural rather than product gaps. A booking platform sees the bookings it took, so a guest who has come back three times as a walk-in still shows the old date, and a group running two books has two partial answers with no way to reconcile them.

A point-of-sale system has the opposite half of the problem. It recorded every one of those walk-in visits and, at most venues, attached no guest identity to them. Toast and Square can pass guest contact detail on off-premise orders, so a room with heavy delivery and takeout volume has a partial route. Dine-in checks arrive without identity, and several systems pass none at all, which leaves the visit real and the guest unnamed. Determining who has genuinely lapsed means reading both sides and joining them, and that join is the specific job a guest data platform exists to do.