Banquette

A banquette is a piece of furniture, and it is also the request a host hears most often. Guests ask for it because the bench faces the dining room while the chair opposite faces a wall. That single fact is why the word turns up in guest data at all: “banquette, facing out” is among the most common preferences a restaurant ever writes down about a guest, and the same handful of tables get requested over and over.

How should I store a guest’s seating preference?

Store it as a tag the system can filter on, not as a line of text in a notes box. A tag is a label chosen from a set list, so every guest who prefers the banquette carries the identical one and the guestbook can find them all at once. Typed notes cannot do that.

Most seating preferences end up as typed notes anyway. Someone writes “prefers banquette” on a booking, and the next person to open that booking can read it. Nothing else can. Forty guests who want the banquette will have it recorded forty different ways, from “banquette” to “bench, facing out” to “hates the back room”. Nobody can ask the guestbook which regulars want the banquette, because the answer is spread across forty different sentences.

A preference tag can be queried, counted, and acted on before service. It lets a manager pull every banquette-preferring regular booked this week and check the floor plan against them, which is a different kind of work from reading bookings one at a time. Notes are still worth keeping for the specifics that resist structure, such as which banquette and why. The rule of thumb is that anything you would ever want to filter by should be a tag, and everything else can stay prose.

Can my reservation platform remember a guest’s seating preference?

Within its own scope, yes. Resy, OpenTable, SevenRooms, and Tock all store guest notes, so a preference recorded on one platform is there the next time that guest books through it. Two limits matter to a group. A preference recorded on one platform does not appear on another, so venues running different books keep the knowledge in separate places. And a note taken at one restaurant does not follow the guest to a sister restaurant, which is exactly where being seated correctly would land hardest.

Closing that gap is what a restaurant CRM is for. In Loyalist a preference sits on the guest profile rather than on a single booking, applies across every venue in a group, and is written back into the reservation platform so it appears on the booking the host already has open. A guest gets the banquette without asking, at a restaurant they have not visited before.