The question usually arrives the same way: a vet group has grown by acquisition to ten or twelve branches, each one bought with its own practice management system still running underneath, and someone on the management team finally asks why a client calling to move a 9am appointment to a 2pm still means a receptionist ringing round to see which vet at which site has a free slot. The honest answer is that nobody designed the scheduling for a group of twelve. Each branch's booking process was designed for a single-site practice, and it never got rebuilt when the business did.
That's the moment "should we just build our own booking system" gets asked out loud. It's a reasonable question, and it has a genuinely different answer depending on one fact most groups haven't actually checked: how many different systems are already running underneath those twelve branches, and whether a shared calendar is something the business needs or something that would just be nice to have.
What phone-booked scheduling actually costs across twelve branches
Picture a mid-size small-animal group: twelve branches, roughly 2,200 bookable slots a week across the group once you add up consults, vaccinations, nurse clinics and routine procedures — around 30 a day per branch over a six-day week. Every one of those slots gets booked, and a good many get moved, by a receptionist on the phone checking a diary that only covers their own site.
Three things happen as a direct result of that setup. First, a receptionist at Branch 4 has no way to see that Branch 7, fifteen minutes down the road, has three free slots this afternoon — so a client who can't be fitted in locally is told to try calling around themselves, which most won't bother doing, and the group loses a booking it actually had capacity for. Second, there's no shared waiting list, so when someone cancels, filling that gap depends entirely on whether that branch's receptionist happens to remember who asked about that day. Third, reminders are inconsistent — some branches call the day before, some send a text through whatever add-on they've bolted on, some do nothing — and the no-show rate tracks that inconsistency closely.
A 9% no-show rate is a realistic figure for a group without automated, branch-wide reminders — UK small-animal practices with proper SMS reminder systems typically run closer to 4-5%. On 2,200 weekly slots, 9% is 198 missed appointments a week. Without a shared cross-branch waiting list, maybe a third of those get filled same-day by whoever the receptionist happens to catch on a callback list; the rest — around 129 slots a week — simply go empty.
Illustrative figures for a twelve-branch group: 129 empty slots a week at a blended consult/nurse-clinic value of £36 is £4,644 a week in appointments that never happened — roughly £241,000 a year in capacity the group paid vets and nurses to be available for and never used.
Add the phone time itself. If each branch receptionist spends around 65 minutes a day purely on booking and rebooking calls — checking a diary, taking a callback, confirming a change — that's 6.5 hours a week per branch, 78 hours a week across twelve branches, roughly 4,050 hours a year. At a loaded reception cost of £14.50 an hour, that's about £59,000 a year in staff time spent on a task that a shared calendar would mostly remove.
Call it around £300,000 a year combined — empty chairs plus phone time — for a cost that has never appeared on an invoice because it isn't a purchase, it's just how the diary has always worked.
What the off-the-shelf options actually give you
Most UK practice management systems — RxWorks, Teleos, ezyVet and similar — sell a scheduling or online-booking module as a bolt-on, typically £180-£350 a month per branch depending on size and any multi-site discount. For a group where every branch already runs the same PMS, this is usually the right answer: implementation runs six to ten weeks, the vendor already understands multi-branch diaries, and the group gets a shared calendar, automated reminders and basic waitlist handling without writing a line of code.
The catch is the word "already". A group built through acquisition rarely has twelve branches on one system. It's far more common to inherit three — say five branches on one PMS, four on a second, three on a third, each kept because migrating a working branch off its existing system mid-acquisition is its own expensive, disruptive project. Bolt-on scheduling overlays are built to sit on top of one vendor's data model. Very few can read live availability from three different PMS APIs and reconcile it into one real shared calendar, and the ones that claim to usually mean a basic read-only feed, not two-way booking.
That's the fork in the road. A single-PMS group should buy the module and move on — building anything bespoke there is solving a problem the vendor has already solved more cheaply. A group split across three systems is choosing between two expensive options, and it's worth being honest that both of them are expensive before picking either.
What a custom build actually involves
A scheduling layer built specifically for a multi-PMS group doesn't replace any of the three underlying systems. It sits above them, reading availability from each one's API, writing bookings and cancellations back the same way, and presenting one shared calendar and one waiting list to every branch regardless of which system sits underneath. That's a materially smaller build than replacing the PMS estate, and it's the piece that's actually worth owning — much as our piece on buying software being a five-year decision argues for the joining layer generally, not the systems either side of it.
Realistic numbers for that scope: four to seven months with a competent development team, £70,000-£140,000 depending on how messy the three source APIs turn out to be, plus ongoing hosting and maintenance of roughly 15-20% of the build cost a year. The variable that moves the estimate most isn't the calendar UI — it's how well-documented and reliable each underlying PMS's API actually is, which almost nobody checks before scoping a project and almost always turns out to matter more than expected.
What a build doesn't remove is the underlying mess. If one of the three PMS instances has years of inconsistent client records or duplicate pet files, a scheduling layer built on top of it will faithfully reflect that mess back at every branch, just faster. That's the same trap described in our piece on why most integrations break: joining two systems together doesn't fix either one, it just moves the argument between them somewhere more visible.
The honest build-or-buy test
Three questions settle it for most groups, in order. Do all twelve branches already run one PMS? If yes, buy the vendor's module — building here is reinventing something that already works, and the saving in the earlier callout mostly comes from having any shared calendar at all, not from who built it. If no, does the business actually need branches to see each other's availability — for referral routing, specialist capacity, or genuinely shared waiting lists — or would branch-level reminders and a better local process close most of the gap without a shared calendar at all? A surprising number of groups discover the second option gets them 70% of the saving at a fraction of the cost and risk.
Only if the answer to both is "we genuinely need one calendar across systems that don't talk to each other" does a custom build clear the bar. At that point it isn't really a build-vs-buy question any more — nobody is selling what's needed, because what's needed is specific to which three systems this particular group happens to have inherited.
A reasonable first step
Before committing to either path, spend two to four weeks logging the real numbers rather than working from an estimate: no-show rate per branch, how many cancellations get refilled same-day versus go empty, and how much receptionist time is actually going on phone scheduling rather than everything else they do. Most groups have never measured any of the three, and the business case changes meaningfully depending on which branches are driving the cost — a group where two branches account for most of the empty slots has a very different, much cheaper problem than one where all twelve are equally affected.
Then check, branch by branch, which PMS is underneath and how good its API actually is — not what the vendor's sales page claims, but whether a developer can get a straight answer on live availability and two-way booking without a lengthy integration-partner negotiation. That single fact, more than anything else, determines whether this is a £25,000 module rollout or a £100,000 build, and it's knowable in a week rather than guessed at in a boardroom.
Common questions
We're on three different practice management systems after acquisitions — does that change the answer?
It's usually the single fact that decides the whole question. Bolt-on scheduling overlays are built to sit on one vendor's data model, so very few can read live availability from three different PMS APIs and write bookings back to all three cleanly — the ones that claim to usually mean a read-only feed rather than real two-way booking. Your realistic choices become consolidating onto one PMS first, which is its own six-to-twelve-month migration project, or building a thin layer that talks to all three APIs — a genuinely smaller, cheaper build than replacing the systems underneath it.
How long would a custom scheduling build actually take for twelve branches?
For a layer that sits above existing systems rather than replacing them, four to seven months with a competent development team is realistic, assuming each underlying PMS has a documented, reliable API to build against. The variable that moves this most isn't the calendar interface, which is well-understood, it's how messy or thin the source APIs turn out to be once a developer actually tries to read live availability from them — a check that takes a week and is worth doing before anyone quotes a firm date.
Isn't buying always safer than building for something like this?
Only when there's something to buy that actually does the job. If all twelve branches already run one practice management system, buying its bolt-on scheduling module is almost always the right call — cheaper, faster, and someone else's problem to maintain. The build case only exists for groups split across several inherited systems, where no off-the-shelf overlay genuinely reconciles three different diaries into one — at that point "buying" usually means paying a vendor to build a bespoke integration anyway, just without owning what comes out of it.
What's the one thing worth doing before committing either way?
Measure the real numbers for two to four weeks rather than estimating them: no-show rate per branch, how many cancelled slots get refilled same-day versus sit empty, and how many hours reception staff genuinely spend on phone scheduling. Most groups have never logged any of this, and the answer often concentrates in two or three branches rather than spreading evenly across twelve, which changes the business case from "we need a group-wide system" to something smaller, cheaper and far quicker to fix properly.