Front of House (FOH)
Front of house is everything a guest sees and the team that works it: the door, the dining room, the bar, and the hosts, servers, captains, bussers, bartenders, and managers who staff them. It is also where a restaurant collects almost everything it knows about its guests.
Front of house and back of house split a restaurant into the half guests see and the half they do not, with the pass as the border between them. FOH is the guest-facing half, and it is also the restaurant’s collection layer for guest information, whether or not anybody treats it that way. Every preference, occasion, and complaint a restaurant learns arrives at a host stand, a table, or a bar.
Where does guest data actually get captured in the front of house?
At four points, and each one writes into a different system.
- The host stand, into the reservation platform. Name, phone, email, party size, visit count, and whatever note gets typed onto the booking. This is the strongest identity data a restaurant gets, because the guest supplies it themselves when they book.
- The table, into nothing, most of the time. What a server or a captain learns during a meal has no system of record unless a person types it into the booking or the guest record afterwards.
- The check, into the point of sale. What was ordered and what it cost, attached to a table and a time rather than to a name.
- The bar, into the point of sale, usually with no identity attached at all. Walk-in bar covers are the largest anonymous block in most restaurants.
Identity and spend are captured in separate systems, and the place where the most is learned about a guest has no system behind it. That split is the reason a restaurant CRM in hospitality is built around matching checks to reservations rather than around a contact list.
How does the front of house use guest data during service?
In three places, each with a different tolerance for detail. The host stand reads it at the moment of arrival and can take in almost nothing, so a visit count and one tag do more than a paragraph. The floor reads it before service, in the pre-shift briefing, which is the one point in the day when a team can be told about ten specific tables. Managers read it afterwards, when they decide what to do about a table that went badly.
Nobody reads it in the middle of a rush. A server with four tables and a captain running a section are not going to open an application, so guest information that only lives behind a login has effectively not arrived. Platforms that write tags and notes back into the reservation book are solving that delivery problem rather than a storage problem, since the book is the screen already open on the host stand.
Last updated