DineGlobeDocs

The service board

The live today view: business date, bookings, visits and table states, auto-refresh behaviour and venue-local times.

HostDoorManager

The service board is the live today view for one venue: every booking on the venue’s business date, plus the physical state of the floor at this moment. Door staff, hosts and managers all work from this one page — the board itself decides nothing about authority; every action on a booking is authorized again on the server. While the page is open it re-renders itself, so the picture on screen follows the floor without anyone pressing reload.

Open the board

Sign in at /app/login and choose a venue under Your venues — the link on each venue card reads “Today’s service”. The board’s address has the form /app/venues/{venueId}. A venue outside your memberships reads as a plain 404: there is no way to reach another organization’s board by typing in an address, and an unauthenticated visit is redirected to the sign-in page.

The clock the board uses

The board renders the venue’s own time, never the viewer’s device time:

What you see How it is produced
Business date The venue-local calendar day of the service start, YYYY-MM-DD (for example 2026-10-02)
Booking times Venue-local 24-hour HH:mm, for example 19:30
Time zone Named in the header line, for example “all times in Asia/Tokyo”

The business date is the day the service starts on in the venue’s IANA time zone — not the UTC day and not your device’s day. A late service that crosses midnight still belongs to one business date.

Bookings

The “Bookings (n)” list is the day’s work, ordered by start time. When the day is empty the board says “No bookings for {date} yet.”. Each row shows:

Field Example Notes
Start time 19:30 venue-local, monospaced
Name and party Tanaka · party 4 falls back to “Guest” for anonymous bookings
Status CONFIRMED the booking lifecycle, shown in upper case
Confirmation code DG-4KQ7X2AM the code the guest was told to keep
Tables T1, T2 or unassigned labels from the floor plan
Visit Arrived 2/4 · seated appears once a visit exists; “· departed” after clearing

Every row is a link to the reservation detail page, where the arrival, seating and clearing buttons live — see Arrivals, seating & visits. The “Add booking” button beside the heading opens walk-in and phone intake, described in Walk-ins & staff intake.

Floor right now

The second half of the page, “Floor right now (n)”, is the physical picture: which tables are held or awaiting cleaning today. Each line names the table (or its id), the occupancy state, and the holding party’s confirmation code and name when the hold belongs to a booking.

State Meaning
SEATED a party is physically at the table
CLEANING the party left; the table was released for cleaning

A release from earlier in the same business date stays on the list as CLEANING rather than vanishing mid-service; the release instant itself is shown in the operator panel’s service view, which appends “released {instant}” to each cleared table. The empty state reads “No table is seated or awaiting cleaning right now.”. Nothing on this list changes by itself: tables are freed only by an explicit complete-and-clear, never by a timer — the rule and its consequences are on Arrivals, seating & visits.

Auto-refresh

While the tab is visible the board re-renders itself every 15 seconds, and the status line beside the heading says so: “Live — refreshes every 15 s while this page is visible”. The refresh is network-first: if a refresh fails, the previous render simply stays on screen — nothing is queued and nothing is faked.

The operator panel “Service view / walk-in / move table (DEV-025 panel)” at /app/panels reads the same dataset with a finer-grained poll: every 5 seconds while the tab is visible and focused, every 15 seconds when idle. Polling is revision-based, so an unchanged floor answers cheaply (“unchanged since the last poll”), and returning to the tab refreshes immediately.

Working a service with the board

  1. Before the doors open — scan the day by start time, check table assignments, and take phone or walk-in bookings through “Add booking”.
  2. At the door — check parties in from a QR pass (QR check-in passes) or record the arrival by hand from the booking page.
  3. During service — seat arrived parties, watch “Floor right now” for tables in play, and move a party with the panel’s “Move party to another table” form when plans change; the move runs through the same allocator as booking, so it can never double-hold a table.
  4. Turning tables — record each departure with complete-and-clear; the table flips to CLEANING on the next refresh and can be planned again once it is physically ready.

What the board does not show

  • No contact details. The board and the booking page are door-safe by construction: the display name and the guest’s free-text requests are the only guest facts on screen — no email address or phone number rides either page.
  • No other days. The board is today in the venue’s business date; there is no date picker for history.
  • No self-moving floor. An overrunning party keeps its table on the list until a staff member records the departure.

Times look wrong? Check the venue’s time zone before anything else. The board renders the venue’s zone faithfully, so a “shifted” day almost always means the venue’s IANA zone or its schedule is set incorrectly — not a display fault.

Access

Any staff membership can open the board; the membership role decides what the linked actions allow. DOOR reads the board and records arrivals; HOST runs the full floor workflow; MANAGER and the ownership tier add corrections and booking decisions. The role-by-role limits are in Roles & what they can do, the host’s routine in Host guide and the door routine in Door guide. Action failures return named codes — the common ones and their fixes are collected in Error codes & fixes.