How Booking Works

A booking calendar lets people reserve time — an appointment, a class, a room, a resource.

Where to find it

Architect Panel → Layout & Pages:

• Booking Calendars — the calendar, then its row actions for everything else

Architect Panel → Data:

• Business Hours Calendars — working hours and exceptions

Everything hangs off the calendar row

The calendar itself is one record with its options. Everything else is reached as a row action on it, and there are ten of them:

• Event Types — what can be booked.
• Available Periods and Available Periods (Recurring) — when.
• Unavailable Periods — when not.
• Locations — where.
• Attendance Options — how attendance is recorded.
• Permissions — who may book.
• User Bookings and Manual Bookings — what has been booked.
• View Itinerary — the day as a schedule.

Nothing announces these, and an administrator who does not know they exist concludes the calendar cannot do any of it.

The calendar’s own options

• View mode — how the calendar is presented.
• Slot mode and availability mode — how bookable time is worked out.
• Slot unit size and time units — the granularity.
• Maximum advance booking — how far ahead people may book.
• Confirmation e-mails — whether they are sent.
• Record attendance — whether attendance is tracked.
• HTML above and below — your own content around the calendar.

Slot size is the decision to get right

It determines everything about how the calendar behaves and it is disruptive to change once people have booked. Pick the smallest unit your business actually schedules in — not smaller, because a fifteen-minute grid for hour-long appointments produces a wall of choices.

Limit advance booking

A calendar open indefinitely gets bookings eighteen months out that nobody honours. Set the horizon to what you can actually commit to.

Decide about attendance early

Recording attendance changes what the calendar is for — from a reservation system to a record of what happened. If you need that for compliance, training or billing, turn it on before you have history rather than after.

Test a booking end to end

As a real user, through permissions, into a real slot, with the confirmation arriving. Booking is customer-facing and a broken calendar is visible immediately.

Worked example

A clinic runs one calendar with thirty-minute slots, a six-week advance limit, three event types with different durations, two rooms as locations, and attendance recorded. Confirmations are on. Every configuration change is tested by booking a real slot as a test patient.

Recommendations

• Learn the ten row actions — they are the whole feature.
• Choose slot size before anybody books.
• Limit advance booking to what you can honour.
• Decide on attendance before you have history.