Availability
Availability is built from three lists: recurring periods, one-off periods, and unavailable periods.
Where to find it
Architect Panel → Layout & Pages:
- Booking Calendars — the calendar, then its row actions for everything else
Recurring periods
The backbone. Each names a day of the week, a start and end time, and a date range over which the pattern is valid. So "Mondays to Thursdays, nine to five, from January to July" is four rows.
The validity range is what lets you change a pattern at a date rather than editing history — the old pattern ends, the new one begins, and past bookings still make sense.
One-off periods
A specific start and end, for availability that does not repeat. A Saturday opening, an evening clinic, an extra session added for demand.
Both carry limits and notes
Each period can say whether slots are shown, how many bookings an event may take within it, and carry notes. So a Saturday morning can be open with a lower capacity than a weekday, without needing a separate calendar.
Unavailable periods win
A separate list of times when nothing can be booked, with a note. This is how holidays, closures and one-off absences are handled — you block them rather than editing the recurring pattern around them.
That is the right shape: the pattern stays simple and the exceptions are visible as exceptions.
Load the closures ahead
The characteristic failure is not misconfiguration but omission. Public holidays, shutdown weeks, planned absence — enter them for the year rather than the week before, because a calendar taking bookings on a day you are closed is discovered by the customer who turns up.
Check the itinerary view
Both period types offer an itinerary view showing the day as a schedule. That is the fastest way to confirm availability actually looks the way you intended, and it catches overlaps that are invisible in a list.
Watch the boundaries
The end of a recurring period’s validity, the day a pattern changes, the last slot before a closure. Those are where availability errors live, and they are quick to check once you know to look.
Worked example
A service defines recurring weekday availability with a validity range ending at its summer timetable change, one-off Saturday sessions added monthly, and a year of closures loaded each January. Availability is checked in the itinerary view after every change.
Recommendations
- Recurring for the pattern, one-off for the exceptions.
- Block closures rather than editing the pattern around them.
- Load a year of closures in one sitting.
- Confirm in the itinerary view, not the list.