One system for bookings, waivers, game-master timing, and payments.

One system for the whole room day: online bookings and a room calendar, waivers tied to each booking, check-in, game-master timing and hint delivery, payments and point of sale, group and corporate events, and the staff screens that run all of it. The guest-facing booking page is one part; the operator record behind it, who booked, who signed, who paid, what changed, is the part your team lives in.

Buy a maintained product when it handles your rooms with reasonable setup and its pricing makes sense. Own a custom system when your room rules, waiver rules, package logic, or multi-room setup need constant workarounds, or when repeated manual joins have a measurable daily cost. Our build-vs-buy analysis walks through where maintained booking products stop fitting and what a custom version covers, so read that before you decide.

Each waiver is tied to a booking and to the player who signed it, collected before arrival or at the desk, and retrievable by staff in seconds during check-in. Your team sets the waiver rules: which rooms and age groups need one, what happens when a player in a group has not signed, and how signed waivers carry across repeat visits. The system enforces the rules you set; it does not write your waiver policy.

One screen per room: live session timing, hint delivery, room state, and the reset checklist for when the session ends. Timing alerts surface before a session runs into the next booking's reset window, so the front desk can manage the arriving group early instead of discovering the clash at the door. Nothing about the run of show lives only in one person's head.

A group booking carries its size, per-player details, package add-ons, and payment schedule as one record, not as separate bookings your team has to reconcile. Corporate accounts keep their own booking and billing pattern. Package rules, such as what changes when the group size changes, are set once and applied the same way every time, instead of being re-decided at the desk.

Yes, when the provider exposes a documented and permitted interface. We confirm the interface, credentials, refund and failure behaviour, and reconciliation rules before committing to the connection. Payments from bookings, the desk, and the gift shop reconcile into one record with an exception queue for anything that does not match, so the close of day stops being a manual hunt.

Moving your data over is scoped as its own work, not an afterthought: what moves, what gets checked, and what stays behind are agreed before the switch. The new system runs alongside the old one first, so you can validate it against real bookings before the old tool is retired. Nothing is switched on a hope.

No. One system can serve several rooms and several locations, with per-location rules for rooms, packages, staff, and pricing where they genuinely differ. The first release starts at one location and expands once it is stable, so a problem found early is fixed once instead of once per site.

You own the code built for you and control where it lives, the cloud accounts, the data, and third-party subscriptions. Outside services and open-source pieces keep their own licence terms. The operating notes and handover material stay current so another capable team can take over.

You judge what you can see, not the code. Every checkpoint is working software you click through yourself, tested against the room day agreed at the start. Progress is reported in plain language: what changed, what is next, and what it costs. Because you own the code, the accounts, and the operating notes throughout, nothing about the work is locked inside our heads. Our job is to make the work checkable; your job is to check it against your business.