# Reservations and Waitlists

TablePort connects what guests can request online with the tables, combinations,
spaces, service capacity, and policies your team controls. Guest searches and
staff actions use the same records, but explicit staff selection is not
restricted by every online eligibility rule. Verify the chosen tables and saved
result through the supported staff workflow.

## What the system manages

| Record             | Use it for                                              | Holds tables?     |
| ------------------ | ------------------------------------------------------- | ----------------- |
| Reservation        | A normal table booking                                  | Yes               |
| Booking request    | A guest request that needs approval                     | Yes while pending |
| Enquiry            | A conversation for an event or private hire             | No                |
| Waitlist entry     | A party waiting to be seated today                      | Not until seated  |
| Availability alert | A guest asking to hear if a full time becomes available | No                |

The walk-in waitlist and **Notify me when full** are separate. A waitlist has a
queue and estimated wait; an availability alert watches a particular booking
search and has no queue position.

## How availability is decided

A time is offered only when all relevant checks pass:

1. Reservations are enabled and the date is within the advance-booking window.
2. An exact special-day override, or otherwise a weekly shift, covers the
   requested time.
3. The party fits the venue, offering, space, and waitlist limits that apply.
4. An eligible table or table combination is free for the entire stay, including
   setup and clear-down time.
5. Shift guest limits, concurrent-cover limits, and rolling pacing still have
   room. A displayed slot is not a completed booking. Required deposit/card
   collection, request acceptance, and saved confirmation must still succeed in
   the enabled flow; inspect the resulting booking and payment state.

Automatic allocation chooses an efficient eligible table or combination and
avoids wasting larger tables where a better fit exists. Staff can explicitly
choose any conflict-free table regardless of online bookability, automatic
capacity fit, or prior area choice. Review physical suitability and the full
[move preview](/reservations/table-moves); a warning and a conflicting table are
different conditions.

## Choose where to begin

- New venue: follow the [Setup Checklist](/reservations/setup-checklist).
- Configure capacity: read
  [Tables & Allocation](/reservations/tables-and-allocation) and
  [Shifts, Pacing & Turn Times](/reservations/shifts-pacing-and-turn-times).
- Offer drinks-only, tasting menus, or other choices: see
  [Offerings & Guest Choices](/reservations/offerings).
- Handle rooms and large groups: see
  [Rooms, Groups & Private Hire](/reservations/spaces-and-private-hire).
- Close holidays or sell a date-specific package: see
  [Special Days & Paid Experiences](/reservations/special-days-and-experiences).
- Run the host desk: use [Managing Bookings](/reservations/bookings) and
  [Waitlist & Availability Alerts](/reservations/waitlist).
- Review results: see
  [Reporting & Daily Routine](/reservations/reporting-and-daily-routine).

> **Before going live:** Use the restaurant's agreed safe test process for each
> guest flow you enable, including payment, confirmation, modification,
> cancellation, and waitlist.