A restaurant's guest database: what to keep on the card

A restaurant guest card needs only the name, the phone number and whatever helps you welcome the guest better: a favourite table, preferences, staff notes and the visit history. Everything else, from a date of birth to passport details, usually only creates risks and brings no benefit. Below we look at what exactly to record, how not to turn the database into a dumping ground, and how to delete data when a guest asks.

Why a restaurant needs a guest database

Without a database, the memory of guests lives in people's heads. The manager remembers that the guest at the window table doesn't eat spicy food, but today is their day off, and a newcomer is on shift. A month later the manager leaves, and everything they knew leaves with them.

A good database solves three problems:

• a guest who comes a second time feels remembered;
• the shift works with the same information rather than with retellings;
• the owner sees who comes often and who came once.

You don't need a complex system for this. You need a card that's easy to open in five seconds while the guest is standing at the host stand.

The minimum card

Start with a short set of fields. You can always add more, but removing what you've collected and don't use is harder.

1. Name. The way the guest introduces themselves. There's no need to demand a surname.
2. Phone number. The main key: it's how you tell one guest from another and find their bookings.
3. The “regular” mark. A simple mark that a member of staff puts. More about it in the article about tracking regular guests.
4. Favourite table or zone. One line: “by the window”, “the sofa at the back”, “at the bar”.
5. Preferences. What the guest likes and asks for.
6. Staff notes. What the team needs to know.
7. Visit history. When and how many times the guest has come.

If you currently keep bookings in a notebook or in private chats, these fields already exist, just scattered. The card's job is to gather them in one place. We wrote about why paper lets you down in the piece about replacing the reservation book.

Favourite table and preferences

This is the most useful part of the card, and the easiest to record badly. Compare two entries:

• “Likes good service” (useless: everyone wants that).
• “Asks for water without ice, sits with their back to the wall, comes with colleagues on Thursdays” (you can work with this).

A good entry is specific, is about an action and helps a waiter or host do something definite. Several types of preferences worth recording:

• where they sit: the table, the zone, by the window or away from the speakers;
• what they order or turn down;
• how the visit goes: comes with children, likes a quiet evening, always runs late;
• how to address them: by first name or formally, whether a high chair is needed.

An example. A guest writes at 23:40 that tomorrow they'll come with their wife and would like “the same table”. If the favourite table is on the card, the manager or the bot doesn't ask again but checks right away whether it's free.

Staff notes

Notes differ from preferences. A preference says “what the guest likes”; a note says “what the team needs to remember”. For example: “last time waited a long time for a table, we apologised”, “nut allergy, warn the kitchen”, “was forty minutes late, we had to hold the booking”.

Rules so that notes don't turn into a diary of grievances:

• write the fact, not a judgement: “was forty minutes late”, not “rude”;
• remember that one day the guest may ask what's been recorded about them, and you must be ready to show it without awkwardness;
• don't record what has nothing to do with the visit: appearance, family circumstances, health (except allergies and restrictions the guest mentioned themselves and that affect the order).

A good test: read the entry aloud as if the guest were standing next to you. If it feels awkward, rewrite or delete it.

What's better not collected

The less data, the less responsibility. Don't ask for or keep without a real reason:

• passports and other documents (unless the law requires them for your type of venue);
• home address;
• bank card details;
• information about health, religion or political views.

A date of birth is acceptable if you really use it for a personal greeting, but even then the day and month are enough. For a restaurant guest database, contacts and habits are enough. If you're not sure whether you need a field, ask: “What will we do with this tomorrow?” No answer means the field is unnecessary.

As for personal data requirements in your country: they differ, so check them with a lawyer in your country and compare them with what you collect. This is one of the cases where you shouldn't rely on a blog article.

Merging duplicates

Duplicates always appear. A guest booked once with a number in one format, another time wrote from a different messenger or gave a different name, and the database has two people with one history. Because of this, the visits are split in half, and a “regular” guest looks like a newcomer.

What to do:

1. Look through the database periodically by phone number and by similar names.
2. Merge cards so that the visits and notes add up into one.
3. Agree who on the team has the right to merge: wrongly merging two different people is worse than a duplicate.
4. Record numbers in a single format, with the country code.

Erasing data

A guest has the right to ask you to delete everything stored about them. A venue should be able to do this quickly and completely, not “remove them from the list but leave them in the chats and logs”.

Check that you have answers to these questions:

• where exactly is the guest's data: the card, bookings, chats, notes?
• who on the team can delete it?
• how will you confirm to the guest that it's done?

If the data is smeared across spreadsheets, personal messengers and notebooks, answering will be hard. It's one more argument for gathering everything in one place, as in the case of chaos in the front desk's private chats.

How it works in GuestKeepr

In the dashboard of the GuestKeepr virtual front desk, the Guests section is built exactly as such a card: name and phone number, the “regular” mark, favourite table, preferences, staff notes and visits by day of the week. The guest's wishes are also visible on the booking card, so the host doesn't search for them in chats.

Duplicates can be merged. The owner can erase all of a guest's data completely. Venues' data is isolated from each other: your database doesn't overlap with anyone else's. A venue can also forbid the use of its conversations in anonymised form to improve the service.

The limits: GuestKeepr doesn't send anything to the guest database and doesn't keep loyalty points. It's the place where the team keeps and finds what it knows about guests. What exactly to record and which requirements apply in your country is up to you.

Frequently asked questions