Running Clinics Across Multiple Sites Without the Rota Falling Apart

The moment a practice becomes hard to run

A single clinician at a single site is a solved problem — a diary works. The difficulty arrives with the second site, or the second clinician working across sites, and it arrives suddenly. Availability is now a function of who is where, on which day, doing which kind of appointment. Held in someone's head or a shared spreadsheet, that arrangement fails in four recognisable ways.

Failure 1: the same clinician booked in two places

The classic multi-site failure. A clinician's Tuesday afternoon is offered at both sites because each site maintains its own view of their availability. Nobody notices until a patient is sitting in the wrong waiting room.

The fix is structural, not procedural: a clinician's time must be a single resource that sites draw from, rather than each site holding its own copy. If site A booking a clinician does not immediately make that time unavailable at site B, you will double-book eventually, and no amount of care will prevent it.

Failure 2: the patient goes to the wrong site

If your practice has more than one address, some patients will attend the wrong one. It is not carelessness — it is that "your appointment with Dr X" says nothing about location, and patients who have been to one site assume the next appointment is there too.

Put the full address and the site name in the confirmation, in every reminder, and on anything the patient is likely to look at on the day. Where the sites are close together or similarly named, say explicitly which one — "the Queen Street site, not the High Street site". Practices that do this see the problem largely disappear.

Failure 3: published availability is already wrong

Every manual step between "the clinician's actual availability changed" and "the booking page reflects it" is a chance to publish something untrue. Someone adds leave to a rota but does not close the slots; a clinic is cancelled but the page still offers it. Patients book, and someone has to ring them back and apologise.

Availability should be derived from the rota rather than maintained alongside it. If a clinician's leave, working pattern and site allocation live in one place and the booking page reads from that, the page cannot drift. If they live in two places, it will.

Failure 4: nobody knows who can change what

As a practice grows, more people touch the rota — practice manager, reception at each site, clinicians themselves. Without explicit permissions you get either paralysis, where nobody dares change anything, or chaos, where a receptionist at one site alters a clinician's pattern at another.

Decide deliberately: who can add and remove clinics, who can book into someone else's diary, who can change a clinician's working pattern, and who can override a block. Then set it up that way rather than relying on convention.

What good looks like in practice

• One rota, many views. A clinician sees their own week across all sites; a site manager sees everyone at that site; the practice manager sees everything.
• Availability derived from the rota, not maintained separately.
• Site as a first-class property of every appointment, appearing everywhere the patient sees it.
• Explicit permissions per role.
• Changes visible to the people affected, so a clinician learns their clinic moved from the system rather than from a patient.
• Per-site reporting. Utilisation, non-attendance and revenue vary by site, sometimes dramatically. Aggregate figures hide the site that is struggling.

Before you add a site

Two questions worth answering honestly. First: is existing capacity actually full, or is it merely inconveniently distributed? A second site solves the first problem and makes the second worse. Second: which clinicians will genuinely work across sites? Travel time between them is unbookable time somebody is paying for, and it is routinely left out of the plan.

How Roshtah fits

Roshtah models sites and clinicians separately: a clinician's availability is defined per site, appointments carry their site through confirmations and reminders, permissions are set per role, and reporting can be viewed per site or across the group — so the rota stays the single source of what is bookable.