How to design your restaurant floor plan with POS Places

POS Places are how you model the physical reality of a restaurant inside the POS. Tables sit in places, places live inside the POS Point, and orders flow from a table → place → POS Point → kitchen ticket. Done well, the staff thinks in zones ("Section 3 just sat down"), the kitchen prints to the right physical printer, and reports tell you whether the Patio is your money-maker. This article is the setup playbook.

Step 1 — list the real-world zones

Walk the venue. Write down every distinct zone where guests sit and a waiter would say "that's a different section". Typical for a mid-size restaurant: Bar Counter, Main Hall, Patio, Private Dining Room, Take-away. For a hotel restaurant: Breakfast Hall (mornings only), Restaurant, Lobby Bar, Pool Bar (seasonal). Don't model every table as its own place — that's tables, not places.

Step 2 — create the places

1. Go to POS → POS Places → Create.
2. Name it after the real zone ("Patio", not "Section A"). Names show up on the POS table grid — clarity beats codes.
3. Assign to its parent POS Point. One place lives in exactly one POS Point.
4. Configure printer mapping (next step). Save.

Step 3 — set the printer routing per place

Each place has a sendTo configuration: where its kitchen tickets go. Two routes: "printer" (silent print to a named QZ Tray printer) and "activeOrders" (push to the live-orders subscribe-and-print page on a kitchen mini-PC).

• Bar Counter → bar printer (silent_to_printer + bar thermal). Drinks ordered there print where bartenders see them.
• Main Hall + Patio → kitchen printer for food, bar printer for drinks. The product itself decides which printer (via product's posplaces tagging) when the place sends to multiple destinations.
• Private Dining Room → if you want it printed separately, assign its own printer. Most properties just route it like Main Hall.
• Take-away → kitchen printer with a clear "TAKE-AWAY" header (configure on the print template). Some properties use a dedicated take-away printer.

Step 4 — assign tables to places

1. Create or edit each table. Assign it to a place ("Patio Table 1").
2. Number tables intuitively. "P1, P2, P3" for Patio; "M1, M2" for Main; "B1, B2" for Bar Counter. The waiter says "order's for Patio 3" and everyone knows the location.
3. Set capacity (number of seats) per table — drives auto-suggested splits and reservation matching.

Step 5 — verify on the POS

1. Open the POS app. The table grid should now have tabs/headers per place.
2. Tap a Patio table, add one drink and one food item, send to kitchen.
3. Confirm: the drink prints at the bar printer, the food prints at the kitchen printer. If both go to one printer, your product → posplaces tagging is wrong, not the place setup.
4. Walk the floor with the manager. "This table is P3, that one is P4" — confirm staff can match physical to digital fast.

Patterns by venue type

Standalone restaurant

POS Point: Restaurant. Places: Bar Counter (1), Main Hall (1), Patio (1, seasonal), Private Room (1). 4 places, kitchen + bar printers, simple.

Hotel with multiple F&B outlets

POS Point per outlet (Restaurant, Lobby Bar, Pool Bar). Each has its own places. Pool Bar is one POS Point with one place ("Bar") — places aren't required to be plural. Restaurant has 4 places. Lobby Bar has 1 place. Each outlet has its own cash desk and Z report.

Quick service / takeaway

Probably hasTables = false on the POS Point (no tables). Places not strictly needed, but you can still create one for kitchen ticket routing if you have multiple prep stations.

What NOT to do

• Don't model every table as its own place. That's the tables list — places are zones.
• Don't use places to track waiter sections ("Maria's section", "John's section"). Waiter assignment is a separate concept; places are physical zones.
• Don't create more than 6 places per POS Point unless you genuinely have that many distinct kitchen routing needs.