Venue Booking System Requirements (2026)

Most venue booking software models a room and a calendar. Real venues are neither.

A stadium contains concourses, which contain rooms, which combine and subdivide. A booking is rarely confirmed on first contact. And what gets booked decides how the building runs on the day — staffing, security, air conditioning. Software that treats a venue as a list of rooms with time slots against them will be worked around within a month.

Here is what actually has to be modelled, based on building Booka, the platform now live across every stadium in the Venues NSW network.

Bookings that match how space is really sold

Commercial venue sales rarely move straight from enquiry to confirmed. An enquiry becomes an interest, an interest becomes a hold, and holds compete.

Most systems offer one state — booked or not — so teams keep the real pipeline in a spreadsheet beside the software. That spreadsheet is where the money is and where the errors come from.

What is needed is tiered provisional holds: a space can be held with a clear signal of how firm that interest is, so the strongest commercial intent wins the slot. That single capability decides whether the booking system reflects the business or merely records its conclusions.

Conflict detection across a space hierarchy

This is the requirement that most off-the-shelf products fail outright.

Venues are hierarchical. Booking a concourse implicitly books the rooms within it. Combining two rooms makes a third that cannot be sold separately while the combination stands. Booking one thing implicitly books others, and the relationships are not symmetrical.

A system that does not understand the space tree will let you double-book and rely on someone noticing. In a venue, noticing happens on the day.

The system has to refuse the conflict at the point of booking, which means it needs a real model of how spaces contain, combine and exclude one another — not a flat list.

Approvals as part of the model

Some spaces cannot be booked outright. They need sign-off, whether for commercial, safety or political reasons.

If approval lives in email, the booking system is not the source of truth and everyone knows it. Spaces that require sign-off should be marked as such and route to an approver as part of the booking, rather than being bookable with a convention that someone will check.

The event, not just the slot

A booking is the beginning of an event, not the whole of it. Staffing, run sheets, timings — this is the operational layer that decides whether the day goes well, and it is almost always the part that lives outside the booking system in documents nobody can find on the day.

Reusable staffing templates that become per-event rosters, and run sheets that turn an event day into a time-ordered checklist, put that information where the booking already is.

Governance, because someone will ask

For a public body or any organisation with real accountability, two things are not optional.

Role-based access per venue, so a team manages its own venues without seeing everything else — including a separate permission set governing who can see other people’s contact details.

An audit log of every consequential action. Being able to show what changed and who changed it is not a nice-to-have when the organisation is publicly accountable; it is the difference between a system that survives scrutiny and one that does not.

The integrations that make it worth owning

This is the argument for a real platform rather than a booking tool, and it is the one most often missed at procurement.

Single sign-on through the organisation’s existing identity provider, so there is no separate account estate to manage.

An API that exposes event and space data to the building management system, which uses it to schedule HVAC, lighting and security around what is actually on. When the booking system is an island, everything downstream is manual — someone reads the calendar and sets the building by hand.

That is the real cost of a closed system: not the licence, but the manual work it forces on every process that depends on knowing what is happening in the building.

Replacing what is already there

Venues do not stop trading while you migrate. A network-wide cutover on a single date is the highest-risk way to do this and the most commonly proposed.

The safer path is venue by venue, with both systems kept in step through each transition until the last one is done. Slower, and it is the difference between a migration and an incident.

When off-the-shelf is fine

If you have a handful of identical, independently bookable rooms, no provisional holds, no approval chain and nothing downstream that needs the data — buy something. Building is the wrong answer to a solved problem.

The threshold is the space hierarchy and the commercial pipeline. Once bookings imply other bookings, and once holds have to compete, the generic products stop fitting and the workarounds begin.

What Booka looks like in practice

Booka is a Next.js and TypeScript application over Postgres, with tenant isolation enforced at the database layer rather than only in application code. More than four thousand commits and over a hundred and thirty database migrations to date, still being extended now that the whole network depends on it.

Every stadium in the Venues NSW network runs on it, and the legacy system it replaced is gone.

If you are running venues on software you have outgrown, we are happy to talk it through — including telling you when the answer is to buy rather than build.

What a Venue Booking System Actually Needs