Reservations vs visits, and the booking flow

The most important idea in TableStack's booking model is the split between a reservation and a visit. Get this and everything else falls into place.

A reservation is intent; a visit is arrival

• A reservation is a future commitment: this guest, this venue, this party size, at this time. It may be confirmed, cancelled, no-showed — or seated.
• A visit is a party physically in the building. When your host seats a reservation, it becomes a visit. A walk-in creates a visit with no reservation behind it.

So a reservation isn't a visit, and not every visit came from a reservation. Once seated, the party's meal is tracked by the service lifecycle.

Reservation statuses

A reservation moves through these states:

Only the active statuses — Pending, Confirmed, Reminded, Partially arrived, and Seated — hold onto their time slot and tables. Cancelling or marking a no-show releases that capacity back to the availability engine.

Partially arrived is worth a note: it's not something staff set by hand. It rolls up automatically from individual party members as they check in — the same way party statuses drive the floor.

The online booking flow

When a diner books on your public page (no account required), TableStack:

1. Matches or creates the guest. It looks up an existing guest by their contact details and reuses it, or creates a new one. Diners never see a merge prompt. A guest your team has blocked can't book online — they get a generic message and must arrange it with staff.
2. Books through the availability engine, so an online booking can never double-book a table your host just filled.
3. Confirms the reservation — unless the venue requires manual confirmation (see below).
4. Queues the confirmation email to the guest.

Automatic vs. manual confirmation

By default, an online booking is auto-confirmed the moment it's made. If your venue prefers to vet bookings, turn on the venue's require confirmation setting — bookings then stay Pending until your team confirms them, and the guest is told it's a request rather than a lock.

One exception: a booking for a ticketed experience with a price stays Pending until its prepayment clears, then confirms itself and sends the confirmation. See Deposits and prepaid experiences.

Manage, change, and cancel links

Diners don't get a password. The confirmation email and reminders carry a signed link unique to that reservation — a private URL that proves who they are without an account. From it a guest can view, change, or cancel their booking.

• Changing the party size or time re-runs availability to make sure the new request actually fits.
• Cancelling frees the slot immediately, which can trigger waitlist checks for other guests.
• Links expire a short while after the reservation date. A link from a past visit stops working, so a forwarded or old email can't be used to reach a booking later — if a guest needs to make a change and their link has expired, rebook or update it for them from the reservation book.

These links are signed, time-limited, and rate-limited, so they can't be guessed, replayed from an old email, or shared into someone else's booking.

What this affects

• The floor — a seated reservation becomes a visit and lights up its tables.
• Availability — active reservations hold their tables; cancellations free them. See the availability engine.
• The guest book — every booking is tied to a guest record, building their history and no-show count.

What affects this

• The venue's require confirmation setting.
• Deposits and ticketed experiences can hold a booking Pending until payment clears — see deposits.
• Everything in how availability is calculated.

Promo codes

With Manage → Guest communications → Promo codes switched on, the booking page shows an optional code field ("GOLF2026" from a partner package, a radio spot, a win-back email). A valid code is stamped on the booking and shows as a badge in the book, so you can see what pulled people in; an unknown code never blocks the booking — the guest just sees "not recognized."

Possible duplicates

Sometimes the same booking lands twice — a guest calls in and also books online, or a partner feed double-submits. TableStack flags this automatically: when a new reservation shares a guest (by guest record, phone, or email) with another active reservation at the same venue within 30 minutes of it, both bookings get an amber Possible duplicate badge in the day sheet and on the timeline.

Click the badge to open the compare view, which shows both reservations side by side — guest, contact details, time, party size, source, and when each was booked. From there:

• Keep this one, under either reservation, cancels the other one and marks the pair resolved.
• Not a duplicate, at the bottom, dismisses the pair — TableStack won't flag that same combination again.

Detection is advisory only: it never blocks a booking or changes anything on its own. A dismissed pair stays dismissed even if the two reservations are re-synced from a booking feed later.