Guest Profile

Almost every system a restaurant runs keeps some kind of guest profile, which is why the term causes confusion. Resy, OpenTable, SevenRooms, and Tock all maintain a guest record. So does a point-of-sale system with a loyalty module, and so does an email platform. Each one is a real guest profile. Each one is also partial, because it only contains what that system happened to see.

Where does a guest profile actually live?

There are two answers, and the difference between them is the whole subject.

Inside a single product, a guest profile covers that product’s own activity. A guest’s OpenTable record holds the bookings they made through OpenTable. It is accurate and it is useful at the host stand. It does not know what the table spent, what the guest wrote in a review, or that the same person booked a private dinner through Tripleseat last spring.

Inside a restaurant CRM, a guest profile is the record that spans systems. It is built by reading the reservation platforms, the point of sale, reviews, events, and messaging, then resolving those separate records into one person. That is a different object from any single system’s profile, and it is the one an operator means when they talk about knowing their guests.

What is on a profile that spans systems?

Each connected system contributes a part of the picture:

• Reservations contribute visit counts, party sizes, no-shows, booking notes, and which venue in a group the guest favours.
• Point of sale contributes spend and, where the integration allows, the items ordered.
• Reviews contribute what the guest said publicly.
• Private events contribute the parties a guest hosted, often the largest single spend on the record.
• Messaging contributes what the guest was sent and what they answered.
• Hotel and retail systems, in groups that run them, contribute stays and purchases.

A profile is therefore only as complete as its connections. A restaurant with reservations connected and no point of sale has a profile that knows how often a guest comes and nothing about what they spend.

What can you do with a profile that a reservation platform cannot?

This is where the depth becomes practical rather than theoretical. A restaurant CRM adds capabilities that a single system’s guest record cannot support, because they all depend on data from more than one place:

• Tags derived from spend and menu items, such as recognising the guests who order heavily from your wine list, which requires point-of-sale detail a reservation platform never receives.
• Segments that combine sources, such as guests who dined three times and also hosted an event, or regulars who have not returned in ninety days.
• Journeys triggered by behaviour, where a first visit or a lapse sets off a sequence of email and SMS.
• Spend broken out by type, so dining, private events, catering, retail, and hotel stays are visible separately on one record.
• Recognition written back into the book, so a tag or a note created in the CRM appears on the reservation in Resy or OpenTable, where the host will actually see it.
• Group-wide identity, so a regular at one venue is recognised at a sister restaurant instead of arriving as a stranger.

What makes a guest profile trustworthy?

Three things, and a team notices at once when any of them slips.

Identity. If duplicate records are not resolved, a four-visit regular looks like four first-timers, and nothing built on the profile can be believed.

Coverage. Every unmatched check and unidentified walk-in is a gap. A profile assembled from 60% of a restaurant’s volume is describing a guest from 60% of the evidence.

Freshness. A profile is only useful if it reflects last night. Reservation changes usually arrive within moments, while point-of-sale data more often arrives on a scheduled import, so a profile is best understood as continuously updated rather than instant.