Guest data: what to collect and what to leave

Guest data is everything a venue knows about the people who eat with it: names, contact details, visits, spend, preferences, allergies, feedback and permission to stay in touch. Used well, it turns a restaurant into a place that remembers its guests: the regular who is greeted by name, the allergy that is never missed, the anniversary that is noticed. Used badly, it becomes a long form at booking, a database nobody trusts and a privacy risk the venue never needed to take.

The temptation is to collect everything, in case it is useful one day. That is usually a mistake. Every field asked for at booking is a reason for a guest to give up, every field stored is a field that must be kept accurate and secure, and every field held without a clear purpose is a liability under privacy law. The better question is not what you could collect, but what you will actually use.

This guide sets out the six fields of guest data that earn their place, what each one lets a venue do, the fields that mostly annoy guests, and how to collect first party data with proper marketing consent and respect for guest privacy. It covers where guest data comes from, how guest profiles should work, how long to keep data and who on the team should see it.

Guest data has three main uses. The first is service: knowing who a guest is when they arrive, what they like, what they cannot eat and how their last visit went. The second is understanding: seeing who your guests are, how often they come, what they spend and who has stopped coming. The third is communication: staying in touch with guests who want to hear from you.

Each use needs different data, and each has a different standard. Service needs accurate, current details that the team can trust at a glance. Understanding needs reliable records of visits and spend. Communication needs explicit permission. A field that does not serve one of these uses probably does not need to be collected.

Keeping the uses in mind also helps when guests ask why you need their details. "So we can confirm your booking and remind you the day before" is an answer guests accept. "For our records" is not.

First party data is information a venue collects directly from its own guests, through its own bookings, orders and conversations. It is different from data bought from others or held by a third party, such as a booking platform. First party data is usually more accurate, more relevant and, collected properly, on firmer legal ground.

It is also yours. Guest data held on a marketplace's system may not be available to you, and it may be used to promote other venues. Guest data collected through your own booking page, your own till and your own feedback forms stays with you, and builds up with every visit.

That makes the way you collect it important. Every booking, order and conversation is a chance to build an accurate, useful record, with the guest's knowledge and, where needed, their permission.

A name is the foundation of every guest profile. It lets the host greet a guest personally, lets the team recognise a returning guest, and lets every other piece of information attach to a person. Most guests expect to give their name when they book.

Ask for it in a natural way, and record it as the guest gives it. Avoid separate fields for titles or middle names unless you will use them. Allow for names from every culture, without forcing them into a first-name and surname pattern that does not fit.

Use it well. A guest greeted by name at the door, by a host who has never met them, notices. A guest whose name is misspelt on every confirmation notices too.

An email address lets you confirm a booking, send a reminder, share a link to change or cancel, and ask for feedback after the visit. With permission, it also lets you send news and offers. For most venues, it is the most useful contact detail after the name.

Verifying it, for example with a short code sent during booking, makes every later message more reliable. A booking made with a mistyped or invented address cannot be reminded or contacted, and that is often how no-shows begin.

Keep the uses separate. An email address given for a booking confirmation is not permission to send marketing. That needs a separate, explicit choice by the guest, which this guide covers below.

A phone number lets the venue contact a guest quickly when something changes: a table running late, a kitchen closure, a question about a large booking. It is also how many guests are recognised when they call to book.

Ask for it when you will use it, and make it optional if you will not. Some guests are reluctant to share a phone number, especially for a first booking. If your venue rarely calls guests, making the field optional removes a reason to abandon the booking.

As with email, a phone number given for a booking is not permission to send marketing messages.

Allergies and dietary needs are the most important guest data a venue holds, because getting them wrong can harm a guest. Recording them once, on the guest's profile, and showing them wherever the guest is served, on the booking, the table and the kitchen ticket, protects the guest on every visit.

This information is sensitive, and in some privacy regimes health-related information carries extra protections. Collect it only to keep the guest safe, store it securely, show it only to the people who need it during service, and never use it for marketing. Our guide to allergy notes covers where an allergy must appear between booking and the pass.

Always confirm allergies at the table as well, even when they are recorded. People's needs change, and a record is a prompt for the conversation, not a replacement for it.

Visits and spend are guest data that the venue records rather than asks for. Each booking, order and settled bill adds to the guest's history: when they came, with how many people, where they sat, what they ordered and what they spent. Over time, that history shows who your regulars are, who your most valuable guests are, and who has stopped coming.

It is the most useful data for understanding guests, and it costs the guest nothing to provide. It simply requires the booking, the order and the bill to be connected to the same guest profile, rather than sitting in separate systems.

Use it to recognise guests and to understand your trade, not to judge guests. A guest who visits once a year for a celebration is as welcome as a weekly regular.

Marketing consent is a guest's permission to receive marketing messages from the venue, such as a newsletter, a new menu announcement or an offer. Without it, a venue should not send marketing, and in many countries the law requires it for electronic marketing.

Ask for it clearly and separately, with a choice the guest makes actively, such as a box they tick, not one ticked for them. Record when and how they agreed, and make it easy to withdraw. Many venues ask guests to confirm by email, so the venue knows the address is genuine and the guest really wants the messages. Our guide to marketing consent collected so it holds up covers how to word it and what to keep as proof.

Consent is what turns a list of email addresses into an audience you can actually write to.

Some fields cost more than they are worth. A required date of birth at booking, a postal address for a dinner reservation, a question about how the guest heard about you, a required title, and multiple questions about preferences all slow the booking down and make guests wonder why you need to know.

Ask whether each field changes what you do. If you will not send a birthday offer, do not ask for a date of birth. If you never post anything, do not ask for an address. If you never read the answers to "how did you hear about us", do not ask. A shorter form books more tables.

