Preference Tag

Guest tags in a restaurant CRM fall into two families that behave nothing alike. Behavioural tags are derived, so a rule reads the reservation and point-of-sale history and applies the label to whoever matches. Preference tags are told to you. Somebody heard the guest say it, or the guest typed it into a booking, and a person put it on the record. Reservation platforms and restaurant CRMs both hold this kind of tag, and the difference in how the two families are maintained is the reason preference tags need their own handling.

What guest preferences are worth recording?

A preference is worth recording when somebody would act on it before or during a service. That test rules out most of what a team notices in a night and leaves five categories that earn a permanent place on the record.

• Seating. The banquette, the corner, away from the kitchen door, never the bar.
• Dietary and allergy. The one category where accuracy is safety rather than polish, and the one that belongs on the record in a form nobody can miss.
• Beverage. A wine style, a spirit, a no-alcohol household, the bottle they asked to be held.
• Service style. Pace, courses coursed out or brought together, a table that wants to be left alone, a guest who wants the sommelier.
• Occasion and relationships. The anniversary date, the business host who always picks up the check, the guest who arrives with their parents.

Everything else is a note. A guest mentioning that they liked the halibut is colour, and putting it on the profile as a tag creates a label nobody will ever filter on.

Where does a preference tag come from?

Preference tags come from three places, and only two of them produce a real preference. A guest states it directly, through a booking note, a form, or a reply to a message. A staff member hears it at the table and records it afterwards. Both of those are the guest’s own words, which makes a preference tag zero-party data in the strict sense: volunteered rather than observed.

The third source is inference from order history, and it produces something weaker. Point-of-sale item detail shows what was ordered on a check, not who at the table ordered it or why. A couple who took the tasting menu for an anniversary are not tasting-menu guests, and a table that ordered two bottles of Barolo may have had one guest choosing for five. Behavioural signals are genuinely useful for segments and campaigns. They are a poor foundation for a claim about what somebody prefers, and a restaurant that mixes the two families under one tag list loses track of which of its labels the guest would actually recognise.

Do preference tags follow a guest between venues and platforms?

Within one reservation platform, a preference recorded on a guest record is there the next time that guest books through the same platform at the same restaurant. Resy, OpenTable, SevenRooms, and Tock all support this. Two boundaries limit it. A preference recorded in one book does not appear in another, so a group running different platforms across venues keeps the same knowledge in separate places. And a preference recorded at one restaurant does not travel to a sister restaurant. That second gap opens at the exact moment a guest most expects to be known.

A restaurant CRM holds the preference on the guest profile instead, above every venue and every book. Some platforms then write the tag back into the reservation system, so it lands on the booking rather than sitting in a database the floor never opens. The round trip is what decides whether a preference tag changes a service or only informs a marketing list.

How do preference tags go wrong?

Preference tags go wrong by ageing quietly, because nothing re-evaluates them. A behavioural tag reflects current data every time it is read, so it corrects itself when a guest’s habits change. A stated preference is a snapshot of one conversation. The guest who avoided alcohol for a year, the guest who was pregnant, the guest whose doctor changed their diet: each leaves behind a tag that keeps being true to the record and stops being true to the person.

Three other failures show up often enough to plan for. Definitions drift between the people applying the tags, so one room’s “wine lover” means a collector and another’s means anyone who ordered a glass. Allergies get entered as preferences and are then treated as a nicety rather than a hard constraint. That failure is the one with real consequences. And a preference lands on the wrong person when two profiles are merged in error, since a bad merge blends preferences along with everything else. The maintenance that works is unglamorous: a short standard list, a periodic review of the oldest tags, and a habit of confirming anything critical at the table rather than trusting a label from three years ago.