Healthcare AI Call Centre: When a Group Practice Should Centralise Calls

Coding Liquids tutorial cover featuring Sagnik Bhattacharya for Healthcare AI Call Centre: When a Group Practice Should Centralise Calls.
Coding Liquids tutorial cover featuring Sagnik Bhattacharya for Healthcare AI Call Centre: When a Group Practice Should Centralise Calls.

A multi-site medical or dental group should centralise calls when the sites share a scheduling system, the front desks keep being pulled between patients and the phone, and most calls are routine. A central AI-assisted queue then handles bookings and messages, with people behind it for anything clinical. If calls are mostly local and clinical, keep receptionists at each site.

Centralising is an operations decision first and an AI decision second. The AI makes a central queue cheaper to run, but it does not rescue one that patients dislike. The tests below sort the groups that will gain from the ones that will lose their patients' goodwill, and they take a fortnight of data, not a vendor demonstration.

Follow me on Instagram@sagnikteaches

What changes when calls go to one place

With a receptionist at each site, a call rings in the building the patient chose. It is answered by someone who knows the clinic, the dentist's habits and the car park. The cost is that each site must staff its own peak, so most of the day somebody is idle and at the busiest minute somebody is overwhelmed. Calls that go unanswered at one site cannot borrow capacity from another.

Connect on LinkedInSagnik Bhattacharya

With a central queue, calls from every site's number arrive in one pool, handled by a shared team plus an AI assistant for overflow and out-of-hours. Peaks at different sites rarely line up exactly, so the pool needs fewer people in total for the same service. The cost is the local feel and a harder rule set, because the central team must know every site's schedule, rules and exceptions.

Subscribe on YouTube@sagnikteaches

Five tests, in order

Test 1: do the sites share one scheduling system?

If every site books in the same system and the central team can see all diaries, centralising is feasible. If two sites run different systems, the central team needs two screens and double the training, and an AI assistant needs two integrations. Fix that first, or leave the odd site out of the pilot.

The Complete Excel Course with AI Integration thumbnail

The Complete Excel Course with AI Integration

From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.

By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner

Buy now

Test 2: how many calls does the front desk lose to the phone?

Count it. For ten working days at each site, log calls offered, calls answered, calls abandoned and the number of times a patient waited at the desk while the receptionist was on the phone. A site that abandons over, say, one call in ten at its peak and has a visible queue at the desk has a problem a central pool could solve. A site that rarely misses a call does not.

Test 3: how routine are the calls?

Take a sample of 200 calls across the group and tag each: book or move, cancel, price or insurance, directions or hours, forms, results, symptoms, complaint, other. A group where 60% or more fall into the routine tags has material for a central team and an assistant. A group where a third of calls are about results and symptoms needs a clinical-capable desk at each site, because those calls need local knowledge or clinical staff.

Test 4: do patients attach to the site or the practitioner?

If patients ask for "Dr [name] at the [site name] site", a central agent can book that only with accurate rules about who works where. If patients usually just want the nearest slot, the central pool is simpler. Check how many bookings are for a named practitioner and how often a patient changes site.

Test 5: can you staff and supervise a central team?

Someone has to own the queue: set hours, listen to calls, review the assistant's transcripts, update the rules and answer the vendor. In a group of two to six sites that is usually one practice manager with a deputy. If nobody has that time, a central queue drifts and quality falls without anyone noticing.

A worked capacity sum for a four-site group

An illustrative four-site dental group. Each site gets about 30 calls an hour at its peak between 8:30 and 10:00. An average call, including notes and booking, takes four minutes. That is 30 times 4, or 120 minutes of call work an hour at each site, which is two people on the phone full time at the peak. But each site's two receptionists also check in patients, so say only one is truly free for the phone. The site is short by about one person at the peak, and callers abandon.

Pool the four sites. Combined offered calls at the same hour are not 120 if peaks are staggered; say the pooled peak is 100 calls an hour. At four minutes each that is 400 minutes of work an hour, roughly 6.7 full-time call handlers. Add an AI assistant that takes routine overflow (booking and message-taking only) and can handle, say, a third of those calls: the human load falls to about 4.5 people. Against the eight people who would be needed across four sites to hold the same ratio at each peak, the central model needs fewer and gives better cover. These numbers are made up to show the method; run it on your own logs, and do not accept a vendor's estimate in their place.

Two cautions on the sum. Peak staggering is the assumption doing the most work, so check it in your logs by comparing site-by-site call counts per hour. And the AI's share of calls handled is the least certain number, so run a pilot with a cap on overflow volume before you build a staffing plan on it.

Central queue or per-site: side by side

