Booking Calendars

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.

Creating a Calendar

A calendar is quick to create and easy to configure in an order that produces rework.

Where to find it

Architect Panel → Layout & Pages:

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

Decide first

1. What is being booked — a person’s time, a room, a piece of equipment, a place on a class.
2. The unit — how long the shortest booking is.
3. Who may book — everybody, signed-in users, one group.
4. Whether attendance matters.

Those four decide most of the configuration.

Then build in this order

1. Create the calendar and set slot size, view mode and the advance limit.
2. Add locations, if bookings happen in more than one place.
3. Add event types — what can actually be booked.
4. Add form fields to each event type, if you need information from the person booking.
5. Add available periods, recurring where the pattern repeats.
6. Add unavailable periods for known closures.
7. Set permissions.
8. Set up confirmations.
9. Book a test slot as a real user.

Availability last among the configuration, because it depends on the event types and locations existing.

One calendar or several

One calendar per bookable thing where each has its own availability — three consulting rooms with different opening hours are three calendars. One calendar with locations where availability is common and only the place differs.

Getting this wrong produces either a calendar that cannot express your availability, or five calendars maintained in parallel.

Use the HTML areas

Content above and below the calendar is where you explain what somebody is booking, what to bring, and what happens if they cannot attend. That is the cheapest reduction in support contact available.

Set permissions before publishing

So the calendar is not bookable while half-configured. A calendar with no availability and no event types, reachable by customers, generates confused enquiries.

Test as somebody else

Your own account probably has permissions nobody else does. Book as a test user with exactly the access a real person would have.

Worked example

A training provider set up one calendar per venue because opening hours differed, each with recurring weekday availability, three course types as event types, and a form field asking about accessibility requirements. Permissions were set before it went live, and a test booking was made from a fresh account.

Recommendations

• Decide the four questions before creating anything.
• Availability last — it depends on the rest.
• Separate calendars where availability genuinely differs.
• Test from an account with real permissions.

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.

Event Types

An event type is a thing somebody can book. A calendar with no event types has nothing to offer.

Where to find it

Architect Panel → Layout & Pages:

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

What an event type carries

• Name and description — what the person is booking.
• Slot time — how long it takes.
• Colour — how it appears on the calendar.
• Maximum bookings — capacity for that event.
• Type — how it behaves.

Duration per event type is the point

A calendar can offer a fifteen-minute follow-up and a ninety-minute assessment side by side, each consuming the right amount of time. That is what makes one calendar workable for a real service rather than needing one per appointment length.

Capacity distinguishes appointments from classes

A maximum of one is an appointment. A maximum of twelve is a class, a session or a group. The same calendar can hold both.

Be realistic about capacity — it is the number that decides whether people are turned away or a room is overcrowded.

Colour is not decoration

On a busy calendar it is how staff read the day at a glance. Use it consistently and few enough that the meaning is learnable — three or four colours, not one per event type when you have twelve.

Form fields collect what you need

Each event type can have its own fields, added as a row action. That is where you ask what the appointment is about, whether the person has particular requirements, or a reference number.

Ask at booking, not afterwards

Information asked at the point of booking gets answered. Information chased afterwards mostly does not, and the chasing is somebody’s job.

But ask only what changes what you do. Every field is a reason to abandon a booking.

Keep the list short

A person choosing from four event types chooses. A person choosing from fifteen guesses, and the guess is somebody else’s problem to correct later.

If you genuinely have many, consider separate calendars for distinct audiences instead.

Review durations against reality

Appointments that consistently overrun mean the slot time is wrong, and the calendar is quietly promising more than the day can hold. That shows up as a schedule that runs late every afternoon.

Worked example

A clinic offers four event types — new assessment at ninety minutes, follow-up at thirty, review at fifteen, and a group session with capacity twelve. Each asks one question at booking. Durations were revised after three months when follow-ups were consistently running over.

Recommendations

• Set real durations and revisit them against what happens.
• Capacity distinguishes appointments from group sessions.
• Ask at booking, and only what changes your actions.
• Four or five event types, not fifteen.

Locations and Attendance

Two features that turn a booking calendar into a record of what happened.

Where to find it

