Almost every group we speak to is sitting on years of guest history and using close to none of it. The reason is rarely indifference. It is that nobody has ever established what is actually there.
This is a checklist for doing that. It takes most operators an afternoon per system, and it is worth doing before you evaluate any software — including ours — because it tells you whether your problem is tooling or hygiene.
Start with an inventory, not an export
Before downloading anything, write down every place a guest fact could live. Most groups underestimate this list by half.
- Reservation platform, per location — different sites often run different platforms after an acquisition.
- POS, per location. Same caveat, more often.
- Google Business Profile and any other review platform you monitor.
- Email or SMS tool, including the one nobody has logged into since last year.
- Spreadsheets. Ask directly — there is always at least one, usually maintained by whoever cares most.
- Paper. VIP lists behind the host stand and allergy notes in a binder are real data and they are the hardest to recover.
- Staff memory. Not recoverable, but worth naming so people understand what walks out when someone leaves.
For each system, answer five questions
The point is not a complete map. It is to know, per system, whether what is inside can be joined to anything else.
- How far back does it go? Platform migrations often quietly truncate history.
- What identifies a guest? Email, phone, both, or a system-specific ID. This is the one that decides everything downstream.
- Can you export it yourself, without contacting support?
- What is filled in? Not what fields exist — what percentage of rows actually have a phone number.
- Who owns it? A named person, not a department.
Measure fill rate, because it decides what is possible
Export one system. Count the rows. Then count how many have a usable email address, and how many have a usable phone number. Two numbers, ten minutes, and they determine everything you can do afterwards.
The result is often uncomfortable. Reservation platforms capture contact details well; POS systems frequently do not capture them at all unless a guest joined a loyalty scheme or asked for a digital receipt.
Email fill rate = rows with a valid email ÷ total rows Phone fill rate = rows with a valid phone ÷ total rows Joinable rows = rows with at least one of the two Joinable rows is your real ceiling. Everything else is anonymous covers — useful for forecasting, useless for recognising anybody.
Look for the duplicates before you look for anything else
Sort an export by name and read it. You will find the same person three times: once with a work email, once with a nickname, once with their partner's phone number.
Do not fix these by hand and do not let any tool merge them automatically on name alone. Two guests called John Smith at the same group is completely ordinary, and a wrong merge destroys both histories in a way you cannot undo.
What you are looking for at this stage is scale. Roughly what proportion of your list is duplicated? That number tells you whether identity resolution is a nice-to-have or the entire project.
Check consent while you are in there
For every contactable guest, you need to know whether you are actually allowed to contact them, per channel, and where that permission came from.
Most groups discover that consent lives in whichever email tool sent the last campaign, and that nothing records what a guest said to a host in person. That is a real gap, and it is worth knowing about before you send anything rather than after.
What good looks like at the end
You are not aiming for a clean database. You are aiming for an honest one-page summary you could hand to a vendor or a new director of marketing.
- A list of every system holding guest data, with an owner's name against each.
- Per system: date range, identifier available, export method, fill rate.
- A rough duplicate rate.
- A clear statement of where consent is recorded, and where it is not.
- One sentence on what you cannot currently answer — usually "we cannot tell whether a guest has been to more than one of our restaurants."