A multi-site clinic group that grew faster than its calendar did
Eleven sites, one scheduling model, and a conflict count that stayed at zero
A clinic group had grown to eleven sites by acquiring practices that each arrived with their own calendar. Appointments, clinicians and rooms were booked in three different places, and the group had no way to answer a question as simple as whether a given room was free on Thursday. The fix was not a bigger calendar. It was modelling the resource — the room, the chair, the clinician — as the thing that gets booked, and letting the appointment be a consequence of that.
The Client
A multi-site clinic group that grew faster than its calendar did
Anonymised · NDA- Healthcare · 11 sites
- Egypt · Saudi Arabia
Each acquired practice kept the booking system it came with, and head office reconciled them by phone. That worked at four sites. At eleven it produced a standing backlog of double-bookings that front desks absorbed by arriving early, and nobody could say how often it happened because nothing recorded it.
Diagnosis
What was broken
- [01]
Three systems each believed they owned the calendar, and none of them could see the other two.
- [02]
A room was booked as free text, so two clinics could reserve the same room without any collision.
- [03]
Clinician availability lived in a shared spreadsheet that was edited by six people at once.
- [04]
Double-bookings were resolved at the front desk and never recorded, so the rate was unknown.
- [05]
Equipment that only two sites owned was booked informally, by asking whoever used it last.
- [06]
Moving a patient between sites meant cancelling and rebooking, which lost the original history.
Business Impact
The visible cost was twenty minutes a day per front desk on the phone to another site. The real cost was that the group could not open a twelfth site without hiring a coordinator for it, because coordination was a person rather than a system.
Why previous attempts failed
Two previous attempts bought a better calendar. A calendar stores appointments, and the thing that was actually scarce was the room and the clinician, which no calendar modelled.
Our Approach
How we solved it
Phase 01 of 04 · Count the collisions first
01
Count the collisions first
Before proposing anything we exported four weeks from all three systems and cross-matched them. That produced the first real number the group had ever had for double-bookings, and it was roughly four times what management had assumed. Everything after this was argued against that number.
Deliverables
- Four-week collision audit across all sites
- A baseline rate management agreed to
- The twelve resource types actually booked
02
Model the resource, not the slot
Rooms, chairs, clinicians and the two shared imaging units became first-class records with their own availability. An appointment then became a claim on one or more of them, and the database — not a person — refused the second claim. This is the whole of why the conflict count went to zero.
Deliverables
- Resource schema with per-entity ownership
- Exclusion constraint on overlapping claims
- Cross-site transfer that keeps the history
03
Migrate one site at a time
We moved the smallest site first and ran it in parallel with its old calendar for three weeks, comparing both every morning. Nine of the remaining ten followed at one per week. The eleventh was left until last because it owned both imaging units and needed the others live first.
Deliverables
- Parallel-run comparison for every site
- Per-site cutover with a rollback path
- Front-desk training in Arabic and English
04
Hand over the operation
The group now adds a site themselves. Resource types, opening hours and clinician rotas are configuration rather than code, the deployment pipeline is in their GitHub organisation, and the on-call rota is theirs. We were out of the critical path two months after the last cutover.
Deliverables
- Site onboarding they run without us
- Runbooks and an on-call rota
- Cloud and repository accounts in their name
End of approach
Scroll on for the results →
Scroll · 4 phases · pinned
Tech Stack
Tools & technologies
PostgreSQL · btree_gist
Constraints
TypeScript · Node
Language
Next.js App Router
Interface
Terraform · Actions
Infrastructure
Results
Quantified outcomes
11
Sites on one model
Migrated one per week, smallest first, each run in parallel for three weeks
0
Double-booking conflicts
Not a report but a constraint: overlapping claims are rejected at write time
−20 min
Front-desk calls daily
Measured per desk across a full quarter after the last site went live
Same day
Cross-site transfer
The appointment history follows the patient instead of being cancelled
Key Takeaways
What we learned
01
Book the scarce thing, not the appointment
An appointment is an outcome. What is actually scarce is the room, the chair and the clinician. Model those as the bookable records and the conflict becomes a database constraint instead of a conversation at the front desk.
Useful when: Any booking system where two bookings can quietly claim one physical thing.
02
Measure the defect before you price the fix
Management estimated the double-booking rate at a quarter of what it was. The four-week audit cost a few days and changed both the budget and the sequencing, because the real number made the imaging units the last migration rather than the first.
Useful when: Before any project justified by a rate nobody has actually counted.
03
A parallel run buys trust, not correctness
Three weeks of running both calendars found almost no defects. What it did was let eleven front desks watch the new system agree with the old one every morning, which is why the tenth cutover needed no training at all.
Useful when: Replacing a system whose users have been burned by a previous rollout.
04
Configuration is what makes handover real
The twelfth site opened without us. That was only possible because resource types, hours and rotas were data the group could edit, not code we would have had to deploy. The handover was decided months earlier, in the schema.
Useful when: Any engagement that is meant to end rather than become a retainer.
FAQ
Frequently asked
01Why not just buy a scheduling product off the shelf?
02How was the zero-conflict figure actually verified?
03What happened to the appointments already in the old systems?
04Does the group still need us in order to open a twelfth site?
05Why is this case study anonymised rather than named?
The closing thought
Ready to write yours?
Every project on this site started as an operational problem somebody had stopped expecting to fix. If one of yours sounds like this, that is the conversation to have.
Let's write yours.
Book a call- 11 Sites live on one model
- 0 Booking conflicts since launch
- SiaSol · siasol.ai
Software products built in Egypt, Saudi Arabia and the UAE.