A single practitioner working from one room has one constraint: are they free. Add a second room, a second site and six staff, and availability becomes a question with several answers that all have to be yes at once.
The failure this produces is specific and familiar. A client books an appointment with the right person at a time that person was genuinely free, arrives, and there is nowhere to see them. Nothing in the booking system was wrong. The system was only tracking one of the two things that had to be true.
This article covers treating rooms and equipment as bookable resources, the double-constraint problem, per-location hours and holidays, timezone differences between sites, and how permissions should be arranged so a branch manager sees their site and head office sees everything.
Everything Scarce Is A Resource
The useful mental shift is to stop thinking of a booking as "time with a person" and start thinking of it as a claim on a set of scarce things. A person is one of those things. So is a treatment room, a dental chair, a piece of diagnostic equipment, a company vehicle, a meeting room with a screen in it.
Any of those can be the binding constraint. Three categories worth modelling separately:
- Staff. Have skills, working hours, personal calendars and leave. Usually the resource people think of first.
- Spaces. Rooms, chairs, bays. Have opening hours tied to a site, need turnaround time between uses, and cannot be in two places.
- Equipment. Portable, which is what makes it awkward. A machine can move between rooms and sometimes between sites, so its availability is not tied to one location the way a room is.
If a service cannot be delivered without a particular thing, that thing belongs in the availability calculation. The common shortcut, tracking only staff and assuming rooms will work out, holds until utilisation gets high, and then fails on exactly the busy days when it hurts most.
The Double Constraint Problem
A bookable slot for a room-based service requires two independent conditions:
- A staff member with the right skill is free.
- A suitable room at that location is free.
The available times are the intersection, not either one alone. Two consequences follow that are worth stating plainly.
Availability is scarcer than any single view suggests. Look at the staff rota and you see plenty of time. Look at the room diary and you see plenty of time. The overlap can still be thin, because the free periods do not line up. Anyone judging capacity from one view will overestimate it.
Adding staff without adding rooms adds nothing. This is the most expensive version of the mistake. A practice hires a fifth practitioner while running four rooms, and utilisation per person drops instead of throughput rising. If rooms are the binding constraint, the only fixes are more rooms, longer opening hours or shorter turnaround.
Working out which constraint binds is straightforward: over a busy week, count the hours each room was occupied and the hours each staff member was in appointments, both as a percentage of the hours available. Whichever runs closer to full is your constraint, and that number is the one worth tracking month to month.
Assignment Order Matters
When both a person and a room have to be chosen, the order changes the outcome. Two workable approaches:
- Person first, then any suitable room. Right when clients book a named practitioner and rooms are interchangeable. Simple and matches how most clients think.
- Room first, then any qualified person. Right when the room is specialised and staff are interchangeable, for example a room with equipment only some services need.
The pattern to avoid is assigning greedily without looking ahead: giving a short appointment the only large room and then having nowhere to put the appointment that genuinely needed it. Where rooms differ meaningfully, restrict services to the rooms that can host them rather than letting anything land anywhere.
Per Location Hours And Holidays
Sites do not keep the same hours. A branch may open late on Thursdays, close Saturdays, or shut entirely for a local holiday that the other sites work through. Modelling opening hours once for the business and applying it everywhere produces bookings at closed sites, which is a wasted journey for the client and an apology for you.
Three layers need to exist, and they need a clear order of precedence:
- Location hours. When the site is open at all. The outer boundary, and nothing should be bookable outside it.
- Resource hours. When a specific room or machine is usable, which may be narrower than the site, for example a room used for something else on Wednesday mornings.
- Staff hours. When the person will take bookings, which may span sites: Monday and Tuesday at one branch, Wednesday at another.
The bookable time is the intersection of all three. Closures need to work the same way: a site-level closure removes everything at that site, while a staff member's leave removes only them. The rules governing the underlying windows are covered in setting your availability rules.
One detail worth getting right early: staff who work across sites need travel time between them, and a normal buffer cannot express "forty minutes only when the previous appointment was at the other branch". The practical answer is usually to block the transition in the rota rather than to rely on padding, and the trade-offs of padding in general are in buffer times between appointments.
Timezones Between Locations
As soon as sites sit in different timezones, "9:00" stops being a single fact. Three rules keep it manageable:
- Store instants, display local. Appointments should be stored as an absolute point in time and rendered in whatever zone the viewer needs. A booking is one moment, viewed from several places.
- Opening hours belong to the location. A branch opens at 09:00 in its own zone, always. Hours are local facts and should never be stored in a head-office timezone with an offset applied.
- Say the timezone out loud. Every confirmation, reminder and staff view should name the zone. "14:00" alone is the most common cause of a missed cross-site appointment.
Daylight saving is where this gets genuinely hard, because different regions change on different dates, so the gap between two sites is not constant. For a couple of weeks each year, a call that is normally a two hour difference is a one hour difference. The detail is in timezone handling in scheduling.
Collisions Get More Likely, Not Less
Every extra resource is another thing that can be double-booked, and multi-site operations have more routes for a booking to arrive: the public page, a branch phoning it in, head office adding it, a staff member blocking their own calendar. Each route has to respect the same constraints.
The three checks worth making explicitly:
- Can a staff member be booked at two locations at overlapping times? It should be impossible, and it frequently is not when each site keeps its own diary.
- Does a manual booking made by staff check room availability, or only the person? Manual entry is the usual bypass.
- Does a personal calendar block at one site remove the person from availability at all sites? It has to.
The mechanics of stopping these are covered in double booking prevention. The multi-site addition is that a collision may not be visible from either site's own diary, so somebody needs a view across all of them.
Permissions: Who Should See What
Permissions in a multi-site operation are an operational tool, not only a security one. Scoping a manager to their own site removes noise and prevents accidents in diaries they do not run.
A structure that works for most multi-site businesses:
| Role | Sees | Can Change | Cannot |
|---|---|---|---|
| Staff member | Own schedule, own bookings | Own availability, own leave requests | See or edit colleagues' client details |
| Front desk | All bookings at their location | Book, move, cancel at that location | Change services, prices or rotas |
| Location manager | Everything at their location | Rotas, opening hours, rooms, local closures | Touch other locations or global settings |
| Regional or head office | All locations | Services, prices, global policy, cross-site reporting | Nothing, this is the top scope |
Two refinements worth making. First, reporting scope and editing scope are different: a location manager often needs to see how their site compares against the group without being able to change anything outside it. Second, staff who work at several sites need their scope to follow them, which is a reason to scope permissions by assignment rather than by a single home branch.
A Practical Setup Order
- Define locations first, with real opening hours and local closures.
- Add rooms and equipment as resources under the correct location, with turnaround where it applies.
- Add staff, and assign them to locations with the days they are at each.
- Map services to the resources they require, so nothing can be booked without what it needs.
- Set permission scopes by location before you give anyone access.
- Test the awkward case deliberately: book a service needing a specialist room at a branch on a day the room is unavailable, and confirm no slot is offered.
Step six is the one people skip. Multi-site scheduling problems are almost never visible in the happy path, and the first real test should not be a client's wasted journey.
How You Would Automate This
appntmnts.io supports multiple team members, per-location hours and pooled team scheduling, with two-way calendar sync to Google, Microsoft 365 and CalDAV so a staff member working across sites carries one honest availability picture rather than one diary per branch. Bookings, reminders and rescheduling all run against the same underlying constraints, which is what stops each site drifting into its own version of the truth.
If you are mapping out how sites, staff and rooms should be arranged, the features overview covers team scheduling and availability rules, and the pricing page sets out what team and enterprise scale look like, including SSO and provisioning for larger operations.