Changing & cancelling

Every change to a booking is an explicit command with a recorded actor, a version check and an audit trail — nothing edits a reservation in place. The split of powers is deliberate: staff with the booking role can move, cancel, no-show and reconfirm; guests can cancel and reconfirm their own booking from a self-service link, and cannot reschedule in this pilot. This page lists who may do what, which states allow it, and exactly what the cancellation quote displays before you commit.

Who may do what

Action	Venue staff	Guest (via the /b link)	Notes
Reschedule (new date, time, party size, duration)	host and above	not available	staff-only command; guests change plans by cancelling and rebooking
Cancel	host and above	yes, for CONFIRMED and REQUESTED	staff need a reason; the guest’s reason is optional
Mark no-show	host and above	no	only after the accepted policy’s grace window
Request reconfirmation / record it	host and above	yes, answer only	the guest answers a request the venue made
Approve or decline a request	manager and above	no	see Request-approval bookings

Door staff read bookings but hold no booking-edit permission, so the door view offers none of these actions. Guest self-service is scoped to exactly one booking per link — see Guest self-service links.

Which states allow edits

Only CONFIRMED bookings and pending REQUESTED requests are editable: they can be rescheduled and cancelled, and a CONFIRMED booking can be marked as a no-show. CANCELLED, DECLINED, EXPIRED and NO_SHOW are final records — the command refuses with RESERVATION_INVALID_TRANSITION (“Only a confirmed booking or a pending request can be rescheduled.”) and the honest path is to create a new booking.

Rescheduling (staff only)

The reschedule command is atomic: it releases the old tables and allocates new ones in one transaction, and any failure leaves the original booking exactly as it was. The target comes from an availability read; the command re-checks every rule under the venue lock — closed day, booking horizon, party bounds of the service, a physical table fit for the new party size — so a stale picture answers AVAILABILITY_STALE and a sold target answers SLOT_UNAVAILABLE with the nearest open times, original booking untouched. Duration overrides run from 15 to 480 minutes.

Two rules deserve spelling out:

• The minimum-notice window is an online rule. Staff moving today’s booking to a near-now slot is the venue acting in person, so staff intake may take it; the website never could.
• If the edit would change the booked amount, currency or terms — anything involving deposit terms — the command refuses with REBOOK_REQUIRED: “That change would change the booked amount — cancel and rebook under the current terms.” Nothing is charged by the edit path; price changes go through the disclosed cancel-and-rebook flow.

After a successful reschedule the guest’s record shows the new details, and the guest email “Your booking at {venue} changed” carries the current facts.

Cancelling and the cancellation quote

Cancelling releases the tables immediately and is replay-safe: a retried submit with the same request key returns the stored outcome rather than cancelling twice. Staff cancels require a reason (at most 500 characters); the guest’s cancel form labels it “Reason (optional)” and the system records “Cancelled by the guest.” when it is left empty.

The quote always comes from the terms snapshot the guest accepted at booking time — never from whatever policy is current today. Before you confirm:

• The guest’s self-service page shows the row “Cancellation terms” with one of two labels: “Free cancellation” or “Late-cancellation terms apply”. This pilot’s portal shows the label, not amounts.
• The math behind the label: the cutoff is the booked start minus the accepted policy’s free-cancellation minutes. At or before the cutoff the status is FREE_CANCELLATION with nothing retained; after it, the status is LATE_CANCELLATION and the retained amount is the expected amount times the accepted late-retention rate, rounded down, with the rest refundable.

Once the cancellation is recorded, staff tools report the outcome with the quote status and the refundable amount in exact integer minor units, and the guest sees “Booking {code} cancelled (no charge).” or “Booking {code} cancelled (late terms applied).” Every amount in the quote is zero for a free booking, which is the normal case in this unpaid pilot — see Payments (pilot posture) and Refunds.

No-shows

Marking a no-show is allowed only when the accepted policy’s grace window has fully elapsed past the booked start — for a 15-minute grace, at 15 minutes and one second after the start, never earlier. An earlier attempt is refused with RULE_VIOLATION, not an error to retry. The command releases the held tables for rebooking and stamps the record NO_SHOW once. Physical occupancy is a separate matter: a table stays occupied until the floor team records the departure — see Arrivals, seating & visits.

Reconfirmation

The venue can ask a guest to confirm they are still coming: staff stamp a reconfirmation request on the booking, which also queues the reminder email “Please reconfirm your booking at {venue}”. A guest with a self-service link then sees the section “Please reconfirm” — “The venue asked you to confirm you are still coming.” — with the button “Yes, I am coming”, answering “Thank you — booking reconfirmed (version {n}).” Staff can record the same answer by hand when the guest replies in person or by phone. The request and the answer never change the booking’s lifecycle state on their own.

There is no guest self-service reschedule in this pilot. The booking confirmation screen says so in plain words, and the /b page offers exactly two actions: reconfirm and cancel. To move a booking, the guest contacts the venue — staff reschedule in one atomic step — or cancels and books a new time.

Version guards and safe retries

Every change command carries the record version you last read. If someone else moved the booking first, the answer is RESERVATION_STALE — reload and redo the action against the current version; nothing was half-applied. Replaying the same request key returns the same outcome instead of a second change, while the same key with a different payload refuses with IDEMPOTENCY_MISMATCH. The console surfaces a stale submit as “Stale form — reload the page.” The full code list with remedies is in Error codes & fixes.