Calendars and Scheduling

Calendars and Scheduling is the booking engine of the platform. A calendar here is not a calendar; it is a bookable service definition. It says what is being booked, who can deliver it, how long it takes, how far ahead and how far out it can be booked, what happens either side of it, and what the platform should do the moment a slot is taken. The calendar view is only one way of looking at the bookings that definition produced.

Because each calendar is a service definition, an account usually has several: a short discovery call, a long consultation, a group class, a multi-person onboarding session. Each gets its own duration, its own team members, its own intake form and its own follow-up. Operators who push every appointment type through a single calendar end up with reminders that say the wrong thing and availability that makes no sense.

The mental model that matters is that availability is calculated, not stored. The platform starts from the calendar's open hours, subtracts what is already booked, subtracts conflicting events on each team member's connected external calendar, subtracts buffers either side of existing appointments, then applies notice periods and per-day limits. A slot a client cannot see is almost never a broken calendar; it is one of those subtractions doing its job.

Calendar types

• Service calendar: one appointment type delivered by one person or resource, the default for a consultation or a treatment.
• Round-robin calendar: several team members behind one booking link, with slots distributed by availability and by a distribution rule such as even spread, priority order or who was booked least recently.
• Class or event calendar: fixed sessions at fixed times with a capacity, so many attendees book the same slot rather than consuming it.
• Collective calendar: a slot only offered when every required attendee is free, for panel interviews and multi-clinician reviews.
• Group or unassigned calendar: bookings taken without being pinned to an individual, assigned afterwards by a human or a workflow.
• Calendar groups: several calendars presented together on one page so a client picks the service first and the slot second.

Availability rules

• Weekly open hours per calendar, and per team member where the calendar is shared
• Date-specific overrides for holidays, training days and one-off late openings
• Slot interval and slot duration set separately, so a 50-minute appointment can be offered on the hour
• Minimum scheduling notice, and a maximum booking window limiting how far out clients can reach
• Buffers before and after an appointment for travel, notes or room turnover
• Maximum bookings per slot and per day, per calendar and per team member
• Timezone handling: the calendar's own timezone, and whether the booking page displays slots in the visitor's detected timezone

The booking form and page

• Which standard fields are collected, which are required, and which custom fields are appended
• Custom questions that write to contact or appointment fields, including consent and intake questions
• Guest or additional-attendee capture, and how many guests a booking may add
• Confirmation behavior: a thank-you message, a redirect to a page you built, or a payment step before the slot is held
• Branding, logo, cover image, text and language on the booking widget, and embedding it in a funnel page, a website page or a standalone link

Reminders, confirmations and follow-up

• Confirmation and reminder messages by email and SMS, with their own timing offsets
• Calendar invitations with location, joining link or address, and the generated conferencing link where a video provider is connected
• Reschedule and cancellation links, and how far in advance each is permitted
• Workflow triggers on booked, rescheduled, canceled, no-show and completed

Team, resources and connections

• Team member assignment, each member's own hours, and their connected external calendar for two-way conflict checking
• Google and Outlook calendar connections, and which direction events flow
• Appointment statuses (confirmed, showed, no-show, canceled) and who is expected to set them
• Payment collection on booking through a connected processor, including deposits for services

1. Write down the service before you touch the platform: what it is called, how long it lasts, who delivers it, where it happens, what has to be known before it starts, and what should happen afterwards. One service, one calendar.
2. Decide the calendar type from how the slot is consumed. One person taking the slot is a service calendar; several people sharing the slot is a class; any of several staff being acceptable is round-robin; everyone needing to attend is collective.
3. Connect each team member's external calendar first, before you publish anything. Conflict checking only works against calendars the platform can see, and doing this later means double bookings in between.
4. Set the slot duration and the slot interval as two separate decisions. Duration is how long the appointment runs; interval is how often a start time is offered. Mismatching them is how clinics end up with appointments starting at awkward minutes.
5. Enter the weekly open hours, then immediately add the date overrides you already know about: public holidays, training days, the week the owner is away. An override entered now is a no-show avoided later.
6. Set minimum notice and the maximum booking window. Notice protects the team from a booking fifteen minutes out; the window stops someone booking eight months ahead and forgetting.
7. Add buffers either side if the work needs turnover time, then re-check the visible availability. Buffers compound with existing bookings and can thin a day far more than expected.
8. Set the per-day and per-slot caps so a busy day cannot be overloaded, and so a class cannot be oversold past room capacity.
9. Build the booking form with the minimum fields that make the appointment useful, and mark required only what you truly need. Every extra required question costs bookings.
10. Write the confirmation, then the reminder sequence, as separate messages with their own timing. Include what to bring, where to go, and how to reschedule in each. Put the reschedule and cancellation links in every one.
11. Decide the confirmation destination: a thank-you message, a redirect to a prepared page, or a payment or deposit step if the slot should only be held once money is taken.
12. Attach the workflows. At minimum, trigger one on booked for confirmation and internal notification, and one on no-show or canceled for recovery. An appointment that nobody is told about is an appointment nobody prepares for.
13. Embed the booking widget where clients actually arrive (the funnel page, the website page, the reply template the team sends) and keep the standalone link for staff to paste in conversations.
14. Book a real test appointment as an outside visitor, from a different timezone if clients come from more than one, and check the slot offered, the invitation, the conferencing link and every reminder as they arrive.
15. Test the reschedule and cancel paths from the client's side, then confirm the slot is released and the external calendar updates both ways.
16. Agree who marks showed and no-show, and when. Every downstream report and recovery workflow depends on a human setting that status honestly.

