How availability is calculated

Every bookable time your diners see — and every slot your host is offered in-house — comes from one availability engine. It answers a single question over and over: can a party of this size be seated at this time, on some table, without colliding with anything already booked? This article explains the rules that go into that answer.

Turn times by party size

The engine assumes each party occupies its table for a set number of minutes — the turn time — and that time depends on party size. Larger parties get longer. A typical default looks like:

Each venue sets its own bands. The turn time is how long a table is considered occupied when the engine checks whether a later booking fits.

Buffers between seatings

Between two seatings on the same table, the engine leaves a buffer (15 minutes by default) so staff can reset. A table isn't offered for a time that would land inside another booking's turn plus the buffer on either side.

Which table fits — and combinable tables

For each candidate time the engine finds the best-fitting free table: the smallest table that still seats the party, preferring the venue's higher-priority tables when several fit equally. A table can also be marked walk-in only, in which case it's held back from reservations.

If no single table fits, the engine looks for a combinable pair — two tables you've marked as joinable — and offers the tightest-fitting combination. This is how large parties get seated across joined tables.

Service periods, closures, and special days

Slots only appear inside your service periods — the open hours you set per weekday (for example, dinner 5:00–9:00). You can mark specific dates as closures (closed that day) or give a date its own special hours that override the weekly template — useful for holidays or private events. Times are always calculated in the venue's own timezone.

Slot rules: pacing and channels

On top of the open hours, slot rules give you fine control over specific windows:

• Cover pacing — cap how many total covers can be seated within a rolling window (for example, no more than 40 covers per 15 minutes) so the kitchen isn't slammed. There's also an optional cap on the number of parties per window.
• Channel restriction — mark a window as online only (widget bookings) or in-house only (phone/walk-in). In-house-only windows protect capacity from the public widget; those slots simply don't appear to diners.

When a slot is physically available but sits past the pacing cap, diners don't see it — but your host does, flagged as a paced slot, so they can knowingly overbook by hand when it makes sense.

Learned turn times

TableStack also watches how long parties actually stay. Over a lookback window it measures the median seated-to-departed time for each party-size band and how many visits support the figure, then suggests updated turn times. This is advisory only — nothing changes behind your back. You review the suggestion and apply it in settings if you agree.

Staff vs. diner views

The public booking page shows only clean, bookable slots. The in-house booking form shows everything a diner would see plus those paced slots, flagged, so your team can override pacing deliberately. Both come from the same engine, so the two never contradict each other.

What this affects

• Online booking — the slots on your public page come straight from here. See the booking flow.
• Walk-ins and seating — when a host seats a walk-in, the engine highlights which tables can take the party right now.
• Waitlist and changes — cancelling or changing a booking frees capacity and re-runs availability, which can open a slot for a waitlisted party.

What affects this

• Your venue's turn times, buffer, service periods, closures, special days, and slot rules.
• Combinable table pairings and walk-in-only flags on the floor.
• Existing active reservations, which hold their tables and count toward pacing.