Booking rules reference
What this covers
Every setting that shapes which times can be booked — what it does, its allowed range, its default, and
a suggested starting value. Requires the manage-settings permission.
This is a lookup page. For why a particular time is missing, go to Why a time or table isn't offered.
Staff-side rules
All on Property Settings → Restaurant (/settings/restaurant).
| Setting | What it does | Range | Default | Start with |
|---|---|---|---|---|
| Booking interval | How far apart bookable times are. A 30-minute interval offers 19:00, 19:30, 20:00 | 15, 30 or 60 min | 30 | 30, or 15 if you are small and flexible |
| Maximum advance days | How far ahead a booking may be made | 1–365 | 30 | 60–90. Too short turns away planners |
| Minimum advance hours | How close to now staff may still book | 0–72 | 2 | 0 — staff answering the phone should be able to book for tonight |
| Minimum party size | Smallest booking accepted | 1–100 | 1 | 1 |
| Maximum party size | Largest booking accepted. Must be at least the minimum | 1–100 | 20 | Your largest table, or largest sensible merge |
| Default reservation duration | How long a booking holds its table unless changed | 30–480 min | 120 | 90 for a bistro, 120 for full service, 150+ for tasting |
| Table reserved window | How long before a booking its table is treated as committed on the live floor | 15–240 min | 60 | 30–60 |
| Max covers per slot | Pacing cap — covers that may start in one interval. Empty = off | 1–1000, or empty | Off | Off at first (link Pacing) |
| No-show grace period | How long past its time a booking waits before the automatic sweep marks it a no-show | 15–1440 min | 120 | 60–120 |
| Waitlist ready window | Within this many minutes, a waitlist guest is told their table is ready now; beyond it, that a table has opened up | 15–1440 min | 60 | 60 |
| Default status, staff bookings | Whether a booking your staff create starts pending or confirmed | pending / confirmed | pending | confirmed — if your own staff took it, it is confirmed |
| Default live view | Which view Live View opens on | list / floorplan | list | floorplan, if you have it |
Public booking page rules
These live on a different page — Property Settings → Public Pages Design → Booking
(/settings/public-pages) — which is the commonest reason someone cannot find them.
| Setting | What it does | Range | Default | Start with |
|---|---|---|---|---|
| Public booking enabled | Whether the page accepts bookings at all | on / off | On | Off until you have walked through it yourself |
| Public booking interval | As above, for guests. May differ from your staff interval | 15, 30 or 60 min | 15 | Match your staff interval unless you have a reason |
| Public default duration | How long a guest's booking holds its table | 60, 90 or 120 min | 90 | Match your staff default |
| Advance notice | How close to now a guest may book — a number plus hours or days | 0–365, hours or days | 2 hours | 2–4 hours. This is a kitchen protection, not a staff one |
| Default status, public bookings | Whether an online booking arrives pending or confirmed | pending / confirmed | pending | pending while you learn your demand, then confirmed |
| Auto-assign a table | Whether an online booking is given a table immediately, or lands unassigned for staff to seat | on / off | Off | Off — deciding where people sit is a host's job (link Unassigned reservations) |
The two intervals and durations are genuinely separate
That is useful rather than confusing. A common setup is a 15-minute public interval so guests find a time that suits, with a 30-minute staff interval to keep the Timeline readable. Likewise a shorter public duration books tables a little tighter online while your staff retain the longer default.
Staff and public advance notice are also separate — deliberately
The staff minimum should usually be 0 and the public one a few hours. Someone on the phone at 18:45 asking for 19:00 should get a table; a stranger online at 18:45 should not be able to surprise your kitchen.
Ordering
The QR session idle timeout — how long a table's ordering session survives with no activity — is fixed at three hours and is not adjustable in the app. If three hours is wrong for your service, that is a support request (link Table sessions, Reporting a problem).
A worked example
A 60-seat bistro, 14 tables, dinner-led, 90-minute turns, taking bookings online and by phone:
| Setting | Value | Why |
|---|---|---|
| Booking interval | 30 min | Readable Timeline, enough choice |
| Maximum advance days | 90 | Catches birthdays and anniversaries |
| Minimum advance hours (staff) | 0 | The phone must always work |
| Min / max party size | 1 / 12 | 12 is two sixes merged; anything larger is a conversation |
| Default duration | 90 min | The actual turn |
| Table reserved window | 45 min | Enough warning on the floor without blocking walk-ins early |
| Max covers per slot | 16 | Kitchen plates about 16 mains in half an hour |
| No-show grace | 90 min | Roughly one turn — clears the diary without being harsh |
| Waitlist ready window | 60 min | Default suits a bar-waiting room |
| Default status (staff) | confirmed | Staff bookings are real |
| Default live view | floorplan | Host stand reads the room |
| Public interval | 15 min | More chance a guest finds a time |
| Public duration | 90 min | Matches the staff default |
| Public advance notice | 3 hours | Kitchen gets warning |
| Public default status | confirmed | Once trusted, stop hand-confirming |
| Auto-assign table | off | The host seats the room |
With a 30-minute interval, a 90-minute duration and 14 tables, that bistro can seat roughly three turns an evening. Its constraint is the 16-cover pacing cap, which is exactly where a constraint should be — in the kitchen's real output, not in an arbitrary number of tables.