The problem is rarely described as a booking problem. It is described as reception being overwhelmed at nine in the morning, patients ringing three times, and a voicemail box nobody has time to clear. Then someone calculates how many of those callers simply gave up, and the conversation turns to booking online.
An online booking system for clinics is not the same product as a booking system for a barber or a restaurant, and the difference is not the calendar. It is the rules around the calendar, and the things the system must never do. Get those wrong and you have automated a compliance problem.
What a clinic booking system has to get right
Every booking tool shows available times and takes a name. These are the parts that separate one built for healthcare from one that is not.
- Appointment types with different lengths and rules. A first consultation is not a review is not a procedure. Each needs its own duration, its own preparation time, and often its own eligibility.
- Who can be seen by whom. A patient of one clinician should usually book with that clinician. Some appointment types need a specific qualification. This is the rule most generic tools cannot express.
- Buffers and turnaround. Rooms need cleaning, notes need writing, and a calendar that books back to back without gaps produces a day that runs forty minutes late by lunchtime.
- Cancellation rules that actually hold. How late a patient can cancel, what happens then, and whether the slot is released automatically to a waiting list.
- Waiting lists. The single highest-value feature and the one most often missing. A cancellation at eight in the morning should be offered to someone before reception has to think about it.
- Rescheduling without a phone call. A large share of calls are moves, not new bookings, and handling those online removes more work than new appointments do.
Connecting it to the calendar you already run
This is where most implementations either succeed quietly or fail expensively, and it is worth being precise about what you are asking for.
A booking system that keeps its own calendar creates two sources of truth, and two sources of truth become one double booking, usually within a fortnight. What you want is for the system your clinicians already look at to remain the only calendar that matters, with online bookings appearing in it and anything blocked out there disappearing from what patients can see.
The practical questions to put to any supplier: does it write into our existing calendar or only read from it, how quickly does a change in one appear in the other, and what happens when the connection fails for an hour. That last answer matters most. A system that quietly stops syncing and keeps taking bookings is worse than one that stops taking bookings and says so.
Reminders and the no-show problem
Reminders are the cheapest part of the whole system and usually the part that pays for it, so they deserve more thought than they get.
- Confirm immediately, in whatever channel the patient used. The confirmation is also the record they will look for later.
- Remind once, well ahead, far enough out that the person can still move it. A reminder that arrives too late to act on generates a call rather than preventing one.
- Remind again the day before, with a one-tap way to cancel. Counterintuitive, and it works: making cancellation easy converts a silent no-show into a slot you can refill.
- Feed cancellations to the waiting list automatically. The value of an easy cancellation only appears if something fills the gap.
- Keep the content minimal. Time, place, and how to change it. Which brings us to the part people get wrong.
Privacy, and what the system must never do
We are not lawyers and this is not legal advice, and your obligations depend on where you are and what kind of practice you run. What follows is the engineering side, and it is the part suppliers should be raising with you unprompted.
- A reminder is not a place for clinical detail. The message can say there is an appointment, when, and where. It should not say what for. Messages are read on lock screens by other people.
- Nothing personal before identity is established. A booking reference is not identity. Anything that reveals history, results or previous appointments belongs behind a proper sign-in.
- No advice, ever, from an automated assistant. If you add a chat layer to help with booking, it books and it answers questions about opening hours. The moment a patient describes a symptom, it hands over to a human, and it should be built so that it cannot do otherwise. This is the single most important constraint in the whole build.
- Know where the data sits and who can reach it, including any supplier's support staff. Ask, and get the answer in writing before you sign.
- Collect the minimum. Every extra field is something to protect, and reception can ask the rest at the desk.
- Log who looked at what. You will eventually need to answer that question, and the time to enable it is before you need it rather than after.
If you are considering adding an assistant to handle enquiries alongside booking, when you should not build a chatbot sets out the test, and clinical questions fall squarely in the category where a confident wrong answer is expensive. Our chatbot work treats a hard handover to a human as a requirement rather than a feature.
Build, embed, or buy
| Buy a platform | Embed and extend | Build | |
|---|---|---|---|
| What it is | A booking product aimed at clinics, used as it comes. | A platform for the calendar, with your own layer for the parts it cannot do. | A booking system built around your rules, connected to your systems. |
| Illustrative cost | $30 to $300 a month | $10,000 to $35,000 plus the subscription | $40,000 to $120,000 and up |
| Live in | Days | Weeks | Two to four months |
| Suits | One site, straightforward appointment types, standard rules. | Mostly standard, with one or two rules the product cannot express. | Multiple sites, complex eligibility rules, or connecting to a records system. |
| Watch for | Per-clinician pricing, and a ceiling you meet suddenly when a rule does not fit. | Being locked to that platform's model. Understand what you would lose if you left. | Maintenance forever, and a compliance surface that is now yours. |
Illustrative ranges from the kind of work we quote, not a price list. For a single-practitioner or single-site clinic, the first column is almost always the right answer and we will say so.
How to start without committing to anything
- Count the calls for a week, split into new bookings, changes, cancellations and everything else. Most practices find changes and cancellations outnumber new bookings, which changes what to build first.
- Write down the rules nobody has written down. Who can see whom, what needs a longer slot, what must never be booked online at all. This document is the project.
- Put the two most common appointment types online first. Not all of them. You will learn more from a fortnight of real use than from three months of specification.
- Keep the phone line exactly as it is. Online booking should absorb demand rather than replace a route, and patients who prefer to ring are not a problem to solve.
- Measure the calls after a month, honestly, against the count you took in week one.
Not for you if
One test worth applying to any demonstration you are given: ask the supplier to show you what happens when a patient tries to book something they are not eligible for. If the answer is that reception catches it, the system has not solved your problem, it has moved it.