Lifetime Value (LTV)

Lifetime value arrived from subscription and e-commerce businesses, where every transaction carries an account and the arithmetic is close to automatic. Restaurants inherited the term without that condition. A dining room’s transactions are checks, most checks are settled with no name attached, and the guest never had an account. LTV in hospitality is therefore produced by a restaurant CRM after it joins checks to bookings and both to a guest profile.

How do you calculate lifetime value for a restaurant guest?

Almost always as a historic sum: every matched check on the guest’s record, plus their spend on private events, catering, retail, and hotel stays where the group runs those lines. Predictive LTV, the forecast of future spend, belongs to retail modelling and is rarely worth the complexity for a single venue.

The harder question is whose revenue a check represents. One guest books a table for six and pays the whole bill. Assigning that check to the booker credits them with five other people’s dinners, and splitting it across a party the restaurant cannot identify is not possible. Most platforms assign the check to the matched guest, so a restaurant’s LTV is best read as revenue that guest was present for and settled. It stays decision-useful, and it explains why frequent hosts and business bookers sit at the top of the list.

A group running several revenue lines should also see them broken out rather than summed. Loyalist reports dining, event, catering, retail, and hotel spend separately on one profile. An events-heavy guest then reads as an events-heavy guest instead of as a large total.

Why does lifetime value undercount a restaurant’s best guests?

Because every unmatched visit is missing revenue, and the misses are not randomly distributed. The visits hardest to attach to a guest are walk-ins, bar seats, and covers where somebody else made the booking, and a restaurant’s heaviest users do more of all three. So the undercount is largest on exactly the guests the number exists to identify.

LTV should be treated as a floor, and the floor rises whenever a venue improves its match rate, including for nights that have already happened. Fragmented identity compounds the error a second way: a guest split across three profiles has their spend split across three profiles, and each fragment reads as an ordinary guest.

What decisions actually use LTV?

Four, and all of them are judgment calls made under time pressure. Whether to comp a course when something went wrong, since a course costs almost nothing against several years of Friday nights. Who gets the last table on a full Saturday. How much outreach a lapsed guest justifies. Whether a private-event enquiry from a known name deserves a call first.

None of those need a precise figure. A rough tier changes the answer, and a team that can see a guest sits in the top band of the guestbook handles a service recovery differently from a team looking only at tonight’s check.