Some of this information can be gathered more naturally over time. A guest who mentions a birthday when booking can have it noted. A preference for a particular table can be recorded after a visit. Nothing needs to be asked of every guest on day one.

Some of the most useful guest data is written by the team: the guest who prefers a quiet table, the regular who always orders the same wine, the anniversary they celebrated last year. Notes like these are what make recognition feel personal.

Keep notes factual, kind and useful. Write as though the guest might read them, because under privacy law they may have the right to. "Prefers a booth, likes the house red, celebrated anniversary in June" is helpful. Comments about a guest's appearance, behaviour or character are not.

Date and sign notes, so the team knows how current they are and who to ask. A note from three years ago may no longer be true.

All of this data comes together in guest profiles: one record per guest, read by the host, the server and the manager. A good profile is short, current and accurate, readable in a few seconds at the door. Our guide to guest profiles your floor team will trust covers what to show and what to leave out.

Duplicate profiles are the most common problem. The same guest books by phone with one name, online with another and orders with a third, and the venue ends up with three partial records. Merging duplicates, carefully, keeps each guest's history in one place.

Trust is the test. If the team finds that profiles are often wrong or out of date, they stop reading them, and the data becomes useless however much of it there is.

Guest privacy is both a legal duty and a matter of trust. Guests share their details expecting them to be used for the visit and, where they agree, to stay in touch. They do not expect them to be sold, shared carelessly or kept forever.

Privacy laws differ between countries, but common principles include collecting only what you need, using it only for the purposes you told the guest about, keeping it secure, keeping it accurate, not keeping it longer than necessary, and letting guests see, correct or delete their data. In the UK, the Information Commissioner's Office publishes guidance on data protection for organisations; other countries have their own regulators and rules.

Publish a clear privacy notice that explains what you collect and why, and make sure the team understands the basics.

Not everyone on the team needs to see every part of a guest's profile. A host taking a booking needs a name, contact details, any allergies and notes relevant to the visit. A manager may need visit history and spend. A marketing role needs consent status. Few people need everything.

Give access by role. Limiting who can see spend, history and feedback reduces the risk of misuse and respects the guest's privacy. It also keeps screens simpler for the people who use them during service.

Remove access promptly when someone leaves the team, and avoid shared logins, so every change to a guest's record is made by a known person.

Keep guest data only as long as it is useful and lawful. A regular's history is useful for as long as they keep visiting. A one-time guest's details from five years ago may not be. Many venues set a retention period, after which inactive guests' data is deleted or anonymised.

Marketing consent should be kept with proof of when and how it was given, for as long as you send marketing and for a period afterwards. Records needed for tax or accounting may have their own retention rules.

Write your retention rules down, apply them regularly and mention them in your privacy notice.

Groups with more than one venue face an extra question: is a guest one person across the group, or a separate record at each venue? For service, one profile is usually better. A regular at one venue who visits another for the first time can be recognised, their allergies are already known, and their history follows them.

For privacy, the group must be clear with guests that their details are shared across its venues, and why. Mention it in the privacy notice and, where it matters, at the point of collection. Marketing consent needs particular care: a guest who agreed to hear from one venue may not expect messages from every venue in the group.

Agree who in the group can see what. A manager at one venue may need to see a guest's visits there, but not necessarily their spend at every other venue.

The best guest data comes from the service itself. Bookings provide names, contact details and allergies. Orders and bills provide visits and spend. Feedback provides what guests thought. Notes provide what the team noticed. When these sources feed one profile, the record builds itself without anyone maintaining a separate list.

Avoid building guest data from sources guests did not expect, such as bought lists or data scraped from elsewhere. It is less accurate, less relevant and often unlawful for marketing.

Our guide to building a guest database from bookings you have covers how to start from the diary you already keep.

Here is an illustrative venue that reviewed its guest data. The details are examples.

The shorter form books more tables, the marketing list is smaller but every guest on it chose to be there, and the team trusts the profiles because they are accurate.

In servearound, guest profiles fill themselves from bookings, orders and checks as they happen: visits, spend, the last visit, allergies, diet and drink preferences, notes from the team with their author and date, visit history and feedback. Allergies saved on a profile show on the guest's bookings, on the table they sit at and on the kitchen ticket. Profiles that look like the same guest are flagged with how confident the match is, and merging keeps the profile you choose and moves the history across.

Guests opt in to marketing as they book and confirm it by email, and opt-in, confirmation and unsubscribes are tracked on the guest's own record. Taking a booking needs only a guest's name and number, so staff who book tables can find and add guests, while the full CRM, with spend, history and feedback, is for the roles you give it to. See the guests module.

Name, email, phone if you use it, party size, and optional allergies and occasion. Anything else should earn its place.

No. Marketing needs a separate, active choice by the guest.

Only if you will use them, and preferably as an optional field or a note when a guest mentions a birthday.

The roles that need it, usually managers. Hosts and servers rarely need spend to give good service.

As long as it is useful and lawful. Set a retention period for inactive guests and apply it.

Respond promptly, following the privacy rules where you trade. Make sure you can find all of a guest's data in one place.

Guest data should be collected for a purpose: service, understanding or communication. Six fields earn their place: name, email, phone, allergies and dietary needs, visits and spend, and marketing consent. Fields that do not change what you do mostly annoy guests and should be left out or gathered naturally over time.

Build guest profiles from the service itself as first party data, keep them accurate, merge duplicates and let the team trust what they read. Treat marketing consent as a separate, active choice, protect guest privacy with clear rules on access and retention, and remember that a short, accurate record used well is worth far more than a long one nobody reads.