Scheduling is where most builds turn interest into a commitment, so it sits between the capture modules and the delivery ones. Funnels and forms feed it, workflows wrap around it, the inbox and the phone system let staff book on a client's behalf, pipelines track the appointment as a deal stage, and payments can gate the slot. Reporting then reads booked, showed and no-show counts as the honest measure of whether the marketing worked.

Paid traffic to a kept appointment

An ad sends traffic to a funnel page with the booking widget embedded. The booking fires a workflow that confirms by email and SMS, creates an opportunity at a booked stage, assigns the owner from the round-robin result, and sends reminders at the intervals the client actually responds to. A no-show status moves the opportunity back and starts a recovery sequence. The whole path is one calendar, one workflow and one pipeline.

Inbound call to a same-day slot

A missed call triggers a text back from the phone system. The reply lands in the unified inbox, where a receptionist (or BO, if the conversation agent is handling it) sends the booking link for the short-notice calendar, which has a tighter notice period and no deposit. Because the calendar is separate from the standard consultation, the availability rules can be looser without affecting the main calendar.

Group program with paid enrollment

A class calendar holds weekly sessions with a capacity. The booking page collects a deposit through the connected processor before the seat is held, then a workflow enrolls the contact in the matching course inside Memberships so the materials unlock on the same day. Attendance statuses drive both the reminder cadence and the certificate at the end.

• Timezones are the single biggest source of scheduling complaints. The account, the calendar, each team member and the visitor's browser can all disagree. Always test a booking from outside your own timezone before going live.
• An unconnected external calendar means no conflict checking. The platform cannot avoid an event it cannot see, so a staff member with a private calendar will be double booked.
• Buffers and caps compound. A buffer either side plus a daily cap plus a notice period can collapse a day to one or two visible slots. If availability looks wrong, remove the rules one at a time rather than guessing.
• Round-robin distribution is not fairness. Whoever has the most open hours receives the most bookings. If one person's calendar is fuller, they drop out of the rotation whether or not that was intended.
• Collective calendars rarely show slots. Requiring several calendars to align means availability thins dramatically. Keep the attendee list to those genuinely required.
• Class capacity does not manage a waiting list by itself. Once a session is full it simply disappears from view. If a waiting list matters, build it with a form and a workflow.
• Reminders are not sent if the message channel is not configured. An SMS reminder on an account with no number, or with an unverified sending domain for email, silently fails.
• Rescheduling can orphan the follow-up. A workflow that already started counting from the original date keeps counting unless the reschedule event resets it. Handle rescheduled as its own trigger.
• No-show status is manual. Nothing sets it for you. If the team does not mark attendance, recovery sequences never fire and the reporting flatters the business.
• Changing a calendar's duration or hours does not move existing bookings. Appointments already taken stay where they are, which can leave them overlapping the new rules.
• Deleting a calendar breaks every link to it. Embedded widgets, pasted booking links and workflow steps that reference it all stop working, usually without a warning anywhere visible.
• Payment on booking does not guarantee a held slot. If the processor session is abandoned, behavior depends on how the confirmation step is configured. Test the abandoned-payment path deliberately.
• Cloned builds carry the original team members. Duplicating an account's calendars copies assignments and calendar connections that belong to someone else. Re-check every team member after a clone.