Floor Plan
A floor plan is the map of a dining room's tables and sections. Reservation platforms render it live during service, showing which tables are seated, finishing, or open, so hosts can assign parties and servers to sections. The same tables also exist in the point of sale, usually under different names.
A floor plan exists in at least two systems at once. The reservation platform draws one for the host stand, the point of sale draws another for servers and checks, and the two are maintained separately by different people. That duplication is how a perfectly organized dining room becomes a data problem, and it is also why the floor plan is the screen that decides whether guest knowledge reaches the room in time to be useful.
Why do my floor plan and my POS use different table names?
Because nothing forces them to agree. Each system was configured at a different time by a different person, and neither validates against the other. The book says 12 and the point of sale says T12, 012, or Patio 2. Bar seats get numbered in one and lettered in the other. A section renamed for patio season gets renamed in one place only.
Nothing on the floor breaks, so nobody notices for years. What breaks is every join between the two systems. A check that cannot be tied to the booking at that table is revenue with no guest attached, and table-level reporting comes back wrong by whichever names failed to line up. Reconciling the two schemes is work that sits above both systems, and platforms differ in whether that mapping is something an operator can configure or something that has to be fixed by renaming tables in both products.
Does guest information reach the floor plan?
This is where it either arrives or does not. Recognition happens at the seating screen, in the seconds when a host decides where a party lands and what to say. A preference, an allergy, a VIP flag, or the fact that the 8:15 is a regular’s anniversary is only operationally real if it appears there. The same fact sitting in a marketing tool, a spreadsheet, or somebody’s memory has no effect on the guest’s night.
Loyalist writes guest tags and notes back into Resy and OpenTable, so what the guestbook knows shows up on the booking a host already has open rather than in another tab nobody checks mid-service. The write-back closes the distance; a person still has to read it and act, which is why pre-shift matters alongside the screen.
Can the floor plan tell me which tables earn the most?
Only once checks reliably match to tables, and then the answer needs reading carefully. Table-level revenue reflects seating policy as much as it reflects the table. Table 12 earns more partly because it seats four and partly because hosts put the regulars and the big parties there, so the report measures a habit as well as a location.
Read alongside dwell time and turn counts it is still worth having. The two-top by the kitchen door that turns three times a night can out-earn a prized window table that hosts one long celebration, and section-level numbers will show which server stations carry a disproportionate share of the room.
Last updated