Booking flow for a multi-room clinic
A concept study in reducing a five-screen booking journey to two, without losing the availability rules a real clinic needs.
This is a self-initiated concept piece, not client work. No client names, results or metrics are claimed anywhere on this page.
The premise
Self-initiated study, not client work. Multi-room, multi-practitioner businesses — clinics, studios, garages — have genuinely hard availability rules, and most booking widgets solve them by asking the customer to do the work.
The problem
A typical journey runs: choose service → choose practitioner → choose date → choose time → enter details. Five screens, and the customer is asked to understand your internal structure before they can book anything.
Worse, most implementations let you reach step four before discovering nothing is available that week.
The approach
Ask for what the customer knows. They know roughly when they want to come and what they need. They do not know or care which room it uses.
Solve the constraints server-side. Room, practitioner and equipment availability are intersected before anything renders, so every slot shown is genuinely bookable.
Two screens. When and what, then who you are.
What it demonstrates
- Constraint solving across three resource types
- Optimistic UI with real conflict handling on submit
- Timezone and daylight-saving correctness
- Accessible date and time selection that works on a keyboard
Honest limitations
It has not run against a real clinic's calendar, and real businesses always have exceptions a concept does not anticipate. Treat it as a demonstration of approach, not a finished product.
Let us look at what you have.
Send us your current site and what you want it to do. We will tell you what is worth fixing and what is worth rebuilding — before anyone talks about money.