Manage reservations
Create and update bookings while keeping guest details and table availability accurate.
On this page
Start with the booking details
Make sure reservations are enabled for the location. A booking needs the intended local date and time, party size and the relevant experience or service.
Use the guest’s existing customer profile when it is the correct person at this location. Matching names alone are not enough to identify the same guest.
Check availability
Availability depends on table capacity, other bookings, service windows and any turnaround buffer. Overnight services can also conflict with bookings on an adjacent date.
A booking can exist without a table assignment. Treat it as unassigned until an available table has actually been allocated.
Change or cancel a booking
When changing a booking, check whether the new time or party size still fits its experience and assigned table. Keep unrelated guest details intact.
Use cancellation or decline for a booking that will not go ahead. Seating guests and changes to bookings already linked to POS should use the existing POS workflow.
Guest notifications
A booking or status change may queue the existing guest reservation email. Saved does not mean delivered, and a sent status does not prove the guest read the message.
If a guest asks about an email, check the recorded notification status rather than assuming a booking confirmation reached their inbox.
Enable reservations and identify the guest
Reservations must be enabled before creating bookings. Missing reservation settings mean disabled. Reuse a verified customer from the same location; a matching name alone is not enough to identify someone or justify linking a profile from another location.
Use the location's local dates and timezone for booking times. Persistent profile notes, allergies and special occasions are different from notes for a particular visit. Preserve unrelated guest details and recorded customer classifications.
Booking status is not table assignment
A booking may be unassigned. It is not a reserved table until an available table is assigned. Pending requests with assigned tables occupy those tables; waitlisted parties do not reserve capacity. Confirming, declining, cancelling and moving a guest to or from the waitlist are explicit status decisions, not side effects of improving a seating plan.
Use the POS seating workflow for arriving guests so their tab is opened. A reservation edit does not automatically seat guests or open a POS tab. Changes to POS-linked bookings need the existing POS workflow. Cancel or decline bookings instead of treating deletion as the normal cancellation process.
Availability across dates and experiences
Check adjacent dates for overnight service and turnaround buffers. Bookings in other experiences also matter when those experiences share rooms or tables. Do not pool the restaurant's entire capacity for an experience limited to particular rooms.
A table’s capacity is the total of its four seat counts. Check the room and table configuration against the actual seating. Review the time, duration, status and assignment before saving, as another booking may have taken the table since you first checked.
Guest emails and status
Normal booking/status changes may queue the existing reservation email. Queued is not delivered; a successful send is not proof the guest received or read it. Saving a booking alone does not establish email delivery. These are booking notifications; they do not send a separate marketing campaign.
Recorded guest history
“New” means no recorded prior visit, not proof that this is the person's first visit. Use recorded VIP/returning/new classifications and explicit staff priorities. Use recorded guest preferences and staff priorities when planning seating.