Clinic Booking Software Problems: The 7 That Cost Real Revenue, and How to Avoid Them

Why does the brief say online booking when the job is patient flow?

A practice manager asks for online booking because that is the visible complaint: patients ring during clinic hours and the front desk cannot answer. So the specification describes a public page with available times on it. Six weeks in, the questions start. Can a hygienist appointment be chained to a dentist appointment. Can a physiotherapy patient book a course of twelve sessions in one action. Does a slot need a room as well as a clinician. What happens when a new patient needs a longer first appointment than a returning one. What happens when a clinician works Tuesdays at one site and Thursdays at another.

None of those are edge cases. They are the practice's actual patient flow, and they were left out because the brief described a booking widget. The rework is not a screen, it is the scheduling model underneath, which is why this failure is expensive rather than annoying.

The fix costs a week and saves a quarter. Before anything is designed, write out every appointment type you offer, and for each one record the duration by patient category, every resource it consumes including rooms, chairs and equipment, whether it must be chained to another appointment, whether it repeats as a series, and who is allowed to book it without a triage step. Practices are consistently surprised by how long that list is. That list is the specification. A vendor who quotes without asking for it is quoting for a widget.

What goes wrong when you migrate the existing appointment book?

Two things, and neither is a technical problem.

The first is that the old diary encodes rules nobody wrote down. A recurring block on Wednesday afternoons that is actually admin time. A column that is a room, not a person. A colour that means the patient has not paid. Appointment types that were created in 2019 and are used for something else entirely now. Free text in the notes field carrying clinical information, allergy warnings, or a safeguarding flag, because there was no proper field for it. Migrating that faithfully imports the mess; migrating it cleanly loses information the clinicians rely on and did not mention because it is obvious to them.

The second is that patient records and appointments have different owners. The appointment book can move on a weekend. The patient record cannot casually move anywhere, because it is protected health information and every copy you create is a copy you have to secure, log and eventually dispose of.

The approach that works is to migrate forward, not backward. Take future appointments only, from a defined cut date, plus the patient identifiers needed to attach them. Leave historical appointments in the outgoing system, kept readable for a defined period. Extract the undocumented rules by sitting with whoever has run the diary longest and asking what each colour, column and block means, then encode those explicitly rather than importing them. And treat any free text field containing clinical or sensitive information as a finding to be fixed in the new model, not a string to be copied across.

Why do EHR, SMS, payments and telehealth integrations break after launch?

Each breaks in its own way and each is predictable.

The health record integration breaks when access changes. Some systems, including Cliniko and Jane, expose usable interfaces. Larger platforms such as athenahealth or Epic frequently gate integration behind a partner programme with its own approval timeline, its own contract and its own sandbox. A booking system built against a sandbox before production access is confirmed is a system built on an assumption. When the assumption fails, the practice inherits permanent double entry.

Messaging breaks quietly and gets expensive. Delivery numbers get filtered, a template gets flagged, a carrier changes its rules, and appointment reminders stop arriving. Nobody complains, because a patient who did not receive a reminder does not know to. The first signal is the no show rate rising a month later.

Payments break on refunds and part payments rather than on taking money. Deposits are easy. Refunding a cancelled deposit, applying it to a rescheduled visit, or splitting a payment between the patient and an insurer is where the reconciliation with your accounts falls apart.

Telehealth breaks on identity. A join link that works is not the same as a join link that only the right person can use.

The fixes are the same in each case: confirm production access before anything is built on top of it, monitor delivery and success rates with an alert rather than waiting for complaints, and get a signed business associate agreement from every provider that touches patient data before go live rather than after.

What happens when HIPAA is treated as a feature toggle?

You inherit somebody else's data model and your exposure becomes invisible. The pattern is consistent. A generic booking tool signs a business associate agreement on a higher pricing tier, so the practice assumes it is covered. Then a receptionist puts the reason for the visit into a notes field designed for a dinner reservation. Intake answers about medication and history sit in a form builder with no field level access control. Reminder text messages include the appointment reason because it is helpful. Every one of those decisions is yours, not the vendor's, and every one of them widens the surface.

Custom development does not solve this by existing. It solves it by letting you decide what is collected, where it lives, who can see it, and how long it is kept, and then only if the vendor implements those decisions deliberately and documents them. What that means in practice is encryption in transit and at rest, role based access so the front desk sees scheduling data and not clinical notes, audit logging that records who viewed which record and when, a retention rule per data type, and a signed agreement with every subprocessor handling messaging, video and payments.

The specific gap to close early is the intake form. It is the place where clinical information enters a scheduling system, and it is almost always designed by whoever built the booking flow rather than by whoever is accountable for compliance. Decide the minimum data set before it is built, and refuse fields that exist because they might be useful.

Should you build custom or configure the scheduler you already own?

A large share of practices should configure what they have and spend the money on clinicians instead. If you are a single provider or a small practice with one site, light intake needs, and a practice management system that already includes online booking, use it. Cliniko and Jane both ship competent patient facing booking, and a tool such as SimplyBook or Appointy will handle a simple diary for a monthly fee. Paying for a custom build to reproduce those is a poor trade, and the honest vendor tells you so before the proposal, not after.

The build case begins when your patient flow stops fitting a calendar. Two way sync your existing connectors do not reach. Multiple providers, rooms or sites requiring resource aware slots where double booking is impossible by construction. Treatment plan series, referral routing, or insurance eligibility as part of how you actually operate. Patient data on infrastructure you control with a compliance posture you can show an auditor. Or booking as something patients choose you for, such as a branded practice application.

A middle path is usually the right one even when you do build: construct the booking, intake and scheduling model yourself, and use proven infrastructure for messaging, video and payments rather than rebuilding any of them. You get control where it matters and speed where it does not.

How do hidden costs get into a clinic booking quote?

Five items, and they are consistent across the projects we deliver.

• Health record integration when access is partner gated. Contract and approval time you do not control, plus workaround engineering if the interface is thin. This is the single largest source of overrun in clinic projects.
• Compliance work done properly. Access controls, audit logging, encryption, subprocessor agreements and the documentation that proves it. Not padding, and not a checkbox.
• Message volume. Reminders, confirmations, reschedule links and waitlist offers are per message costs that scale with patient numbers and are usually left out of the build price entirely.
• Insurance eligibility. Verifying coverage before a visit touches clearing houses and payer specific behaviour, and it is a project rather than a feature.
• Parallel running. The old diary and the new system run together for a period, and someone has to keep both correct.

Ask for the health record integration to be quoted separately, with the specific system named and the access route confirmed in writing before the rest of the build starts.

What separates a clinic build that works from one that fails?

Four things. First, the integration is proved before anything depends on it. Production access confirmed and a sandbox exchanging real data in the first two weeks, not the last two. Everything else in the project can be rescheduled; this cannot.

Second, reminders are paired with waitlist backfill. Reminders alone reduce the number of people who forget. Backfill converts the cancellations you now receive earlier into filled slots, and the combination is where the return lives, because a recovered appointment is a slot that was already paid for in staff time and clinician availability.

Third, the front desk was in the room during design. The people who will use this every hour know that the 4pm slot cannot be a new patient because of the car park, and that a specific clinician needs ten minutes between appointments. A system designed around the patient journey and not the desk gets worked around within a fortnight.

Fourth, you own the code, the data and the infrastructure accounts, and the agreements with every subprocessor are in your name. Patient data on infrastructure you cannot access is not a compliance posture you can defend to an auditor, and it is not one you should accept in a contract.