How Schedules Work

Before you start setting up time slots, it helps to understand the model. Booking Phoenix organises availability around three concepts: rooms, seasons, and time slots. This guide explains how they fit together and what the booking engine does behind the scenes when a customer hits your widget.

The three building blocks

Rooms

A room is a bookable thing — an escape room, a VR experience, a function space. Rooms have their own name, capacity, and pricing. A room on its own doesn't mean anything is bookable; availability comes from time slots.

Seasons

A season is a set of date ranges during which a particular timetable applies. Typical seasons: "Winter Hours", "Summer Hours", "School Holidays", "Public Holiday Schedule". Each season has one or more date ranges attached — a season can cover "1 Dec – 31 Jan" plus "all weekends in April" if you want.

Time slots

A time slot belongs to a season and a room, and defines:

• A start time (e.g. 10:00am)
• The days of the week it runs (e.g. Fri, Sat, Sun)
• How many parallel bookings it can take (availability)

If a room can run two groups at once, that's availability = 2 on each slot.

[SCREENSHOT: A diagram or flowchart showing Room → Season → Time Slots with examples of each]

How the booking engine uses this

When a customer picks a date on the booking widget, here's what happens:

1. The system looks up which season covers that date, per room.
2. It finds all time slots belonging to that room + season, filtered to the day-of-week.
3. For each slot, it counts existing bookings on that date and subtracts from availability.
4. Slots with remaining availability are shown as bookable; full slots show as "sold out".

Why seasons are powerful

Seasons let you run completely different timetables without duplicating rooms. Some common patterns:

• Weekday vs weekend hours. Create one season named "Weekend" with date ranges covering every Saturday and Sunday of the year, and another "Weekday" season for Monday–Friday. Slots in each have different start times.
• School holidays. A "School Holidays" season with extra morning slots, so your room runs 10am/12pm/2pm/4pm instead of just 2pm/4pm.
• Short-term changes. A "Renovations" season covering a two-week window with no slots at all — effectively makes the room unbookable for that period without deleting anything.

Overlap and priority

Seasons must not overlap dates. If two seasons cover the same day, the booking engine doesn't know which timetable to use — you'll see a warning when saving. Plan your date ranges carefully; think of them as non-overlapping slices covering the year.

Slot availability and resource size

Availability controls parallel bookings. If your "Haunted Mansion" can physically run two simultaneous groups, set availability = 2 on each slot and the room will accept two bookings at 7:00pm on the same night.

Room-level Resource Size is a different concept — used when rooms share a resource (e.g. two rooms share a single games-master). Resource Size says "this room consumes N units" and the calendar caps how many units can run at once across the branch. If you don't share resources, leave it at 1.

Public holidays

If your branch has a separate public-holiday schedule (higher prices, different capacities), the Override for Alternative Holidays switch on each room lets you override limits and pricing for those dates without creating a whole new season. You'll see this on the Players tab and Pricing tab of the room edit modal.

Next steps

Now that you understand the model:

• Setting Up a Schedule and Managing Time Slots — step-by-step for a brand-new room.
• Managing a Room's Schedule — day-to-day operations once it's set up.
• Setting Up Room Pricing — pricing groups also respect effective dates (a similar idea to seasons, but for prices).