A table is not a fixed number of seats
A two and a four become a six. The six splits back at nine o’clock. Whether you can take a booking depends on what the floor can be rearranged into, not on what it happens to look like right now. This is the shape of capacity we are building for, and it is at launch rather than live today.
Availability is a question about combinations, not counts
Booking software that stores a seat count against a table can answer “is table nine free”. The question you actually ask a hundred times a night is “can I seat six at seven thirty”, and the answer might be one table, or two pushed together, or no because the pair that would combine are on either side of a walkway.
So the model has to hold adjacency, which tables can join which, what the combined capacity is, and what combining them costs you elsewhere on the floor. A six taken from two twos removes two separate deuces from the same hour.
There is no session, there is a table becoming free again
An escape room starts at seven and ends at eight because the product says so. A table starts when the party sits and ends when they leave, and the difference between those two on a Friday is the whole night’s second turn.
Duration is an expectation rather than a fact, and it varies by party size, by day, by whether they are eating. Availability has to be built on expected occupancy with a buffer for the turn, and it has to bend when the floor runs late rather than pretending the diary is still correct.
Two demand streams, one floor, and only one of them is in the system
Most reservation tools treat a walk-in as an afterthought typed in later. But a walk-in consumes exactly the same resource a reservation would have, so a diary that does not know about them is wrong from the first busy hour of service.
Held-back capacity for walk-ins has to be a rule the system understands, not a section of the floor your host mentally reserves. Otherwise online availability keeps selling the tables you were saving.
Combinable resources as a first-class model
Tables are resources with adjacency and join rules, so a booking can hold more than one of them and release them independently. Expected duration drives the turn, buffers are per party size rather than global, and holds are placed during checkout so a table cannot be sold twice while someone is entering their card.
And because the same account also runs whatever else is on your site, a table booked beside an experience is one customer record and one report, not two systems agreeing by coincidence.
At launch, and we would rather say so
Combinable resources are being built now and land at launch. If you run tables today and nothing else, this is not yet the thing to move to, and we will tell you that on a call rather than after you have signed.
If you run tables alongside experiences, the experiences side is live and the floor joins it, which is the order most mixed sites want anyway.