Five systems, one shared floor
Semble, Meddbase, Cliniko, Jane and Zanda are the systems private practices actually run, and they share the capability a private GP diary depends on. All five handle GP booking with appointment types for in-person, video and phone, and all five expose live availability that shows today's slots. That last part is the whole product for a private practice: somebody who could not wait is looking for a time this afternoon.
So the choice is not about capability. It is about which one fits the size of the practice, what reception touches every morning, and how the thing behaves embedded in a page on a phone.
Why there is no ranking here
Ranking practice software is a way of pretending every private practice is the same one. The system that suits a solo GP running remote consultations across two time zones is not the one that suits a four-partner family practice with its own phlebotomy room, and neither of them is helped by whichever tool won a feature count.
What follows is the set of questions that separate these five. Ask them on a trial with your own appointment types set up, before you commit and before a website is built around the answer.
Can a patient see a slot for today without hunting?
Availability existing and availability being visible are different things. Open the booking flow on a phone and see what the first screen offers: the next free slot, or an empty month view you have to page through. If the earliest bookable time today is three taps deep, the practice is still selling a wait.
Is video its own appointment type?
Check that a remote consultation is a real type with its own duration and its own fee, not an in-person slot with a note attached. Then book one on the trial and read the confirmation: the join link should arrive with it. If somebody has to send that link by hand afterwards, you have bought a diary, not a remote service.
Does a phone consultation behave differently again?
Phone, video and in-person are three products, and patients choose between them deliberately. Ask whether all three can exist at once, each with its own length, and whether you can close one for a day without touching the other two.
Can a patient book a named GP?
Where a practice has more than one doctor, patients arrive wanting a person. Test whether availability can be filtered to one GP, whether each GP can hold their own types and durations, and whether there is a direct link that books that doctor. That link is what a GP profile page needs to be worth building.
Can it take the fee at the point of booking?
Ask what the system does with money: whether the consultation fee can be charged or held when the slot is taken, which processor it uses, and what happens to that payment when a patient reschedules. The answer decides how much of your fee page is a promise and how much of it is a checkout.
What does the vendor sign about patient data?
A private GP practice handles the most sensitive information of any clinic type. Ask each vendor which data-processing agreement they offer for the country you practise in, and get it in writing before launch rather than after. Then keep the website out of it: forms and booking run inside the tool that has the agreement, and the site itself stores nothing.
Then test what the embed does to the page
Put the booking widget on a real phone, on mobile data, and watch the page while it arrives — whether the layout jumps, whether the calendar sizes itself to the screen, whether it works under a thumb. Load it on the page where someone books and nowhere else: a script running across the whole site slows the fee and explainer pages, and on a private GP site those pages are what earn the booking.
Where this sits
Every private GP practice website we build embeds whichever of these five you already pay for, wired to your diary, at a fixed price. For the Semble-specific version, read embedding Semble on a private GP site. To check what your current site does with a booking, run the six phone tests.