Building a guest database from bookings you have

Building a guest database sounds like a project that starts with a blank spreadsheet and a campaign to collect email addresses. For most venues, it does not need to. Every booking already holds a name, a contact detail, a date, a party size and often a note. Every bill holds what was spent. The raw material of a guest database is already in the diary and the till; it simply has not been brought together.

Starting from the bookings you have is faster and more accurate than starting from scratch. The guests are real, the visits happened, and the details were given for a reason. But the data is usually messy: the same guest under three spellings, phone numbers in different formats, notes scattered across systems, and no record of who agreed to hear from you. Using it well means cleaning it first, then sorting out consent, and only then putting it to work.

This guide sets out how to build a guest database from the bookings you already have, in the right order: gathering the data, cleaning it, merging duplicate guest records, connecting visits and spend, sorting out marketing consent, and using the result for service and, where guests agree, for marketing. It also covers what not to do, and how to keep the database healthy once it exists.

The booking diary is the best source of guest data most venues have. Guests give their details when they book because they want a table, so the information is usually accurate. Each booking also records a visit: who came, when, how many and, often, what they needed. Over months and years, that adds up to a detailed picture of who your guests are.

It is also first party data: information collected directly from your own guests, through your own service. That makes it more relevant than any list you could buy, and, handled properly, on firmer ground under privacy rules. Our guide to guest data covers what to collect and keep.

Starting from bookings also means the database reflects reality. The guests who appear most often are your regulars. The guests who stopped appearing are the ones who lapsed. No survey can tell you that as reliably.

Start by listing every place guest data lives. The booking system, past and present. The till or point of sale, if it records guests. A paper diary, if you still use one. Spreadsheets of event bookings. Email inboxes with enquiries. Feedback forms. A list of newsletter subscribers. Delivery platform exports, if they include guest details you are permitted to use.

For each source, note what it contains, how far back it goes and under what terms the guests gave their details. That last point matters: details given for one purpose cannot always be used for another.

Do not try to combine everything at once. Begin with the booking system, which is usually the largest and most reliable source, and add others once the core is clean.

Booking data is rarely clean. Names are spelt differently, sometimes in capitals, sometimes with titles. Phone numbers appear with and without country codes. Email addresses contain typos. Notes are inconsistent. Some bookings were made under a company name or a nickname.

Clean the basics first. Standardise the format of phone numbers and email addresses, correct obvious typos, and separate names into a consistent format where possible. Remove test bookings, internal bookings and clearly fake entries.

Do not over-clean. If you are not sure a correction is right, leave the original. A record that is slightly untidy is better than one confidently changed to something wrong.

Duplicate guest records are the biggest problem in most booking data. The same guest books by phone as "Mr Smith", online as "John Smith" and at the door as "John", and the database holds three people where there is one. Each holds part of the guest's history, and none shows the full picture.

Find likely duplicates by matching on the strongest identifiers: the same email address or the same phone number are strong signals; a similar name alone is weaker. Review possible matches before merging, especially those based only on names. Two different people called James Brown may share nothing else.

When you merge, keep the most accurate details from each record, and bring the visit history together. Record that the merge happened, so it can be checked later. Once merged, a guest's history becomes far more useful.

A guest database becomes much more useful when each guest's visits are connected to what they spent. Bookings show that a guest came; bills show what the visit was worth. Together, they show who your most valuable guests are, who visits often and spends little, and who visits rarely but celebrates generously.

Connecting the two depends on the bill being linked to the booking or the table. If your booking system and till are separate, that link may be missing for past visits. Going forward, choose systems that connect them, so every visit adds both a date and a spend to the guest's record.

Use visits and spend carefully. They help you understand your trade and recognise guests, not rank them by worth in front of the team.

This is the step most often skipped, and the one that matters most legally. Having a guest's email address because they booked a table does not mean they agreed to receive marketing. In many countries, sending marketing emails without proper consent breaks the law, and in all of them it damages trust.

Look at each source and ask: did these guests actively agree to receive marketing from us, and can we show when and how? Guests who ticked a clear box to receive news, with a record of it, may be on solid ground. Guests who simply booked a table usually are not.

For guests without proper consent, do not send marketing. Instead, invite them to opt in the next time they book or visit, with a clear choice and a confirmation. Our guide to marketing consent collected so it holds up covers how to ask and what to keep as proof.

The first use of a guest database is service, not marketing. Once records are clean and merged, the team can recognise returning guests when they book, see their allergies and preferences, and greet regulars by name. That needs no marketing consent, because it is part of serving the guest who chose to book.

Make guest records visible where the team works: at the host stand, on the booking list and on the table during service. Our guide to guest profiles your floor team will trust covers what to show and how to keep it trustworthy.

Allergies deserve special attention. Recorded once on the guest's profile, they can appear on every future booking, table and kitchen ticket, which makes every future visit safer.

Even before any marketing, a clean guest database tells you things about your trade that are hard to see any other way. How many distinct guests you served last year. How many of them came more than once. How often your regulars visit, and how many of them have not been back for several months. Which days and services your most frequent guests prefer.

These numbers are often surprising. Many venues find that a relatively small group of regulars accounts for a large share of their visits, and that a noticeable number of former regulars have quietly stopped coming. Both findings are useful: the first tells you whom to look after, the second whom to welcome back.

Look at the numbers with the team. Knowing that a few hundred regulars carry the venue makes recognising them at the door feel important rather than optional.

Many venues have years of bookings in places that are hard to use: a paper diary, a booking system that has since been replaced, or spreadsheets kept for events. It is tempting to type all of it into the new database. Usually, it is not worth it.

