Owning your guest data when you switch systems

A restaurant decides to change its booking system. The new one is better in every way, and the contract with the old one ends next month. The owner asks the old provider for an export of the guest list. It arrives as a file with names and email addresses, but no visit history, no allergies, no notes and no record of who agreed to receive marketing. Ten years of knowing the venue's guests have been reduced to a list of addresses.

Owning your guest data sounds simple until you try to move it. Most systems can hold a great deal about your guests, but far fewer let you take all of it with you, in a form another system can use. The time to find that out is before you sign, not when you are leaving.

This guide covers what owning your guest data really means, the export to test before signing anything, the fields that usually do not come across, how to plan a move so your guests come with you and the questions to ask any provider. Every venue and figure in it is an example.

Owning your guest data means three things. You can see all of it: every guest, every visit, every preference. You can use it: for service, for campaigns, for reports. And you can take it with you: in a complete, usable form, if you change systems.

Many venues have the first two and assume the third. The guest list feels like theirs because they built it, but whether they can take it with them depends entirely on the system holding it.

Switching systems is when ownership is tested. The old provider has little reason to make leaving easy, and the new one can only import what you bring. If the export is incomplete, the history is lost, and the new system starts with a list of names that tells it little.

That loss has a cost. Regulars are no longer recognised, allergies have to be asked again, the record of who agreed to marketing is gone and years of visit history disappear. Our guide to first party data: the list nobody can take away covers why the list is worth so much.

Before signing with any system that will hold your guest data, ask for a sample data export, and look at it. Does it include every guest? Every visit, with dates and party sizes? Allergies and dietary needs? Notes? Marketing consent, with when it was given? Spend?

Ask in what form it comes: a spreadsheet you can open, a format another system can read, or something only the provider's own tools understand. Ask whether you can run it yourself, at any time, or whether you must ask and wait.

If the provider cannot show you a sample, treat that as an answer.

Some fields are often left out of exports. Visit history is the most common: many exports give you guests but not their visits. Notes from the team, allergies and preferences are often missing or flattened into a single text field. Marketing consent is often exported as a simple yes or no, without when or how it was given, which may not be enough to rely on.

Spend and order history are frequently left behind, because they live in the till rather than the guest records. Tags and segments may not come at all.

Ask about each one specifically. A general "yes, you can export your data" often means only names and contact details.

When a sample export arrives, read it properly rather than glancing at it. Open it in a spreadsheet and check each column against what you expected. Are the dates in a usable form? Are allergies in their own column, or mixed into notes? Are guests with more than one visit shown once, with their visits elsewhere, or several times?

Count the rows and compare them with the number of guests the system says you have. A large difference means either duplicates or missing guests, and either needs explaining.

Ask someone who will use the data in the new system to look at it too. They will spot gaps you might miss.

Marketing consent is the field that matters most when you move. If you cannot show that a guest agreed to receive marketing, you may not be able to email them from the new system, however long they have been on your list.

Make sure the export includes, for each guest, whether they agreed, when and how. If the old system cannot provide it, you may need to ask guests again for their consent after the move. Our guide to marketing consent, collected so it holds up covers what a good record looks like.

Guest data often lives in more than one place. Bookings, preferences and notes may be in the booking system; orders, spend and payments in the till. When you switch one of them, ask what happens to the link between the two.

Pos data, the record of what each guest ordered and spent, is valuable for understanding regulars, but it is often the hardest to move, because it is tied to the till's own menu and records. Decide what you need to keep and what can stay behind as an archive.

Booking platforms are a special case. Guests who booked through a marketplace may be the platform's guests as much as yours. The platform may share their details for each booking, but not let you export them as a list, or only with conditions.

Read the platform's terms before you rely on it, and make sure guests who book directly are recorded in your own system. Our guide to booking platforms: what you rent and what you own covers the difference.

Many venues hold guest data in more than one place: a booking system, a till, an email tool, a loyalty scheme, a spreadsheet kept by the manager. When you switch one system, the others may hold pieces of the same guests.

List every place guest data lives before you plan the move. Decide which system will hold the main record afterwards, and how the pieces will be brought together. Without a plan, the new system starts with one piece and the others stay scattered.

Moving systems is often the best chance to bring the pieces together, if you plan for it.

Plan the move of guest data as carefully as any other part of a switch. Export from the old system before the contract ends, check the export for completeness, clean it, then import it into the new system and check again.

Allow time for each step. An export that arrives on the last day of the contract, with fields missing, leaves no time to fix anything. Our guide to POS migration without losing a Saturday covers the wider plan.

Moving systems is a good moment to clean the list. Merge duplicate guests, remove addresses that bounce, drop guests with no contact details and no visits, and update preferences that are out of date.

A clean list of a few thousand guests is more useful in the new system than a messy one of ten thousand. Our guide to duplicate guest records and how to merge them covers the duplicates.

Guests rarely need to know that you have changed systems, but some things may change for them: a new booking page, a new confirmation email, a request to confirm that they still want to hear from you. Tell them clearly and briefly, where it affects them.

If you need guests to confirm their marketing consent, explain why in plain words, make it easy and do not keep asking those who do not respond. A guest who chooses not to confirm should be treated as not having agreed.

Update your booking links everywhere guests find them: your website, your search listing, your social profiles and printed materials.

