Walk-ins & staff intake

A walk-in is a party at the door or on the phone: no booking page, no email thread — the venue takes the party directly. DineGlobe books walk-ins through the same commands and the same table allocator as the website, so a walk-in occupies real tables and can never quietly overlap a confirmed booking. This page covers how to add one, which rules staff may pass that the website may not, and how anonymous door parties are handled without inventing a guest profile.

Adding a walk-in from the board

Open the venue’s Today board and choose Add booking. Step one is the same shape as the guest search — “Service” and “Party size” with a Show slots button (“Pick a service and party size, then show today’s slots.”; a party above 200 answers “Party size is bounded at 200.”). Step two, “Today’s slots”, shows the service’s accepted terms text for reference and lists the day’s bookable times as radio chips under “Slot (venue-local time)”. Chips inside the service’s notice window are shown with a “short notice” tag and remain selectable — see the next section.

The form itself asks for “Party name” (required) and “Email (optional)”, with Book the walk-in as the submit. A mid-flight policy publish is caught honestly: the server re-resolves the accepted terms for the exact slot, and if they changed the answer is POLICY_STALE rather than a booking under terms nobody accepted. Success opens the new reservation’s detail page, where the code, tables and lifecycle actions live.

Staff who prefer the service board can book the same party from the board’s phone/walk-in form — it runs the identical server command against a slot taken from an availability read. Booking requires host or above: door staff see the board and take arrivals but hold no booking permission.

What staff may skip — and what they may not

Exactly one rule differs between the website and the floor: the minimum-notice window. Online intake can never book a slot inside a service’s notice window (“too soon — call us”), because the venue cannot know a website visitor is genuinely en route. A party standing at the host stand is different — the venue can see them — so staff intake may take a “short notice” slot directly.

Everything else binds staff exactly as it binds the website:

Rule	Staff path
Closed day	enforced — a closed date offers no slots at all
Booking horizon	enforced — the per-service booking window cannot be jumped
Party bounds of the service	enforced — party size must sit inside the service’s own min/max
Physical capacity	enforced — a real table fit is allocated, and a sold slot answers SLOT_UNAVAILABLE with the nearest open times
Published terms	enforced — a service with no published terms cannot be booked (“a manager must publish a policy version before bookings can be taken”)
Deposit services	refused with PAID_BOOKING_UNAVAILABLE during the pilot, same as online

Anonymous walk-ins

Leaving the email blank makes the booking an anonymous walk-in, and the system invents nothing: no guest profile, no placeholder address, no “unknown@” filler. The board shows the party name as given (or “Guest” when the booking carries no name — the operator panel’s service view and the scanner outcome say “Anonymous” instead), and any message the booking would otherwise trigger is recorded as an honest NO_RECIPIENT outcome rather than sent to an invented address. The record keeps exactly the details that were taken at the door — nothing is guessed in the meantime, and no later command edits the guest details of an existing booking.

After the walk-in is booked

A fresh walk-in is a CONFIRMED booking with tables allocated but nobody arrived yet. The floor flow then runs exactly as for any other booking:

1. Record arrival — the count field “Guests at the door” defaults to 1 and accepts 1 up to the party size; a party of four trickling in is four arrival records, not one edit.
2. Seat the party — seats them at their planned tables and marks the tables occupied.
3. Complete & clear — records the departure and releases the tables for cleaning. A timer never frees a table; the release is always this explicit step.

The full walk-through, including corrections and table moves, is in Arrivals, seating & visits and The service board. Cancelling a walk-in or marking it a no-show follows the same rules as any booking — see Changing & cancelling.

During the unpaid pilot no email provider is connected, so a walk-in booked with an email address gets a composed-but-unsent confirmation (a visible failed delivery, retryable once a provider exists). An anonymous walk-in produces the honest NO_RECIPIENT outcome instead. Either way the confirmation code on the reservation detail page is the artifact the floor works from. Provider posture is described in Messages, confirmations & reminders.