Architect Panel → Layout & Pages:

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

Locations

A calendar can have sub-locations — rooms, chairs, bays, sites. Bookings are made against one, so a single calendar can schedule several places sharing the same availability.

Locations or separate calendars

Use locations where availability is common and only the place differs — four identical treatment rooms open the same hours. Use separate calendars where each place has its own opening hours, staff or event types.

The wrong choice shows up as either a calendar that cannot express your hours, or several calendars maintained in parallel with the same edits.

Attendance options

You define the outcomes — attended, did not attend, cancelled, arrived late, whatever your service actually distinguishes — each with a colour.

Recording attendance is a calendar-level setting, so it is on or off for the whole calendar.

Define outcomes that mean something

Few, distinct, and matched to a decision. "Did not attend" and "cancelled in advance" are different because you would treat them differently; "cancelled" and "cancelled by customer" probably are not.

A long list means people pick the first plausible one and the data stops meaning anything.

Why attendance matters

• Charging — for missed appointments, or for what was delivered.
• Compliance — proving training was attended, not merely booked.
• Capacity — a slot with a persistent no-show rate is a slot to overbook or to move.
• Follow-up — somebody who missed an appointment usually still needs it.

Record it promptly

Attendance recorded at the time is accurate; attendance recorded on Friday for the week is remembered. Make it part of closing the session rather than an administrative task.

Colours are for the day view

Staff should be able to look at the schedule and see what happened without reading. Keep the palette obvious — one colour for attended, one for did not attend, and the rest muted.

Look at the pattern

No-shows cluster — a time of day, a day of week, an event type, a first appointment. That pattern is actionable in a way an overall rate is not.

Worked example

A service runs four rooms as locations on one calendar and records attendance with four outcomes. Reviewing no-shows showed they concentrated in first appointments booked more than three weeks ahead, which led to a reminder two days before and a shorter booking horizon.

Recommendations

• Locations for shared availability, calendars for different hours.
• Few, distinct attendance outcomes.
• Record at the time, not at the end of the week.
• Look for the pattern in no-shows, not the rate.

Who May Book

A calendar’s permissions decide which groups may reach it and what they may do.

Where to find it

Architect Panel → Layout & Pages:

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

Admin Panel → User Administration:

• User Groups — the groups themselves

Permissions are per calendar and per group

Each entry names a group and what it may do. So one calendar can be bookable by customers, administered by staff, and invisible to everybody else.

Three roles, usually

• Book — make and see their own bookings.
• Administer — see everything, make manual bookings, record attendance.
• View — see the schedule without changing it.

Most calendars need exactly these three, and mapping them onto existing groups is usually the whole task.

People must not see each other’s bookings

The requirement that matters most on a customer-facing calendar. A booking often reveals something — that somebody has an appointment at a clinic, a meeting with a solicitor, a session with a service.

Test it explicitly: book as one customer, sign in as another, and look.

Set permissions before publishing

A calendar reachable while half-configured takes real bookings into availability you have not finished defining. Restrict it while you build.

Public calendars need thought

If anybody can book without signing in, you have an unauthenticated form creating records. Consider what stops abuse — verification, rate limiting, a booking horizon — before opening it.

Administrators can see everything

Including the form fields people filled in, which may be sensitive. Grant administration to the people who need it for the service, not to everybody who works there.

Test as a real user

From an account with exactly the groups a customer or a member of staff would have. Reading the permission list tells you what you configured; signing in tells you what you did.

Review when groups change

Calendar permissions reference groups, and a group repurposed for something else silently changes who can book. When groups are reorganised, check the calendars.

Worked example

A clinic calendar is bookable by the Patients group, administered by Clinicians, and viewable by Reception. A test patient account confirmed one patient cannot see another’s bookings — checked again after a group reorganisation, which had briefly widened it.

Recommendations

• Restrict before publishing.
• Test customer-to-customer visibility explicitly.
• Administration to those who need it for the service.
• Re-check calendars after any group reorganisation.

Confirmations and Reminders

Confirmation e-mails are a calendar-level setting, and the message is where most of the value is.

Where to find it

Architect Panel → Layout & Pages:

• Booking Calendars — the calendar, then its row actions for everything else
• E-mail Templates — the message