PointReceptionist at each siteCentral queue with AI
Peak coverEach site staffs its own peakOne pooled peak, usually smaller than the sum
Local knowledgeHighDepends on the rule set and training
Front deskTorn between phone and patientsPhone work moves out of the building
Out-of-hoursVoicemail or nothingOne assistant and callback process for all sites
SupervisionEach site managerOne owner, one set of reports
RiskMissed calls at busy sitesOne outage affects every site; wrong-site bookings
Patient view"My clinic answered""Someone who did not know my clinic answered"

Hand-off rules the central desk needs written down

The assistant and the central team both work from the same rules. They should be short enough to fit on a page, and they should say who the call goes to, not just that it goes somewhere. For a group, they have an extra part: which site and which person.

Always pass to a person immediately (assistant: do not continue, transfer):
- any mention of pain, bleeding, swelling, breathing difficulty, chest symptoms, a child who is unwell, an accident, or "emergency"
- a distressed or angry caller, a complaint, a safeguarding concern
- a request for results, medication advice, or anything clinical

Pass to the caller's own site (not the central team) when:
- the caller is mid-treatment and names the clinician
- the caller asks for their site's reception by name

Take a message, never a booking, when:
- the patient is not found in the record
- the date of birth does not match twice

Always give the emergency instruction first when the call is out of hours.

Notice what is missing: no triage. The assistant does not decide how serious a symptom is. It spots words that mean "stop and get a person" and does exactly that. How to write call scripts and escalation rules for an AI receptionist goes deeper on wording these.

Queue design that keeps the local feel

Patients do not mind a central team when the experience feels local. Three design choices do that.

  • Keep each site's number. Forward each local number to the central queue, tagged with the site, so the greeting can say "[clinic name], how can I help?" before the caller says a word.
  • Let the caller press for the site. One option, "press 1 to speak to the clinic directly", routes to the local desk during staffed hours, so patients with a treatment question are not forced through the pool.
  • Show the agent the site on screen. The central agent should see which number was dialled and the site's diary first, so nobody asks "which clinic?".

Use time-of-day rules too. During a site's quiet hours, its local desk may take calls itself; during peaks, the central pool takes overflow after a short ring time. Adding AI answering to a medical practice phone system covers how that sits on an existing line.

The agreement: BAA or DPA, and what it must cover

A central call centre listens to everything, so the paperwork is not optional. If you are a HIPAA covered entity, you need a business associate agreement with the vendor, and the privacy rule (45 CFR 164.502(e)) lets the vendor pass patient information to its own subcontractors only with the same kind of written assurances, so ask to see that chain for the companies that record, transcribe, process and store the calls. If you have patients in the EU, the GDPR (Article 28) requires a processor contract, which is the data processing agreement, plus a check on where data is stored and a lawful transfer route (Article 44 onwards) if data leaves the region. Either way, ask three things in writing: what is recorded, how long it is kept, and which other companies see it.

A group adds one more question that a single practice does not face: is each site its own entity, or is there one group entity? The agreement should be signed by the entity that is responsible for the data, and the vendor's account structure should keep each site's data separable if a site is sold or leaves the group. For the full contract and retention list, use the BAA and retention checklist for an AI receptionist.

A pilot that proves it with two sites

Do not centralise four sites at once. Pick two that share a scheduling system and have the clearest phone problem, and run a six-week pilot.

  1. Weeks 1 and 2: baseline. Log calls offered, answered, abandoned, longest wait and desk interruptions at both sites.
  2. Weeks 3 and 4: central queue, no AI. Forward both numbers to a small central team. Compare against the baseline.
  3. Weeks 5 and 6: add AI overflow. Turn on the assistant for calls waiting over a set time and for out-of-hours calls, with the hand-off rules above and a weekly transcript review.
  4. End of week 6. Compare abandoned calls, wrong-site bookings, transfers that failed and patient complaints against the baseline.

An illustrative result: abandoned calls fall from 14% to 6% in the central phase and to 4% with overflow, wrong-site bookings rise from 0 to 3 in the first week then to 1 after a diary-rule fix, and two patients complain about repeating themselves. That is a decision with evidence: extend to a third site, fix the site-selection prompt first. How to measure an AI receptionist's return in the first 90 days gives the metrics.

Tagging 200 calls: what the sample might show

The routine-call test is the one groups skip, because it takes an afternoon. Do it anyway, since it decides how much the assistant can ever take. An illustrative tally for a four-site dental group, 200 calls drawn evenly across the sites:

Call typeCountShareAssistant may handle?
Book or move an appointment6231%Yes, with an identity check
Cancel189%Yes
Price or insurance question2412%Fact sheet answers only; otherwise a message
Hours, directions, parking2010%Yes
Forms and paperwork147%Yes: tell them where to find it
Results or treatment questions2613%No: message to the clinical team
Pain or urgent problem189%No: immediate transfer or emergency message
Complaint or other189%No: person