Old records are often incomplete, hard to read and collected under different terms. Typing in thousands of paper bookings takes a long time and produces data that is less reliable than what the new system will gather on its own within a few months. Focus instead on the recent past and on the guests who matter most, such as regulars whose allergies and preferences the team knows.

If an old system can export its data in a usable format, import what is reliable and recent, check it, and leave the rest.

Event and group bookings carry valuable guest data, but they need care. The organiser of a private party or a corporate dinner is a guest worth knowing: they bring large groups and often book again. Their details, history and preferences belong in the database like any other guest's.

The other guests at an event are different. The organiser may have given a list of names or dietary needs, but those guests did not book themselves and did not agree to anything beyond the event. Use their details for the event, especially allergies, and do not add them to marketing lists.

Record events on the organiser's profile, with notes about what worked, so the next booking is easier.

A guest database is only as good as the details captured at each booking and visit. Train the team to ask for the essentials, confirm phone numbers and emails, check allergies and note anything useful the guest mentions. A few seconds at booking saves a great deal of clean-up later.

Make it part of the routine rather than a separate task. The host confirms details as the guest arrives; the server notes a preference after the meal; the manager reviews new notes weekly. Each habit is small, and together they keep the database accurate.

Explain why it matters. A team that understands that accurate records keep guests with allergies safe and help regulars feel recognised is far more likely to capture details carefully.

Track a few simple measures to see whether the database is improving: the number of distinct guests, the share of bookings attached to an existing guest rather than creating a new one, the number of possible duplicates waiting to be reviewed, and the number of guests who have confirmed marketing consent.

Watch the share of bookings that match an existing guest especially closely. If it rises, the team is finding returning guests at booking; if it stays low, duplicates are still being created. Review the measures monthly, and fix whatever is slipping.

Once you have guests who have properly agreed to hear from you, the database becomes the basis for marketing. You can write to regulars, to guests who have not visited for a while, to guests who celebrated with you last year, or to guests who prefer weekday lunches, with messages that suit each group.

Start small. A short, well-written email to a few hundred guests who chose to hear from you will usually do more than a large send to a list of uncertain origin. Measure what happens: who opens, who clicks, who books.

Respect unsubscribes immediately, and record them on the guest's record so they are never mailed again by mistake. Our guide to guest segments covers which groups are worth writing to and what to say.

Some shortcuts cause lasting problems. Do not import a bought list into your guest database; the people on it did not choose you, and marketing to them is often unlawful. Do not add guests' details from delivery platforms unless the platform's terms and the guest's consent allow it. Do not treat every email address in your inbox as a subscriber.

Do not keep everything forever. Data from guests who visited once, many years ago, may no longer be useful, and keeping it adds risk without benefit. Set a retention period and apply it.

And do not let the database become a separate project that never connects to service. A guest database that the floor team never sees is a mailing list, not a guest database.

A guest database starts to decay as soon as it is built. Guests change email addresses, move away, develop new allergies or stop visiting. New duplicates appear as guests book through different channels. Notes go out of date.

Build habits that keep it healthy. Match returning guests by phone or email when they book, so new duplicates are not created. Review possible duplicates regularly. Ask the team to update profiles when guests mention changes. Review notes on frequent guests monthly, and remove what is no longer true.

The best protection is a system where the database is filled by the service itself, so every booking, order and bill updates the right guest automatically, rather than a list someone has to maintain.

Every step involves personal information, and guest privacy should guide each one. Collect only what you need, use it only for the purposes guests would expect, keep it secure and accurate, and give guests a way to see, correct or delete their data. Publish a clear privacy notice that explains what you hold and why.

Privacy rules differ between countries. In the EU, the General Data Protection Regulation sets the framework; the UK and the UAE have their own laws, and other countries have rules of their own. If you are unsure what applies, take advice before using guest data for marketing.

Limit who can see what. Hosts need names, contact details, allergies and notes; spend and full history are usually for managers.

Here is an illustrative venue building its guest database from five years of bookings. The figures are examples.

The database started from bookings the venue already had, and grew properly from there.

In servearound, the guest database is built by the service itself. Taking a booking by phone number finds the returning guest and saves what you note to their profile, checks settled at the table add to the guest's visits and spend, and orders from their phone join their profile. Profiles that look like the same guest are flagged with how confident the match is and why, such as the same email or phone number, and merging keeps the profile you choose and moves the reservations, orders and feedback across, recorded in the profile's history.

Guests opt in to marketing as they book and confirm it by email, and only confirmed subscribers are ever mailed by Campaigns, with unsubscribes recorded on the guest's own record. See the guests module and Campaigns.

Usually not for marketing. A booking is not consent to marketing. Invite guests to opt in instead.

Match on email address and phone number first, then review possible matches before merging.

Only if you can show that the people on it agreed to receive your marketing. If not, invite them to opt in again.

The first clean-up can take a few days of careful work. After that, a system that fills the database from the service keeps it current.

Service: recognising returning guests and knowing their allergies and preferences.

Match guests when they book, merge duplicates regularly, review notes and let the service update the records automatically.

Yes, where they give their details, for example when they join the waitlist or pay. Every visit attached to a guest makes their record more complete.

Often more so. A small venue's regulars are a large share of its trade, and knowing them well is one of its biggest advantages over larger competitors.

Building a guest database works best from the bookings you already have. Gather your sources, clean the basics, merge duplicate guest records carefully, and connect visits to spend. That gives you accurate first party data about your real guests, without starting from scratch.

Then sort out marketing consent before sending anything: a booking is not permission to market. Use the database first for service, then for marketing to guests who chose to hear from you. Respect guest privacy throughout, avoid bought lists, and keep the database healthy by letting the service itself keep each guest's record current.