Architect Panel → Integration & Connections:

• E-mail Accounts — what it is sent from

What a confirmation must contain

• What was booked, in words the person recognises.
• When, with the day of the week spelled out.
• Where, including the location if the calendar has several.
• What to bring or prepare.
• How to cancel or change it, and by when.
• Who to contact — a monitored address, not a no-reply.

Most confirmations contain the first two and stop, and every one of the remaining four is a support contact you will otherwise receive.

Spell out the day

"Thursday 14 May at 2:30pm" is read correctly. A date alone is misread, particularly across countries where the number order differs.

Say how to cancel prominently

Somebody who cannot easily cancel does not cancel — they simply do not turn up, and you have lost the slot as well as their attendance. Making cancellation easy is the cheapest way to recover capacity.

A reminder is worth more than the confirmation

Bookings made weeks ahead are forgotten. A reminder a day or two before is consistently the single most effective reduction in no-shows, and it is built as a rule or a journey rather than as a calendar setting.

Two days is usually better than one — it leaves time to rearrange rather than only to cancel.

Send from something monitored

People reply to confirmations, to change a time or ask a question. A no-reply address turns that into a missed appointment.

Include a calendar invitation where you can

Something the recipient can add to their own calendar removes the transcription step where the wrong time gets written down.

Test the whole message

Book a real slot and read what arrives, on a phone. Confirmations are read on phones, and a message that looks fine on a screen frequently does not.

Cancellations deserve a message too

Both ways. A cancellation confirmed in writing prevents the person turning up anyway, and a cancellation by you needs to reach them reliably.

Worked example

A service sends a confirmation naming the day, time, room, what to bring and a cancellation link, from a monitored address, with a calendar invitation attached. A reminder two days before is sent by a rule. No-shows fell by roughly a third after the reminder was introduced.

Recommendations

• Answer all six questions in the confirmation.
• Add a reminder two days ahead — it matters more than the confirmation.
• Monitored sending address, never no-reply.
• Read the message on a phone before going live.

Manual Bookings and Itineraries

Not every booking is made by the person attending. Manual bookings cover the ones staff make.

Where to find it

Architect Panel → Layout & Pages:

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

Two lists, deliberately

User bookings are made by the person themselves; manual bookings are made by staff on somebody’s behalf, recording a name rather than a user account.

Keeping them separate is right — a booking taken over the telephone for somebody who has no account is a different thing from one somebody made online, and conflating them loses that.

When manual bookings are needed

• Telephone bookings from people who will not use a website.
• Walk-ins recorded after the fact.
• Blocking time for something that is not a customer booking.
• Rearranging on somebody’s behalf.

They still consume capacity

Which is the point. A manual booking occupies the slot exactly as a user booking does, so the calendar stays truthful about what is available.

Record enough to identify the person

A manual booking carries a name and additional information. Whoever is on reception when that person arrives needs to recognise the booking, and a name alone is often not enough.

Do not use them to work around configuration

The temptation. When availability does not allow something, a manual booking makes it happen — and the underlying configuration stays wrong, so it happens again next week.

If staff are routinely booking manually into unavailable time, fix the availability.

The itinerary view

Available from the calendar and from individual periods, showing the day as a schedule rather than a list of records.

That is what staff actually want: what is happening today, in order, in one place. It is also the fastest way to spot a gap, an overlap or a slot that should not have been bookable.

Use it as a daily check

A look at tomorrow’s itinerary catches problems while there is still time to telephone somebody — a double booking, an appointment in a room that is unavailable, a session with nobody assigned.

Confirm manual bookings too

Somebody booked over the telephone still benefits from written confirmation, and is more likely to attend for having received one. Take an address where you can.

Worked example

A service takes roughly a third of its bookings by telephone, recorded as manual bookings with a name and contact number, with a confirmation sent where an address is given. Reception reviews tomorrow’s itinerary each afternoon, which regularly catches something worth a telephone call.

Recommendations

• Keep manual bookings for real bookings, not configuration workarounds.
• Record enough to identify the person on arrival.
• Review tomorrow’s itinerary daily.
• Confirm manual bookings in writing where you can.