After importing, check that the data arrived as intended. Look up a few regulars and compare their profiles with the old system. Check that allergies, preferences and notes are in the right fields. Check that marketing consent is recorded correctly, so nobody is emailed who did not agree.

Fix problems before the old system is switched off, while you can still go back to the source.

Keep a complete archive of the old data, stored securely, even after the move. You may need it to answer a guest's question, settle a dispute or check a record the new system did not import. Keep it only as long as you have a reason and the rules allow.

An archive you can open without the old system, such as a set of spreadsheets, is far more useful than one that needs software you no longer have.

Under data protection rules in many countries, the venue is responsible for the guest data it collects, even when a provider holds it. That means the venue must know where the data is, how it is protected and what happens to it when the contract ends.

Ask each provider how they protect the data, where it is stored, who can access it and how they will delete it when you leave. Make sure the contract says so. A provider who cannot answer clearly is a risk to the venue as well as to its guests.

When you leave, ask for written confirmation that your data has been deleted, once you have a complete copy.

In many countries, guests have rights over their own data, including the right to see what you hold about them and, in some cases, to receive it in a portable form. The idea of data portability applies to businesses moving between systems too: your data should be able to move with you.

A system that makes it hard to get data out may also make it hard to answer a guest's request about their own data. That is worth considering when you choose.

Before signing, ask every provider the same questions about guest data:

Write down the answers. They tell you whether the guest list will truly be yours.

Ask these questions at the start, before signing, when the provider is keen to win your business and the answers come easily. Asking when you are about to leave is too late: the provider has less reason to help, and you have no time to find another way.

Ask again every year or two. Systems change, and an export that was complete when you signed may have changed since.

The easiest way to own your guest data at the moment of switching is to own it from the start. Choose systems that let you see, use and export your data. Keep your own archive of anything you import. Record marketing consent properly, with when and how it was given.

Check every year that you could still leave with your data if you needed to. Systems change, and an export that was complete when you signed may not be now.

A venue that treats its guest data as its own from the first day never faces the moment of discovering that it was not.

The best exports are the ones you can run yourself, at any time, without asking. A system that lets you download your guest list from its own screens, whenever you like, gives you control. One that requires a request to support, a wait and sometimes a fee gives the provider control.

Ask whether the export is available to you directly, and test it during a trial. Run it more than once, and check that it gives the same complete result each time.

Even if you never plan to leave, a regular export of your own data is a sensible backup, kept securely in case something goes wrong.

Sometimes the old provider is slow to provide an export, or provides one that is incomplete. Ask in writing, early, with a clear list of the fields you need and a date. Keep a record of every request and every reply.

If the contract gives you a right to your data, refer to it. If the export is still incomplete, ask what is missing and why. Most providers respond to a clear, polite and persistent request.

Do not let the contract end before you have what you need. Once access is switched off, getting the data out becomes much harder.

Before importing your guests into a new system, read the new provider's terms on data. Will the data remain yours? Can you export it again later, completely? Will the provider use it for anything else, such as marketing its own services?

The questions you asked of the old provider apply to the new one too. A switch is the moment to make sure you will never be in the same position again.

Choose a provider whose answers you would be happy to rely on the day you decide to leave.

Before relying on the new system, test it with real guests. Look up a dozen regulars after the import and check that their history, preferences, allergies and consent all appear as they should. Make a test booking for one of them and check that their allergy shows on the booking and the kitchen ticket.

Problems found in a test are easy to fix. Problems found when a regular with a severe allergy arrives on a busy Friday are not.

An invented bistro plans to change its booking system. Before signing with the new provider, the owner asks the old one for a full export. It contains names and emails only. The owner asks specifically for visit history, allergies, notes and consent, and learns that only visits can be added, at a fee.

The owner pays for the fuller export, cleans it, merges duplicates and imports it into the new system, which takes guests from a spreadsheet. Because the old consent records were only yes or no, the bistro sends a short email to past subscribers asking them to confirm they would still like to hear from it, and records the answers.

Most of the history moves across. The regulars are recognised from the first night, and the bistro asks its new provider the same export questions before signing, so the next move will be easier.

In servearound, guests can be brought in from an Excel or CSV file, using servearound's template, after confirming that the list is of guests who visited or booked and was not bought, and imported guests are not signed up to marketing emails, so consent is asked for again rather than assumed. From then on, every booking, order and check adds to each guest's profile.

Guests cannot be exported from servearound today, so ask about it before you plan around it, and keep your own archive of anything you bring in. Bills for any range of dates can be downloaded as a spreadsheet. To talk through moving your guests, see pricing or get in touch.

Being able to see it all, use it and take it with you, complete and usable, if you change systems.

A sample export: every guest, with visits, preferences, allergies, notes, spend and marketing consent.

Visit history, notes, allergies, detailed consent records, spend and tags are often missing.

Without a record of when and how a guest agreed, you may not be able to email them from the new system.

They may be the platform's guests as much as yours. Check the platform's terms.

Yes. Merge duplicates, remove dead addresses and update old preferences.

Keep a secure archive for as long as you have a reason and the rules allow.

Before signing, and again every year or two.

Owning your guest data means being able to see it, use it and take it with you. Test a sample data export before signing anything, and ask specifically about visits, allergies, preferences, notes, spend and marketing consent, because those are the fields most often left behind.

Plan the move early, make sure consent travels with when and how it was given, clean the list before importing, check the import against the old system, keep a secure archive and ask every provider the same questions about exports, before you sign and every year or two after.