One site, four different definitions of full
The ropes course is booked out privately. The lanes are allocated to whoever wants them. The play area runs continuously with timed entry. The cafe has tables that push together. No single one of those is unusual. Running all four in one building is what breaks the software.
Four capacity shapes that cannot share one availability rule
Fixed private capacity asks whether the whole thing is taken. Fixed shared capacity asks how many of the units are left. Continuous flow asks how many people are inside right now and how many more the hour can absorb. Combinable resources ask what the furniture can be rearranged into.
Those are four different questions with four different answers, and a platform built around one of them can only fake the other three. Usually it fakes them as fixed sessions with a capacity number, which is why the play area oversells at eleven and the lanes look free when they are not.
Three systems, and a person whose job is reconciling them
A booking platform for the attractions, a reservations tool for the cafe, and a point of sale that knows about none of it. Each one is defensible on its own. Together they mean a birthday party is three bookings, one customer is three records, and nobody can say what the party was worth end to end.
The cost is not the three subscriptions. It is that the questions you most want answered live in the gaps between them: attach rate from the ropes course to the cafe, whether timed-entry sessions cannibalise lane bookings, what a Saturday actually earns per head across the whole building.
One booking that consumes three kinds of capacity
A party arrives at ten, does the ropes course at ten thirty, has the room from eleven thirty and eats at twelve. That is one sale against three resources with hard ordering between them, and if any one leg is unavailable the whole thing is unavailable.
Systems that cannot express a booking spanning several resources push this onto your staff, who hold it together on the phone and in a spreadsheet, and it works until two parties want the same eleven thirty.
The capacity model is the product, so mixed sites are the normal case
Each shape is modelled as itself rather than forced into sessions: private buyout, shared allocation, timed entry against a live headcount, and combinable tables. One product can use one shape and the site next door can use another, inside the same account.
Above them sits one customer record, one voucher balance, one filter that persists across every view, and one set of reports. A voucher sold at the lanes spends in the cafe. Last Saturday is one query, not four exports.
What is live today and what is not
Fixed private and fixed shared capacity, the run sheet, check-in with waivers and the reporting layer are live. Sessions, holds and the widget are in build. Combinable tables and vouchers land at launch, and point of sale comes after it.
For most centres that means the attractions side can run now and the floor and the tab join it, which is the order we would recommend even if everything shipped tomorrow.