How to scope a booking system for an appointment-led business

A booking system looks like a simple purchase: a diary, some services, a button that says "book". The reason so many of them disappoint is that the business was scoped as "appointments" when the real work is in the rules around the appointment: who can do what, in which room, with what equipment, how far ahead, with what deposit, and what happens when the customer does not turn up. Those rules differ between a hair salon, a dental practice and a physiotherapy clinic, and they differ again between two salons on the same street. The purpose of scoping is to write them down before anyone builds anything.

Start with the diary you have, not the one you want

Before you list features, describe a normal week. Who takes bookings and from where: the front desk, the telephone, a social media inbox, a web form, a walk-in? Who is allowed to move an appointment, and does anyone have to be told when it moves? Which bookings need something other than a person to be free: a treatment room, a chair with a basin, a surgery with a particular machine, a hydrotherapy slot? Which services are fixed-length and which depend on the client, the clinician or the condition?

Write this down as a plain description, not as a wish list. Most of the cost of a booking system is driven by the number of distinct rules it has to enforce, so an honest account of the current diary is the single most useful document you can hand to a developer. It also exposes rules that live in one person's head and nowhere else, which is the main reason a new system "does not work" in its first month.

The seven questions that shape the scope

1. What is being booked: a person, a resource, or both?

A salon usually books a stylist, and the chair follows. A dental practice books a clinician, a nurse and a surgery together, and the appointment is only possible when all three are free. A physiotherapy clinic may book a clinician and a room, and some treatments need equipment that only exists in one room. The more things that have to line up, the more the availability engine has to do, and the more careful the scope needs to be about what happens when one of them changes.

2. How is the duration decided?

Fixed durations are the easy case. Durations that depend on the service combination (a colour followed by a cut with processing time between), on the client (a first consultation is longer than a follow-up), or on the practitioner (a senior clinician runs a shorter list) each need a rule. Processing and recovery gaps, cleaning time between patients and buffer time around complex treatments are all part of the same question. If you cannot describe the rule, the system cannot apply it.

3. Who sets availability, and how far ahead?

Rotas, holidays, part-time patterns, locums and self-employed chair renters all affect what can be booked. Decide whether staff manage their own hours, whether a manager approves changes, and how far ahead the public can book. Clinics with recall cycles (six-month check-ups, review appointments after a course of treatment) also need the system to create future bookings from a schedule, not only from a customer clicking a button.

4. What does the customer have to commit?

Deposits, card details held against a cancellation policy, pre-payment for first appointments, and simple free booking are four different checkout flows. Each has a refund and no-show policy behind it that the system must apply consistently. Scoping this early matters because it decides whether a payment provider is part of the build and which parts of the booking flow have to be transactional.

5. What happens around the appointment?

Reminders by text or email, intake forms and medical histories completed in advance, consent to be recorded before a treatment, aftercare instructions sent afterwards, and a prompt to rebook. These are small individually and together they are most of what the customer notices. List them with the trigger for each: when it is sent, to whom, and what stops it being sent.

6. Where does the data need to go?

Card payments, accounting, a clinical records system, a stock system for retail products, a marketing list with its own consent rules. Each integration is a scoped item with a direction (read, write or both) and a failure mode (what happens when the other system is down). An integration described as "it should just sync" is an integration that has not been scoped.

7. Who needs to see what?

Reception sees everything for today. A stylist sees their own column. A clinician sees clinical notes that reception must not. An owner sees utilisation across sites. Roles decide the screens that have to be designed, and clinical data decides the security scope that has to be written as named controls rather than assumed.

How the questions land differently by sector

The same questions produce different answers, and the answers are where the scope lives. The table below is a summary of what we most often hear in discovery for three appointment-led sectors; your business will differ, and the point of discovery is to find out where.

Package or custom build?

If your answers fit a common pattern, a package built for your sector covers most of the scope with configuration rather than development, and the remaining items become named add-ons or custom work. If the answers include rules nobody else has, a custom build around the rules is the honest option, and the scope document says which parts are standard and which are yours. The sector packages on this site each list what is in the base scope, what is an add-on and what is custom, so you can compare your answers against them before you ask for a proposal.

• Hair salon booking package and the custom salon systems service
• Dental clinic package and the custom dental practice software service
• Physiotherapy centre package and the custom physiotherapy systems service

What to ask a developer

Whoever you are talking to, these questions separate a supplier who has scoped your kind of business from one who is selling a generic diary.

1. Show me how the availability rule for a two-stage service works, and what the customer sees when the second stage has no slot.
2. What happens to a booking when the staff member's rota changes after it was made, and who is told?
3. How is a deposit held, refunded and reported, and what does the system do if the payment provider is unavailable at the moment of booking?
4. Where is clinical or sensitive data stored, who can see it, and how is access logged?
5. Which of my current systems does this connect to, in which direction, and what is the behaviour when the connection fails?
6. Who owns the source code and the data at the end, and what does it take to move hosting?
7. What is in the base scope, what is an add-on, and what in my description is custom?

What moves the price

We do not publish figures, because no two scopes are the same, but the factors are predictable. The number of distinct booking rules is the first. The number of resources that have to coincide is the second. Payment flows (none, deposit, held card, pre-payment) each add a transactional path. Each integration adds a connector and its failure handling. Multiple sites or brands multiply the configuration. Sensitive data adds a security scope. Migration of an existing diary, client list and future bookings is its own item with its own testing. Finally, the number of roles and screens decides the design effort. Give a developer honest answers to the seven questions and the proposal you get back will be priced on those factors rather than on a guess.

A worked example, labelled

Before you ask for a proposal

Write the plain description of your week. Answer the seven questions, including the ones you are unsure about. Decide who in your business owns the rules, because they will be the person a developer needs during discovery. Then compare your answers to the package for your sector, and start a quote with the description attached. A scope built this way is one you can hold the supplier to, and one that will still describe your business after launch.