15 · Floor map · KDS · GPE Signage

Product vision (your intent)

1. Draw the room — theater, restaurant, patio — in the visual floor mapper (stable seat/table IDs).
2. Sell at POS — staff (or kiosk) attach that seat/table to the order.
3. Prep sees where it goes — KDS already shows text chips; the fuller goal is a visual mini floor map on one or more prep/expo screens (and optionally lobby screens), highlighting the seat and order state.
4. GPE Signage carries the screen — same player/display registry that already runs ads, with a new live board / map mode fed by KDS (not only static ad playlists).

That last hop (live map/board on Signage displays) is the missing product slice. Floor design + POS + kitchen tickets already share IDs for it.

Who is at which seat? (this is where it gets deep)

A prep screen cannot highlight a seat unless the order carries a seat. A seat only means something for CRM/rewards if the order also carries a customer. Those are two independent attachments that can arrive in different ways.

flowchart TB
  subgraph WHERE["WHERE — seat on the order"]
    W1[Staff taps seat on floor map
Modern POS · seating visualizer]
    W2[Staff types table/seat label]
    W3[Guest picks seat at kiosk / storefront
future]
    W4[Admission / show ticket already has seat
future link]
  end

  subgraph WHO["WHO — customer on the order"]
    H1[Staff attaches customer at POS
search CRM]
    H2[Member scans / looks up loyalty ID]
    H3[Logged-in storefront / app account]
    H4[Guest checkout — no member]
  end

  WHERE --> CART[POS cart metadata + customerId]
  WHO --> CART
  CART --> SALE[Finalize → Invoice + kitchen_tickets]
  SALE --> KDS[Prep sees seat]
  SALE --> LOY[Loyalty earn / rewards if customer linked]
  SALE --> MAP[Future live map on GPE Signage]
          

Paths that already work in code

Paths that are product design / future glue

How deep the graph actually goes

• Floor mapper — geometry + stable seat IDs
• POS / Mobile POS — attach seat + customer at order time
• Customers CRM — who they are
• Loyalty / rewards / tiers — earn/redeem when customer is on the sale
• Invoicing — money spine; sale is source of truth
• KDS — prep execution + seat chips (and later mini-map)
• GPE Signage — multi prep/lobby screens (playlist today; live map later)
• Optional: visits / admissions — pre-known seat before concessions order

None of that requires every guest to be a member. Membership deepens personalization and rewards; seat-on-order is enough for kitchen routing; customer-on-order is enough for rewards. Combining both is how theater “knows” it’s the same person in F12 ordering nachos.

Visual floor mapper (exists)

What gets stored on the cart / ticket

Stable identities from the designer — this is the join key for every downstream screen.

Three systems (as-built vs intended)

KDS today (summary)

• UI: /pos/kitchen — lanes FIRE / PREP / FUTURE / DONE
• Poll GET /api/kds/orders ~3s (no WebSocket)
• Bump / recall / print; station filter ?station=
• Feature gate: plan module kds
• Tickets from POS finalize + Mobile “send to kitchen”
• Admin routing: /admin/kitchen-displays · /api/admin/kds

Detail tables for routes/schema remain valid from the prior KDS write-up; focus here is floor + multi-screen vision.

GPE Signage today (summary)

• Product name: GPE Signage / venue digital displays
• Admin: folders, ads (image/video/URL/HTML), displays with slugs
• Player: /:tenantSlug/signage/:displaySlug
• Public playlist API + bridge signageUpdate + optional ?reloadSec=
• Media = hosted URLs (not the platform barcode upload store)

As-built data path

flowchart TD
  FL[Floor mapper
layoutData + seat IDs]
  POS[Modern POS
PosSeatingPicker]
  META[Cart metadata
seatId tableId numbers]
  KT[(kitchen_tickets)]
  KDS[KDS text chips]
  SIG[GPE Signage
ad playlist only]

  FL --> POS
  POS --> META
  META -->|finalize / send-to-kitchen| KT
  KT --> KDS
  KT -.->|no feed| SIG
  ADS[Admin ads] --> SIG
          

Target architecture (prep screens · multi-display)

Goal: any prep/expo/lobby display can show a live map (or ticket board) for seats that have open food, without re-drawing the floor in three products.

flowchart TB
  subgraph SOURCE["Single sources of truth"]
    FL[Floor layout JSON
geometry + seat IDs]
    KT[kitchen_tickets
order state + seatId]
  end

  subgraph FEED["New: status feed"]
    API["GET /api/kds/board or /api/signage/live/…
layoutId + open tickets + lane"]
  end

  subgraph SCREENS["One or many displays"]
    KDSUI[KDS web · optional mini-map]
    PREP1[GPE Signage display A
mode=live-map · grill]
    PREP2[GPE Signage display B
mode=live-map · expo]
    LOBBY[Optional lobby
mode=order-ready]
  end

  FL --> API
  KT --> API
  API --> KDSUI
  API --> PREP1
  API --> PREP2
  API --> LOBBY
          

Recommended design choices

Build list (to match the vision)

File anchors

Related DocHub