Direct answer: Multi-site healthcare call automation fails when groups copy a single-clinic script onto several locations. Success depends on number architecture, location detection, global versus site rules, staff permissions, escalation ownership and a phased rollout—not on claiming the AI can silently fill empty chairs across the network.
This guide is for operations leaders running several clinics. It is materially different from single-site AI receptionist content. Dental networks should also read the DSO guide. Mixed pathway rules belong in NHS/private clinic automation and the enterprise mixed matrix.
The multi-site problem
Adding sites multiplies phone complexity even when branding is shared:
| Pressure | What breaks if ignored |
|---|---|
| Inconsistent opening hours | Callers hear the wrong “open/closed” behaviour |
| Location-specific services | Site A books a treatment Site B does not offer |
| Pooled vs local demand | Marketing drives a central queue with no site default |
| Routing | Local numbers, central number and overflow collide |
| Shared staff | Central admins need all-site visibility; local staff must not |
| Local booking rules | Clinicians, deposits, NHS/private status differ by site |
Hypothetical (not a customer case): Site North is fully booked for new assessments on Monday mornings; Site South has gaps three miles away. Without explicit cross-site offer rules, automation that only knows “the caller’s local diary” will either fail the book or invent a transfer. With rules, it can ask whether the caller will travel—and stop if they will not.
Architecture and workflow (Clero-supported patterns)
Clero’s multi-location model centres on organisation locations, optional per-location settings (including hours inheritance), agents assignable to a location or all locations, location-scoped memberships, and booking tools that require a clinic/location identifier chosen from configured options. Dashboard metrics and calls can be filtered by location.
Describe configurations you can actually run—not marketing “network brain” diagrams.
1. Local numbers (site-default)
- Patient dials Site A’s published number.
- Telephony delivers the call into the AI path configured for that line.
- The assistant defaults to Site A’s location identity, hours and bookable types.
- If Site A cannot fulfil the request, follow configured fallback: message, transfer, or offer another site only if allowed.
Fits: strong local brand, different services per site, patients who expect “their” clinic.
2. Central number (group front door)
- Patient dials the group number.
- The assistant asks for preferred location (or applies a documented rule such as postcode guidance—only if you have approved that script).
- It sets the clinic/location identifier for availability and booking.
- It applies that site’s hours and appointment rules before offering slots.
Fits: pooled marketing, one contact centre brand, shared overflow.
3. Hybrid (common in practice)
Keep local numbers for familiarity and use a central or overflow path for peaks and after-hours. Document which path owns which hours.
Cross-site availability and fallback
| Behaviour | Supported framing | Do not claim |
|---|---|---|
| Check availability for the selected site | Yes, when that site’s system/routing is connected | Instant visibility of every chair with no configuration |
| Offer another site | Only when group policy and scripts allow a second choice | Silent auto-reroute to maximise utilisation |
| Clinician pick inside one PMS location | Some connectors balance among providers at that location | The same mechanism as cross-site load balancing |
| Fallback | Transfer, callback task, or next-day message | Guaranteed 0% abandonment across the group |
Booking write-back still depends on a supported connector for that diary. See automated appointment booking and PMS integration. Clero’s verified booking handlers today include Dentally, CareStack, Semble, Aerona and Exact (via Exact Online Booking when enabled), plus calendar-style connectors where configured—not every PMS a group may run.
Global rules versus site-level rules
Write this matrix before go-live. Mark each row Global, Site, or Inherit with override.
| Rule area | Typical global standard | Typical site override | Why it matters |
|---|---|---|---|
| Hours | Brand after-hours message style | Local open/close and holidays | Wrong hours destroy trust |
| Services | Shared FAQ tone | What that site actually offers | Prevents impossible bookings |
| Clinicians / rooms | Naming conventions | Local diaries and constraints | Avoids cross-site collisions |
| Appointment types | Naming and duration standards | Which types are bookable by phone | Stops diary clutter |
| Deposits | Prefer payment links over spoken card data | Amounts and which types need deposit | Finance differs by site |
| NHS / private status | Pathway language standards | Which types are NHS vs private locally | Mixed groups need explicit separation |
| Escalation contacts | Severity definitions (111/999 scripts) | Desk, mobile or central team per site | Unanswered transfer needs an owner |
| Language / voice | Brand voice guidelines | Optional local accent or bilingual scripts if configured | Consistency vs local preference |
In Clero, organisations can maintain organisation-level defaults and per-location overrides (for example business hours with a “use organisation defaults” pattern). Agents can be tied to one location or left organisation-wide. Members can be scoped to one location or allowed all-location visibility. Treat those as governance controls, not optional UI trivia.
Governance for groups
Multi-site automation without governance becomes inconsistent faster than single-site automation.
| Control | What to define |
|---|---|
| Change control | Who may edit global scripts vs site hours/types; how changes are tested |
| Role permissions | Central ops vs site managers vs location-scoped reception |
| Audit logs | Who changed rules; which location a booking/call belongs to |
| QA sampling | Sample transcripts per site, not only network averages |
| Incident ownership | Who owns telephony vs PMS vs AI path failures at 08:00 Monday |
| Site onboarding | Checklist before a new location joins the automated path |
Resilience design for peaks and outages sits in the healthcare call-handling resilience guide—groups need site-named owners on that checklist.
Governance example (hypothetical)
Hypothetical: A four-site group lets only central ops edit global urgent-language scripts. Site managers may change local hours and which assessment types are phone-bookable. Location-scoped receptionists see only their site’s calls and tasks. Weekly QA samples ten calls from each live site; rule-error bookings are tagged by site before the next location is enabled.
Phased rollout plan
- Pick one site and one workflow (for example Site A out-of-hours FAQ + one approved booking type).
- Document the matrix for that site; freeze global safety scripts.
- Connect telephony and diary for that site only; verify create/change/cancel where in scope.
- Test failures: wrong location chosen, no availability, unanswered transfer, PMS timeout.
- Measure site answer rate, booking completion, rule-error corrections for two weeks.
- Expand to a second site or a second workflow—not both on the same day.
- Only then consider cross-site offer scripts, and only with travel-consent language.
Hypothetical rollout: A three-site private group enables AI on Site A evenings for assessments only. After two weeks of clean writes, Site B joins with the same type. Cross-site offers wait until both diaries and deposit rules match.
Multi-site metrics (use your baseline)
| Metric | What it shows |
|---|---|
| Call distribution by site / number | Where demand actually lands |
| Site-specific answer / abandon rate | Whether one site is still failing locally |
| Cross-site booking rate | How often callers accept another location (if offered) |
| Transfer / fallback rate by site | Whether escalation paths work |
| Rule-error rate | Bookings staff must correct (wrong site, type, clinician) |
| Location-scoped QA findings | Script drift at a single branch |
Do not set fabricated network targets (“0% abandon,” “full utilisation”). Compare each site to its own pre-automation baseline and to peer sites in the same group.
Failure cases and safety boundaries
Failure cases to design explicitly
- Caller selects Site A; diary write lands on Site B because routing was wrong.
- Site hours override missing → overnight books into a closed local diary.
- Location-scoped staff cannot see a central overflow task → callbacks stall.
- One site’s PMS connector fails while others work → false “network is fine” reading from blended metrics.
- Cross-site offer without travel consent → complaints and DNA risk.
Safety boundaries (administrative only)
The assistant must not diagnose, prescribe or give emergency medical advice at any site. Urgent language should stop routine booking and follow the group safety script (typically NHS 111, 999, approved urgent pathway, or transfer). Site differences never override that floor.
Build vs buy vs central human team
| Model | Strength | Weakness |
|---|---|---|
| Build internal telephony + scripts only | Full control | Slow; hard to maintain location matrices |
| Central human call team | Judgement and empathy | Costly; still needs site rules and diary access |
| Buy AI layer on existing numbers | Scales routine admin; location tooling if supported | Needs governance; not a substitute for unclear rules |
| Hybrid (recommended starting point) | AI for routine; humans for exceptions; clear site owners | Requires disciplined change control |
Buying AI does not remove the need for a named multi-site operations owner. Pair the buy decision with the matrix, the number plan and the one-site pilot gate above.
Frequently asked questions
What makes multi-site AI reception different from a single clinic?
Multi-site groups must handle inconsistent hours, location-specific services, pooled or local demand, number routing, shared staff permissions and site booking rules. A single-site script usually fails when those differ.
Can Clero automatically load-balance bookings across all sites?
Not as a silent network optimiser. Callers are routed by number configuration and location choice; another site is offered only when your rules allow it. Provider load-balancing inside a connected PMS location is separate from cross-site diary balancing.
Should a healthcare group use one central number or local numbers?
Either can work. Local numbers preserve familiarity and default to a site. A central number needs clear location detection and fallbacks. Many groups keep both: local lines plus a group overflow path.
How do global rules and site rules interact in Clero?
Groups can set organisation defaults and override per location where needed—for example business hours—while keeping shared safety and escalation standards. Confirm which settings inherit and which are site-owned before launch.
How should multi-site rollout be sequenced?
Start with one site and one workflow, test failure cases, measure site metrics, then expand. Adding every location on day one multiplies rule errors.
Is this the same as a DSO guide?
No. This page covers multi-site healthcare operations generally. Dental service organisations should also use the DSO-specific guide for dental network depth.
Next step
Draft the global vs site matrix for two locations, choose central vs local number behaviour, and run a one-site pilot before network expansion. Continue into DSO, mixed NHS/private, booking, resilience and PMS integration as needed—without treating this page as a single-site sales rewrite.