A clinic phone system with a CRM: the full guide
A clinic with several locations has one problem that looks small until you run into it: the patient does not know, and does not care, which site they are calling. They are calling the clinic. Everything after that is your job.
This guide is for whoever has to decide how that actually works: a practice manager, an administrative lead, or an owner who has already noticed that three phones at three addresses are not a system.
What the phone system actually solves
An exchange is not "a phone number for the business". It is the layer between the call and your organisation, and it decides three things:
- Where the call goes. Not by which number was dialled, but by what the patient needs.
- What the person answering knows. Whether they can see this patient's history, or ask again for everything the patient already said last time.
- What survives the call. A recording, a note, a callback request, or nothing at all.
If the system you are considering only solves the first, it is a phone exchange. If it solves all three, it is patient-service infrastructure, and the difference shows up daily.
Cloud or self-hosted
This is the first real decision and it shapes the rest.
A cloud exchange is rented monthly, runs within days, and maintenance is not your problem. For most businesses that is the right answer and there is nothing embarrassing about it.
Self-hosted runs on infrastructure you control. It is slower to start and maintenance becomes your responsibility. In return you control two things that carry weight in a medical setting: where call recordings physically sit, and who can reach them.
The rule we would apply: if you record conversations with patients and that is part of your process, self-hosting stops being an indulgence. If you do not record and will not start, cloud almost always wins.
The trade is real in both directions. It is worth making deliberately rather than by default.
Recordings are personal data, of the sensitive kind
A call in which a patient explains why they are ringing contains information about their health. That is not ordinary customer correspondence.
The practical consequences we most often see skipped:
- The patient has to be told the call is recorded, before the recording starts.
- How long recordings are kept, and what happens afterwards, has to be a decision. "Forever" is not a policy.
- Access has to be limited to people who need it for their work, not to everyone with a login to the dashboard.
- If the exchange is run by a third party, they are processing that data on your behalf, and that needs to be agreed in writing.
None of this is exotic. It gets missed because a phone reads as equipment rather than as a system that processes personal data.
Routing should follow the organisation, not the org chart
The classic mistake is a menu that repeats your internal structure: press 1 for reception, 2 for accounts, 3 for management. Patients do not think in departments. They think "I want an appointment", "I am running late", "something hurts now".
The better shape is a menu built from reasons for calling, with the system deciding which department that turns into. Which team owns it is your problem, not theirs.
The second thing worth insisting on: routing between locations has to be one system, not three. If a patient rings site A but wants an appointment at site B, the call should reach B without the patient hanging up and dialling another number.
Urgent calls do not wait in a queue
For some calls, waiting for a free operator is not acceptable. That needs its own path: a group of handsets that ring at the same time, not one after another.
It is a small piece of configuration with disproportionate weight, and it is among the first things we would check in somebody else's system.
The CRM: what the minimum actually is
"With CRM" appears on a lot of quotes and means very different things. The minimum that earns its place in a clinic:
- Call history per patient, not per number. One patient may ring from three different phones.
- What was agreed. One free-text field filled in during the call does more work than the most thorough form nobody completes.
- Callback requests as a list with a status, not a note on paper.
- Missed calls as a task, not a line in a log. A missed call nobody picks up is a lost patient.
Everything beyond that is nice. It is not the minimum.
Real time is not showmanship
An operator dashboard that shows the state of the lines the moment it changes leads to different decisions than a report you refresh.
An operator who can see a free colleague at the other site transfers the call. One who cannot leaves the patient waiting. The difference is not the interface, it is which decisions are available at all.
Integrating with what you already run
The question is not "does it integrate", it is "with what exactly, and in which direction". Before signing, check:
- Can the system read your appointment calendar, or will you keep two?
- When an operator records a request, where does it land?
- If you change your booking software next year, what breaks?
"We have an API" is not an answer. Ask who writes the connection and who maintains it afterwards.
What happens to your current numbers
This is the question that worries people most and gets asked least. The numbers on your signage, in your Google profile, on your cards and in your patients' heads are an asset. Changing the exchange should not mean changing the number.
Porting is standard practice and it works, but it runs to a schedule and needs paperwork from your current operator. Two things worth knowing up front: a port is planned for a specific day rather than happening incidentally, and on that day it is sensible to run the old and new systems in parallel instead of trusting everything to switch at once.
If a vendor tells you it is easier to just take a new number, that is easier for them, not for you.
What the switch looks like
Replacing the phone system of a working clinic is not an implementation, it is surgery on something live. The order that lowers the risk:
- Listen before configuring. A week of watching who calls, about what and when, before anyone draws a menu.
- Run in parallel. The new system takes part of the traffic while the old one is still alive.
- One site first. If the logic is wrong, it is better discovered at one address.
- Recordings and integrations last. They are layers on something that already works, not part of day one.
A plan that opens with "we go live Monday across all sites" is a plan that will spend Monday explaining itself to patients.
What to measure once it is running
If you do not measure, you will argue from impressions. The four numbers that actually lead to a decision:
- Missed call rate, by site and by hour. It shows when you are short-staffed, not whether your staff are slow.
- How many missed calls got a callback, and how quickly. This is the number that turns most directly into booked appointments.
- Average wait before answer.
- Distribution by reason for calling. If 60 per cent of calls are "I want an appointment" and your menu puts that option third, the menu is wrong.
Each of those leads to a specific action. Everything else is interesting, but it is not a metric.
What to ask the vendor
A short list that sorts quickly:
- Where are call recordings physically stored?
- Who on your side can access them, and how is that access logged?
- If we leave, in what format do we get our history back?
- Can you ring several handsets at once for an urgent path?
- What happens if one site loses its internet connection?
- Who maintains the link to our booking software, you or us?
- What is in the monthly fee, and what is billed separately?
Question 3 is the one that most often gets an evasive answer.
What drives the price
There is no sensible single answer, but there are sensible factors: how many sites and extensions, whether calls are recorded and how long recordings are kept, how many integrations with other systems are needed, and whether you want self-hosting with support.
What usually does not move the price much is call volume. If somebody is billing you mainly per call, ask why.
When you do not need this
The honest answer: if you are one site with one administrator who answers everything, you probably need a good phone and the discipline to write notes, not a platform.
The case appears when calls start getting lost between people or between locations. Until then, an exchange is money spent solving a problem you do not have yet.