Case 01of 08
Meridian Booking, rebuilt around the next free slot
A twelve-clinic physiotherapy group was taking 38% of its bookings by phone and losing nearly a quarter of them to no-shows. We replaced a third-party calendar widget with a booking flow built around one question: when can I actually be seen?
The booking screen — next available first, calendar secondFig. 01
The problem
Meridian had a website, a phone line and a third-party booking widget that none of the three shared a database with. Reception kept a paper day-sheet as the real source of truth because the widget could not be trusted.
We spent the discovery week in the Northgate and Ashfield clinics with a stopwatch, timing forty bookings end to end. The median online booking took 4 minutes 12 seconds and required choosing a clinic, a practitioner and a date before the system would admit whether anything was free. Eleven of the forty gave up.
- 38% of bookings came by phone, at 3m 40s of staff time each
- 22% no-show rate, concentrated in first appointments
- Reception re-keyed every online booking into the practice system by hand
- No clinic could see another clinic’s availability
- 11 of 40 observed online bookings were abandoned before payment
Before and after
The first screenMedian time to complete a booking after launch, down from four minutes and twelve seconds. Measured the same way, in the same two clinics, with the same stopwatch.
The decision
Almost nobody arrives wanting a specific practitioner on a specific Thursday. They want to be seen soon, near where they are. So we inverted the flow: the first screen answers when and where, and the calendar grid became a fallback for the minority who need it — 14% of bookings, as it turned out.
The harder decision was the deposit. A refundable £15 hold at booking was the single biggest lever on no-shows and the single most contentious thing we proposed. Two clinic managers threatened to opt out. We shipped it as a six-week A/B across four clinics rather than winning the argument in a meeting.
- Next-available surfaced across all twelve sites, ranked by distance
- Three taps for a returning patient, five for a new one
- Refundable deposit, released automatically on arrival
- Two-way sync with the existing practice management system
- SMS confirmation and a single reminder at T−24h
The booking flow
Five screens became threeMeasured over six weeks against the same weeks of the prior year to control for seasonality. The four A/B clinics were chosen by the client, not by us. The eight remaining sites adopted the deposit after the trial and show the first eight weeks.
The system
Twelve clinics meant twelve sets of opinions about wording, hours and services. Rather than build twelve variants we built one design system — 34 components, tokens for the two sub-brands — and gave clinic managers a small set of levers they could pull without us.
It was handed over with a documentation site, a Figma library that matches the code one-to-one, and a recorded walkthrough. Their in-house developer shipped the next two features — group classes and a waiting list — without our involvement.
- 34 components, documented, with light and dark tokens
- Practitioner-facing schedule app on the same system
- WCAG 2.2 AA, tested with keyboard and VoiceOver before launch
- Repository, pipeline and hosting in the client’s own accounts
- Two features shipped by their developer in the first quarter after handover
The design system
34 components, handed overResults
Each with its methodThe deposit was the thing I fought hardest against and it turned out to be the thing that fixed our week. They ran it as an experiment instead of winning the argument.
LogWeek by week
The build log
Ten weeks, demoed every Friday on a staging URL the client could open on their own phones.
Paid discovery. Two days in clinics with a stopwatch, forty bookings timed, practice-management API documented. Scope and fixed price written and signed.
Booking flow designed in the browser. Three directions for the first screen, reviewed on reception’s own devices. Next-available chosen on day nine.
Two-way sync with the practice system built first, because it was the riskiest part. Reconciliation log designed for reception before the UI was finished.
Deposit A/B shipped to four clinics. Stripe holds, automatic release, and a manual override for reception. Measurement agreed with the client in writing first.
Design system extracted from what had been built, not invented ahead of it. Practitioner schedule app assembled from it in four days.
Accessibility pass: keyboard, VoiceOver, dynamic type. Nine defects found, seven fixed before launch, two deferred with the client’s agreement.
Phased launch, two clinics a day. Handover: source, docs site, Figma library and a recorded walkthrough for their developer.
Thirty days of fixes. Deposit rolled out to the remaining eight clinics on the client’s decision, not ours.
What shipped
Six deliverablesWhat we would do differently
We over-built the reporting. The first version shipped with fourteen charts because every clinic manager asked for a different one; six months on, three are used. We should have shipped two and added the rest on evidence. The deposit A/B was the right call and we would run it earlier — waiting until week five cost us three weeks of arguing that the data settled in six.
Who did it
CreditsProduct design, front end, design system, accessibility. One person, nine weeks.
Back-end and practice-system integration — a developer we have worked with since 2019, introduced to the client in week one.
Operations director as decision-maker, two clinic managers as reviewers, one in-house developer who took handover.
Two build slots openNext start: March