Module: Scheduling
Scheduling
Booking an appointment sounds like one thing. In practice, it's a different thing at every business that does it.
One company has a single technician, and "the schedule" is really just his day. Another has a dozen people whose calendars have to be checked at once. One runs on Google Calendar, the next on Microsoft 365, and the one after that on a proprietary system nobody outside the company has heard of. The rules underneath are just as varied — who can be booked, when, for how long, and around what.
A scheduling feature that only works for one of those businesses isn't really a scheduling feature. The point of this module is to sit on top of whatever a business already uses and book appointments the way that business actually books them.
Every Business Schedules Differently
The differences aren't cosmetic. They change what a valid appointment even is.
- One person or many. A solo operator has one calendar to protect. A larger team means checking several people's availability at once and booking against the right one — the technician who covers that area, the provider the patient asked for, whoever is actually free.
- Working hours. A business that runs 8 to 5 shouldn't be offering 7 p.m. slots. Hours can also differ by person and by day.
- Office-wide closures. When everyone is out — a holiday, a company offsite, a day the office simply closes — nothing should be bookable, no matter who's asking.
- Blackout time. Some of the calendar isn't open even though it looks empty. Drive time between appointments, setup and teardown, buffers between jobs — a slot that ignores travel time isn't really available.
The backend a business runs on doesn't change these rules; it just changes where the answers live. Whether availability comes from Google, Microsoft 365, or an internal system, the module's job is to read the real calendar and respect the real rules, not to impose a generic idea of what a schedule should look like.
Connecting to What's Already There
Most businesses don't want to move their calendar to book an appointment. They want the tools they already use to keep being the source of truth.
This module is designed to work as the scheduling layer around a business's existing calendar system rather than as a replacement for it. Availability is read from the connected backend, appointments are written back to it, and the business keeps managing its calendar the way it always has. What's connected and how deeply depends on the system involved, its capabilities, and the business's requirements.
Confirmations
A time that's been discussed isn't the same as an appointment that's been booked.
Once a time is chosen, the appointment is confirmed back to the person, so both sides end the conversation knowing the same thing: it's on the calendar, here's when, here's where. That confirmation is what turns "sometime Thursday" into a real, written-down commitment — and it gives the person something to refer back to instead of a half-remembered conversation.
Canceling and Rescheduling
Plans change, and a schedule that can only add appointments isn't much use.
The module supports canceling and rescheduling, not just booking — so someone who needs to move a Tuesday appointment to Thursday, or cancel one altogether, can do it through the same conversation, and the underlying calendar stays accurate. A schedule is only useful if it reflects reality, and reality includes the appointments that fall through.
Only Your Own Appointment
Canceling and rescheduling raise a question booking doesn't: who's allowed to change this?
It isn't enough to find an appointment and move it. The person asking has to be the person the appointment belongs to. Without that, anyone who knew a name or a phone number could cancel someone else's booking — which is not a scheduling feature, it's a liability.
So changes are gated on verifying that the request is coming from the right person before anything on the calendar moves. Someone can manage their own appointment; they can't reach into someone else's. How that verification works depends on the channel and what the business has connected, but the principle doesn't change: the calendar only moves for the person who owns the slot.
Why This Is Hard
Scheduling looks simple from the outside because everyone has booked an appointment before. The difficulty is that "book an appointment" means something slightly different everywhere it's said.
The rules vary, the backends vary, the number of calendars varies, and the sensitive part — letting someone change a booking — has to happen without letting them change the wrong one. A scheduling module earns its place by handling that variation, not by assuming it away.