# Managing Bookings

**Console: Service → Bookings.** Confirm the working location and service date.
The staff app supports live host actions; both views use the same records, but a
local change can still await sync. Verify the saved result before handover.

## Find and review a booking

The booking list can be narrowed by date, guest search, status, segment,
assigned table, and reservation tags. Open a booking to review:

- guest name and contact details;
- arrival, party size, offering, space, and table assignment;
- dietary requirements, occasion, guest notes, and staff notes;
- reservation tags;
- deposit or cancellation-fee state; and
- booking history.

Use tags for structured operational labels and notes for visit-specific context.
Avoid sensitive payment details in any note.

## Use the Console calendar

Choose **Calendar** beside **List** on the Bookings page. The month view keeps
its booking list underneath, so you can find a day and then review individual
records.

1. Use **Previous month** or **Next month** to browse. **Today** returns the
   displayed calendar to the current month; choose the intended day afterwards.
2. Select a day to set the list's date range. Shift-click a second day to select
   a range. With a keyboard, arrow keys move between days and Enter or Space
   selects; Shift with Enter or Space extends the selection. On a touch device,
   use **Date range** to choose multiple days.
3. Review the list below. A calendar selection uses the location's time zone,
   starts the list at its first page, and sorts it by booking time.
4. Check any remaining guest, status, type, table, or tag filters. Browsing to a
   different month does not itself replace the list's selected date range, and
   selecting a day does not clear those other filters.

The calendar counts booking records, including notify-list records and all
booking statuses; waitlist records are excluded. It does not use the list's
additional filters. A count can therefore include cancelled or no-show records
and differ from the filtered list below. Darker days are busier relative to the
month shown, not a measure of occupied tables, arriving guests, or remaining
capacity. Check the actual reservations and allocation before accepting another
party.

If calendar counts fail to load, use its **Try again** control or investigate
through the list. A failed count is not an empty day. Inspect filtered links
before sharing them: guest-name or phone searches can be retained in the link,
so use an authorised channel and remove personal search values from public
captures.

## Booking statuses

| Status    | Meaning                             | Common next actions                                          |
| --------- | ----------------------------------- | ------------------------------------------------------------ |
| Pending   | A booking request awaits a decision | Confirm or cancel; mark no-show once its service has started |
| Confirmed | The reservation is accepted         | Modify, assign/move table, seat, cancel, or mark no-show     |
| Arrived   | The party has been seated           | Continue service and order workflow                          |
| No-Show   | The guest did not attend            | Review any fee or restore if recorded by mistake             |
| Canceled  | The booking is no longer active     | Review payment outcome or restore if recorded by mistake     |

Confirming a pending request sends the guest confirmation. The list's **Mark as
no-show** action records the status without charging a fee; use the booking's
full review/payment flow when a fee decision is needed. Restoring a canceled or
no-show record to Confirmed does not send another confirmation automatically;
contact the guest separately if needed.

### Review a private-hire request

Open the request rather than making a status decision from the list. Confirm:

- the requested layout, party size, event duration, setup, and clear-down;
- the complete exclusive footprint and any conflicting regular reservations;
- whether service capacity is shared or dedicated;
- the deposit to collect on acceptance and the disclosed cancellation policy;
- guest notes, dietary needs, and operational tags; and
- that the team can deliver the event before choosing **Accept request**.

Acceptance charges any request deposit and confirms the booking only when that
charge succeeds. If it fails, the request stays Pending. Venue decline never
creates a cancellation fee; any legacy captured deposit must be refunded before
the decline completes.

## Create or change a booking

Staff can enter guest details, date/time, party, offering, space, tags, and
notes, then use automatic allocation or choose tables manually. A modification
rechecks the complete booking against table overlap, capacity, duration, space,
and pacing rules.

The table chooser shows availability and selected tables, and can preview
re-seating other parties. Explicit staff choices retain every conflict-free
table regardless of online bookability, automatic capacity fit, or an earlier
area selection. Judge physical suitability and review the complete move before
saving. A pacing warning is not the same as a conflicting table. See
[Table moves](/reservations/table-moves).

## Run arrivals in the App

**Check in** records that the guest is here without claiming a table is already
seated. Review actual arrived/seated counts rather than assuming every booked
guest is present. For live service, staff can:

- select, move, or confirm tables;
- partially seat a party when only some guests have arrived;
- seat the full party;
- use the offered waitlist seating/notification flow deliberately; and
- open the order automatically on seating when **Auto-Open Order** is enabled.

Check the assigned table and party count before seating. Partial seating keeps
the operational record accurate without pretending the full party has arrived.
Use **Whole party is here / All here** only when true. **Depart / Guests left**
releases tables after actual departure; it is not a substitute for checking the
linked order and payment outcome.

## Payments and exceptions

When a card is required, send the secure payment link by text or email or show
its QR code. Authorised staff can waive the requirement with a reason, refund an
eligible deposit, and process a qualifying late-cancellation or no-show fee.

If the editor asks how to collect the card, choose the intended channel or an
authorised waiver. Text needs a mobile number and email needs an email address;
resolve the displayed form error before saving. Choosing a channel does not
prove that its message was delivered or the guest completed payment.

When a charged deposit is retained, the cancellation/no-show decision shows it
as credit against the configured liability. Charge only the remaining balance,
or record an authorised waiver. If the charge fails, the booking remains active
so staff can retry without losing the financial decision trail.

An authorised deposit hold is not a captured deposit. **Release hold** cancels
the authorisation; the guest's bank controls when it disappears. A charged
deposit needs its supported refund flow instead. After an uncertain financial
action, reopen the same booking and inspect the payment state before retrying.
Review **Notify the guest** and any required notification in a cancellation
confirmation; a status change alone is not proof the guest received the message.

## Service handover

Before each shift, review pending requests, unassigned bookings, large parties,
spaces, deposits/cards still required, dietary details, and tags. After service,
resolve arrivals, no-shows, cancellations, fees, and waitlist entries so reports
remain meaningful.

See [Reporting & Daily Routine](/reservations/reporting-and-daily-routine) for a
complete opening and closing routine.

For uncertain actions, preserve booking, table-move and financial references,
actual guest outcome, notification state, and the exact error. Keep contact
details and payment credentials within authorised channels.