With a single location, a well-kept diary at reception copes. With two or three, you get separate calendars, specialists who work on different days at different sites, and people who phone the wrong branch. An online booking system puts all the diaries into one system, where customers choose the location, service, specialist and time themselves.
The hard part is the rules: how long each service takes, who can perform it, in which treatment room or on which vehicle lift, how much notice is needed to cancel. They differ between a clinic, a salon and a garage, and they are also what decides whether you need something custom-built.
A calendar by location, by specialist and by resource
A slot can be offered only if three things line up: the location is open, the specialist is working there that day, and the resource needed (the treatment room, the chair, the vehicle lift, the machine) is not in use. We model the opening hours of the locations, each person’s schedule across locations and the list of resources separately; availability is where they intersect.
Say a doctor sees patients in one part of town on Mondays and in another on Thursdays. The patient sees only the real slots, with the right address next to each. On top of the calendar sit the rules, which you change yourself from the admin panel.
- Duration: each service has its own duration, which can differ from one specialist to another.
- Buffer time: minutes kept between appointments for cleaning, preparation or moving the car.
- Booking window: how late a booking can still be made and how far ahead the calendar is open.
- Cancellation: up to what point the customer can cancel or reschedule on their own.
- Exceptions: leave, public holidays, slots kept for emergencies only.
Reminders, waiting list, advance payment
Reminders go out automatically, at the intervals you choose, by email and by SMS (the latter sent through a specialist provider that charges for each message). They contain a link to confirm or cancel, so that a freed slot goes straight back into the calendar.
The waiting list makes use of exactly those slots: anyone who could not find a time signs up for a day or a specialist and is notified when a slot comes up. Advance payment is optional and goes through a payment processor; you can require it for certain services only. You check the refund rules with your lawyer; the application simply applies them.
For clinics, the reminder does not mention the medical service. What data you collect and how long you keep it is something you settle with your data protection officer.
Syncing with staff calendars, and the rest of the technology
We connect the platform to Google Calendar or to Microsoft’s calendar through their official programming interfaces: with the consent of the specialist, who links their own account, appointments appear in their personal calendar, and a private event entered there blocks the slot in the platform too. We settle at the outset which side has the final say.
We usually build on Laravel (a PHP framework, that is, a set of ready-tested components) and on PostgreSQL or MySQL. The delicate part is simultaneous booking: if two people click the same slot in the same second, the database must accept only one of them, which is handled through transactions and constraints, not through checks made only on screen.
How reception’s rules find their way into the application
The real rules live in the heads of the people at reception: “the doctor doesn’t take new patients in the afternoon”, “we don’t start a colour late in the day”. We bring them to the surface before drawing a single screen.
The switch is made in stages. The phone line stays open, but reception logs phone bookings in the same system, so that you do not end up with two diaries.
- Inventory: services, durations, specialists, resources and each location’s opening hours.
- Sketches: the customer journey and the reception screen, discussed on mock-ups.
- Development in slices: first the calendar and the rules, then the messages, the waiting list, payment.
- Trial: a single location uses the system alongside the old diary.
- Roll-out: the other locations join one at a time, with training for reception.
A custom online booking system or a subscription service?
For a single location, with fixed-length services and no shared resources, an existing booking service paid for monthly is usually the better choice: it is quick to set up and often comes with ready-made mobile apps.
Building your own starts to make sense when several of the situations below come together.
- Your rules combine locations, people and resources in a way that standard services do not allow.
- You need a link to your practice or business management software, the patient record or the garage’s repair estimate.
- The subscription, charged per user or per location, is growing faster than the business.
Frequently asked questions
Do customers have to create an account to book?
Not necessarily. A name, phone number and email address, confirmed with a code, are usually enough; an account becomes useful for those who come back often. The less data you ask for at the first booking, the fewer people give up along the way.
What does the development time depend on?
On the number of rules and exceptions, on the integrations required (calendars, SMS, payments, management software) and on how quickly we receive the list of services, durations and schedules. After the initial inventory we tell you which stages the work divides into.
How can I tell the platform is doing its job?
You track how many bookings come in online rather than by phone, how often no-shows occur and how full the calendars are at each location. The platform shows these in reports, but it cannot improve them by itself: prices and staff matter too.
This is a typical project description: it shows how we usually approach this kind of work and does not present a project carried out for a particular client. Every real project starts from your company’s situation, and the stages, timescales and price are agreed after the initial discussion.