Adding the "yes" rows gives 62 + 18 + 20 + 14 = 114 calls, or 57%, plus part of the price questions. So this group is near the 60% line: a central team plus an assistant will help, but the human part of the queue matters, and the 26 results calls and 18 urgent calls need a person on the line at every hour the sites are open. A group where the same tally gave 35% routine would be told to improve local staffing first.

Staffing and hours for the central team

The central team does not need to match the sites' opening hours exactly. Cover the peaks, and let the assistant carry the edges. An illustrative plan for the four sites: two people from 7:45 to 10:30 each weekday (the shared morning peak), three from 10:30 to 12:30 when callbacks and results queries build, two through the afternoon, and the assistant alone for the first half hour and the hour after close, with a callback list for the morning. Re-draw this after four weeks from the real hourly counts, not before.

Give each person one site they know best, and rotate. A central agent who has sat at the front desk of one of the sites answers faster and sounds more local. Plan for sickness: a team of two has no cover, so train a site receptionist as a named back-up for each shift.

The weekly numbers a group manager should see

Keep the dashboard short. Six figures, by site and for the group, every week:

  1. Calls offered and answered.
  2. Calls abandoned, and the longest wait.
  3. Calls the assistant handled start to finish, and calls it passed to a person.
  4. Transfers that did not connect.
  5. Callbacks promised and callbacks completed within the target time.
  6. Wrong-site or wrong-practitioner bookings found.

The ratio to watch is calls the assistant handled that later needed a correction by staff. If more than a few percent of its bookings need fixing, tighten its rules or reduce its job list. Read ten transcripts a week alongside the numbers; a figure can hide the one conversation that should worry you.

Questions to put to a vendor that serves groups

  • Can one account hold several sites, each with its own number, greeting, hours and rules, and still report as a group?
  • Can the assistant read each site's diary, and does it need separate integrations for each system?
  • Can a site be removed from the account, with its recordings and logs deleted or exported, if it is sold?
  • Does a failure at the vendor route calls back to each site's own line automatically?
  • Who signs the BAA or DPA, and does it cover every company in the chain, including the one that stores recordings?

I have not compared vendors here, and no prices are quoted: vendors in this space sell by quote, and a figure printed in a tutorial would be out of date before it was read. Ask for each quote on the same volumes from your call logs, using the sum above as the shape.

Wrong-site bookings, outages and unreturned messages

A realistic one: the central team books a patient at the wrong site because two sites share a street name or share a practitioner on different days. Patients arrive at an empty waiting room. The fix is a confirmation line that always says the site name and address and the practitioner, and a text confirmation with the address.

Another: the group centralises, cuts front-desk hours at each site, and then the central queue has an outage. Every site loses its phones at once. Keep a failover: each local number must be able to ring the site directly if the central route fails, and someone must own the switch.

A third: managers read only the answered-call figure. The central queue answers 98% of calls, but a quarter of callers are told "I'll send a message to the clinic" and never hear back. Count call-backs completed within a set time, not only calls answered.

When to keep a receptionist at each site

Keep local desks when the calls are mostly clinical, when sites use different systems you cannot join, when each site is very different (a specialist clinic next to a general one), or when nobody can own the central team. In those groups, put the money into better lines and callbacks at each site first, then add AI only for out-of-hours and overflow. The comparison in AI receptionist vs front desk hire: a dental practice comparison works at a single site and will tell you whether even that helps.

If you want help running these tests on your own call logs, that is what my AI implementation consultation covers. The AI guide collects the rest of the series.

Questions group managers ask about centralising calls

How many sites before centralising makes sense?

Two sites can justify it if both run the same scheduling system and the front desks are constantly pulled between patients and the phone. Three or four is the usual point where pooling staff and one queue starts to pay. Below that, fix the phone setup at each site first.

Should the AI triage callers?

No. Keep it to routine jobs such as booking, rescheduling, directions, forms and taking messages, with firm rules to pass any symptom, urgency or distress to a person at once. Triage is a clinical decision and belongs with trained staff.

Do patients accept a central number?

Many do if the greeting names their clinic and the booking lands correctly, and many do not if they are asked to repeat themselves or reach the wrong site. Keep local numbers, forward them to the central queue, and let callers press for a person at their own site.

Which agreement do we need with the vendor?

If you are a HIPAA covered entity, a business associate agreement covering every step the call passes through. If you have patients in the EU, a data processing agreement and a check on where data is stored. Get the right one signed before any real call is routed.

Further reads

Sources: 45 CFR 164.502(e) on business associates and subcontractors; GDPR Articles 28 and 44 (read 4 November 2026). The capacity sums and call tallies are illustrative, not vendor data, and no vendor prices are quoted.

Want to know if one central queue suits your group?

On a 1:1 call we can take your call logs from each site, test the five questions on them and decide whether centralising is worth trying.

Book a 1:1 call with me