# Waitlist and Availability Alerts

TablePort has two tools for different situations:

| Tool                | Purpose                                                           | Queue position? | Reserves a table?              |
| ------------------- | ----------------------------------------------------------------- | --------------- | ------------------------------ |
| Walk-in waitlist    | Manage parties waiting to be seated today                         | Yes             | No, until staff seat the party |
| Notify me when full | Let a guest request an alert if a searched reservation time opens | No              | No                             |

Do not use the availability-alert list as a walk-in queue.

## Configure the waitlist

Open **Settings → Location settings → Waitlist** and enable **Accept waitlist
requests**. You can set an optional minimum and maximum party size. The
effective range is the overlap between those values and the venue's online
reservation party range; Console shows the resulting range.

Leave a waitlist bound empty to inherit the corresponding reservation bound. If
the two ranges do not overlap, guests cannot join until the settings are
corrected.

## Join and queue order

A guest can join through the published waitlist page, or staff can add them at
the host stand. Capture accurate party and contact details, then add an
estimated wait where useful.

Review today's genuinely waiting parties and the displayed join/queue position.
Resolve old or completed entries rather than treating every historic record as a
current waiting party. A queue position is not a confirmed reservation or proof
that a particular table is free.

The guest confirmation shows position and an estimate when one is available and
allows the guest to cancel their place.

## Operate the queue

Staff can:

1. review the party, wait, and queue position;
2. update the estimated time;
3. select a suitable table;
4. send the table-ready message;
5. partially seat or seat the party; and
6. use the offered seating/notification confirmation when those actions should
   happen together, reviewing the table and intended recipient first.

A table-ready message is a deliberate staff action; enabling the waitlist does
not automatically decide that a table is ready. Confirm the assigned table
before notifying the guest. **Table Ready / Text: table ready** sends a real
message; check current notification state before repeating an uncertain send.
**Check in** and actual seating are separate guest outcomes.

## Availability alerts

Enable **Notify me when full** under **Location settings → Reservations →
General**. When an eligible search has no availability, the guest can leave
contact details for that date/time and party search. The record is an
availability alert, has no queue position, and does not hold inventory. An alert
can be triggered when that booking opportunity opens, but the guest must still
complete a valid booking.

## End-of-service hygiene

Resolve parties who were seated, cancelled, or left. Confirm that the dashboard
contains only genuinely waiting parties and review unresolved entries before
closing. See [Managing Bookings](/reservations/bookings) for seating workflows.

If settings fail to load, use **Try again**; the existing configuration has not
been changed. If an estimate, notification, or seating save is uncertain,
inspect the same party and table state before repeating it. Do not duplicate
queue entries to force another message. Escalate with party reference, location,
service date, intended action, displayed state, and exact error.