Most restaurant guest databases fail the same way. Someone sets up a form with fifteen fields, the floor fills in two, and nobody reads the rest. The restaurant guest data fields CRM question is really a question about restraint: which few facts will change what you do on a Friday night or in next month's email?
This post sorts the fields into three piles: capture always, capture with a reason, and skip. It also covers who types each one in and how to explain it to servers and bartenders. It sits under our guide to restaurant loyalty program software and guest data for South Jersey restaurants. Short version: five or six fields, each with an owner.
The test every guest field has to pass
Before a field goes into your CRM (customer relationship manager, the database that holds your guest records), ask three questions. If any answer is "nobody," drop the field.
- Who types it? A specific role, on a specific screen, at a specific moment. "The team" is not an answer.
- Who reads it? A host at seating, a bartender at the rail, or the person who sends your email.
- What changes because of it? A table assignment, a greeting, a message, a safety check. If nothing changes, you are storing trivia.
Every extra field also costs you at the point of capture. A host with a line at the door will skip anything that takes more than a few seconds. A form that guests abandon gives you less data, not more.
We do not have a sourced industry figure for how many captured fields restaurants actually use, so we won't invent one. The pattern we describe comes from how restaurant workflows run, not from a survey.
The fields worth capturing
Phone number and email
These are the keys to the whole record. Without them you cannot recognize a returning guest, send a reservation reminder or run a loyalty program. Capture both when you can, but treat the phone number as the primary key. At a bar or a walk-in, a phone number is usually the easier ask.
Capture consent at the same moment. Record whether the guest agreed to marketing messages, when, and where (web form, host stand, receipt QR code). A transactional message, like "your table is ready," is a different thing from a promotion. Which rules apply to each is a question for your own attorney.
One rule from the Federal Trade Commission belongs in your design: its CAN-SPAM guide says you must honor an opt-out request within 10 business days (FTC, CAN-SPAM Act compliance guide, read October 26, 2026). Your CRM needs a real unsubscribe flag that stops sends, not a note in a free-text box.
Visit dates and spend
Last visit, first visit and visit count are the most useful fields you will never have to ask a guest for. They should come from your POS (point of sale) or reservation system automatically. Staff should never type them. A restaurant CRM that ties reservations to guest profiles is built to fill them in for you.
From those three you can answer practical questions. Who came twice in the fall and has not been back since? Who is a regular on Tuesdays? Who has not visited in ninety days? Spend per visit is useful if your POS can tie a check to a guest, but it is the first field to go missing when a check is not matched to a profile. Know that gap before you build a campaign on it.
Matching checks to guests is the hard part, and it depends on which systems hold your data. Our guide to exporting guest data from your POS, delivery app and loyalty tool shows how to find out what you can pull out of each one.
Party size
Party size is worth keeping for two reasons. At booking, it drives table assignment. In the record, it tells you whether a guest tends to come as a couple, a family or a group of eight. That changes which offers make sense. A prix fixe for six means little to someone who always dines alone at the bar.
Capture it from the reservation, not from the guest profile. Store the party size per visit, with an "usual party size" you can derive later. A single fixed number on the profile goes stale fast.
Birthday: month and day only
A birthday is a legitimate reason to send one message a year, and it is a natural reason to get in touch. Ask for the month and day. You do not need the year, and asking for it makes people hesitate.
Only collect it if you have decided what you will send. If the plan is a free dessert, check that the floor can honor it and that the offer has an expiry date. If you have no plan, skip the field. We have no sourced redemption rates for birthday offers at independent restaurants, so judge the value for your own room.
Dietary notes: useful, with a safety limit
Dietary notes earn their place, and they are the field most likely to be misused. Split them into two types and store them separately.
- Preferences: vegetarian, no pork, prefers the quiet side of the room. These shape service and suggestions.
- Allergies and medical restrictions: shellfish, tree nuts, celiac. These are a safety matter.
A CRM note is guest-reported and may be out of date. It is a prompt for a conversation, not a clearance. The server still asks about allergies at every visit, and the kitchen still confirms. Write that into your training. Never let a profile flag substitute for the question at the table.
Use a short fixed list plus one free-text line, so the entry reads the same way every time. A list of "shellfish, peanuts, tree nuts, gluten, dairy, egg" scans faster than "allergic to crab I think." Whether to store health-related details at all, and for how long, is something to confirm with your own advisor.
The fields you will never use
These show up in templates and survey forms. Most restaurants should leave them out.
- Full birth date with year. You need month and day. The year adds privacy exposure and no useful action.
- Home address. Unless you deliver, it is a field you will not use. Zip code is enough to see which towns your guests come from. It also helps you decide where to run ads.
- Job title or employer. This is a B2B habit. Keep it only if you run corporate events and have someone assigned to follow up.
- Anniversary. It is the birthday idea again, with less data and more awkward questions. Capture it on a reservation note when someone mentions an occasion.
- Favorite wine, favorite cocktail, "likes loud music." Free-text preferences fill up with inconsistent notes. A handful of tags you actually use will do more.
- Social handles. Nothing in your workflow acts on them.
- Anything copied from a data broker. Guests did not give it to you, and you cannot explain to them why you have it.
If a field exists because "we might want it someday," leave it out. You can add a field later. Deleting hundreds of half-filled records is harder.
Who owns the entry on the floor
This is where most CRM projects fail in practice. The data model can be perfect, but if nobody owns each field at the moment of capture, it stays empty. Assign ownership by role and by moment.
| Field | Who enters it | When |
|---|---|---|
| Phone and email | Host or online booking form | At reservation or seating |
| Marketing consent | Booking form checkbox, or host at the stand | Same moment as the contact info |
| Visit dates, party size, spend | System, from POS and reservations | Automatically |
| Birthday (month and day) | Guest, through a loyalty sign-up or booking page | At sign-up |
| Dietary preferences | Guest at booking, or server at the table | Booking or first visit |
| Allergy flag | Server, after asking the guest | Every visit, confirmed with the kitchen |
Notice how little falls on servers. The best capture is the one the guest does themselves through a booking page, a QR code on the check or a loyalty sign-up. Staff handle only what a guest says out loud at the table. The Mother's Day piece on a booking page that collects guest data shows how a reservation form can collect consent and an occasion note without extra work for staff.
We took the same approach on the booking site and captain's CRM we built for Sand Bar Joe's. That is a charter business, not a restaurant, but the principle carries over. The customer enters their details once at booking, so the crew doesn't re-enter them on the dock.
How to explain capture to servers and bartenders
Your staff will ask the same question every time: why am I doing extra work? Answer it honestly, and keep the ask small.
Give them the reason in one sentence
Skip the talk about data. Say what it does for them: "When a regular walks in, the host sees their name and last visit, so you aren't starting cold." Or: "The allergy flag means the kitchen hears about it twice." Staff will carry out a step they can see paying off.
Give them one script
At the bar, one line is enough: "Want us to text you when we do the next oyster night? What's the best number?" That sentence asks for a number and states the purpose, but you still need the consent recorded in the system. Put the script on a card at the POS terminal. Keep it to one sentence and let a bartender reword it.
Keep the number of asks low
Staff should ask for one thing: a phone number or email. Everything else comes from the booking page or the system. If you ask a server to also collect birthdays, dietary tags and party notes, the first thing to go will be all of it.
Do not tie it to a contest at first
Some owners attach a bonus to sign-ups. That can work, but it rewards typing something, not typing a real number. Check weekly for fake entries such as 555 numbers and repeated emails. Coach on those, and fix the screen if the screen is the problem.
If you are changing the system underneath all this, do it in the off season. Our winter cutover checklist for a POS or loyalty switch covers what to freeze and test before the busy weekends.
What the data should feed
Each kept field should map to one action. Phone and consent feed reservation reminders and texts. Visit dates feed a "we haven't seen you" email. Birthday month feeds one annual message. Allergy flags feed the server's prompt at seating. For ideas on what to send once the list exists, see restaurant email marketing ideas. If you want those emails driven by the guest record, instead of a separate list that drifts out of date, that is what CRM-connected email marketing automation is for.
A field that feeds no action is a candidate for deletion at your next review. Set a calendar reminder, say each January before the spring rush, to look at which fields are less than half filled and remove them.
Where a custom guest record fits
Many off-the-shelf POS and loyalty tools give you fixed fields and charge more to add custom ones. If your list of keepers is short and specific, that mismatch matters. We build restaurant CRMs that connect reservations, guest profiles, events and follow-up, with the fields you chose. Whether to build or subscribe is a separate decision, covered in our build-versus-subscribe breakdown. Many restaurants should stay with a subscription. If you do build, the guest data belongs to you under the project agreement.
Frequently Asked Questions
What guest data should a restaurant CRM collect?
Start with phone number, email and marketing consent. Add visit dates, party size and spend automatically from your POS and reservations. Add birthday month and day only if you have an offer planned. Keep dietary preferences and allergy flags separate. Anything beyond that should have a named person who enters it and an action it triggers.
Should servers and bartenders collect guest information?
Only a little. Ask staff for one thing, a phone number or email, plus allergy confirmation at the table. Let guests enter the rest through your booking page, a QR code or a loyalty sign-up. The more you ask of staff mid-service, the less accurate and less complete the data becomes.
Do I need a guest's birth year for a birthday offer?
No. Month and day are enough to send a birthday message. The year adds privacy exposure and gives you nothing to act on, unless you serve age-restricted items and check ID some other way. Skip it, and confirm any questions about storing personal data with your own attorney.
How quickly do I have to honor a guest's request to stop marketing emails?
Every marketing email needs a working unsubscribe, and the Federal Trade Commission says opt-outs must be honored within 10 business days (FTC, CAN-SPAM guide, read October 26, 2026). Your own attorney can confirm what applies to texts and to your particular setup.
If you have a guest list full of fields nobody reads, start by listing what your team actually uses on a busy night. Tell us how your host stand, bar and booking page work today, and we will help you trim the list to what earns its place. Our custom CRM work starts from that kind of workflow review.
Sources
Every outside claim in this article links to where it came from. These open in a new tab.
- Federal Trade Commissionftc.gov
- leave it outnvlpubs.nist.gov