Practice management software (PMS) is the clinical and operational system of record for a dental practice: charting, medical history, treatment plans, the day list, and recalls for patients you are already caring for. A dental CRM is the system for people who have enquired and are not yet, or not only, a record in the PMS. It holds the source, the owner, the stage, the conversation, and the next action until they book or you close the lead. UK clinics need both. They are not rival brands of the same product.
The PMS remembers the patient you are treating. The CRM remembers the person who asked, and makes sure someone answers. Mixing those jobs up is how enquiries get lost and clinical records get cluttered.
Why the comparison keeps coming up
Most UK practices already pay for a PMS. Systems in that category include products such as Dentally, Software of Excellence, and the other clinical platforms teams run the day on. When enquiries start arriving from the website, Facebook, WhatsApp, and email, it is natural to ask the PMS to "just hold the leads as well". Sometimes a spreadsheet appears beside it. Sometimes every Facebook lead is created as a patient record so that it exists somewhere.
That instinct is understandable, and it is the wrong shape. Our earlier guide, what a dental practice CRM should do, describes the enquiry system on its own. This article is the comparison: what stays in the PMS, what belongs in a CRM, and where the two should meet when a consultation is actually booked.
What practice management software is responsible for
The PMS is where clinical care is recorded and where the booked day is run. A competent PMS is built for dentists and nurses as much as for reception. It is the place for charts, periodontal records, medical histories, estimates and plans that a clinician owns, appointment books with surgeries and clinicians attached, recalls for people who attend, and the financial record of treatment that was done.
It assumes, most of the time, that the person is a patient. They have a record because you are caring for them or you are about to. The screens are dense because dentistry is dense. That is a virtue in the surgery and a poor place to triage a one-line Facebook enquiry at 9pm.
Recalls, examination reminders, and the existing-patient relationship live here for a reason. Those people are already yours to look after, under the policies you run as a practice. Do not copy that whole job into a marketing database and hope the two stay in step.
What a dental CRM is responsible for
A CRM starts earlier. The person may never become a patient. They asked about implants, aligners, a new patient exam, or an emergency visit, and someone has to reply, follow up, and either book a consultation or close the lead honestly. The record you need at that stage is not a chart. It is:
- Who they are, and how to reach them (name, mobile, email).
- Where they came from (website, WhatsApp, SMS, email, Facebook, phone, referral).
- What they asked, in their words, plus the transcript of what you already replied.
- Who on the team owns the next action.
- The stage: new, contacted, consultation booked, treatment started, won, or lost, and why it was lost.
- Whether they have asked you to stop messaging them.
The point of those fields is behaviour. A PMS will store a phone number. A CRM should make an untouched lead impossible to ignore on a Monday morning. If your "CRM" does not change what reception does before lunch, it is a second database, and you do not need one of those.
Side by side
| Job | Practice management software | Dental CRM |
|---|---|---|
| Clinical notes, charts, medical history | Yes. This is the record of care. | No. Do not keep a shadow chart in the enquiry tool. |
| Day list for booked visits | Yes. Clinician, surgery, length, status. | No. It can record that a consultation was booked. It should not run the clinical day. |
| A new enquiry at 9pm from the website or Facebook | A poor fit. The person is not a patient yet. | Yes. Capture, acknowledge, assign, follow up. |
| Who owns follow-up until they book | Rarely designed for this. Inboxes hide it. | Yes. An owner and a next action are the product. |
| Which source became a booked consultation | Partial at best, and usually only after they exist as a patient. | Yes, if the source was stored on the enquiry from the start. |
| Recalls for people who already attend | Yes. Keep this with the clinical system. | No. Do not rebuild recall in the CRM. |
| Complaints and consent for treatment | Yes, under the practice's clinical process. | No. Hand these to a person and to the clinical record. |
| Speed of the first reply | Not its job. | Yes. The pipeline should show who waited. |
Read the table as a division of labour, not as a score. A PMS that is "bad at Facebook leads" can still be the right clinical system. A CRM that is "good at chats" is unsafe if a team starts writing treatment decisions into it because the box was handy.
Failure modes that show up in real clinics
Every lead becomes a dummy patient
Creating a full patient record for every advert enquiry feels tidy until the database fills with people who never attended, never consented to a clinical record, and never should have been mixed into recall. Reception then hesitates to search the PMS, because half the names are not patients. Close the lead in the CRM. Create the PMS record when there is a real booking or a real clinical encounter, using your normal identity checks.
The recall module is asked to chase cold enquiries
Recall is for people under your care. A person who asked about implants once, three weeks ago, and did not book, is not a recall. They are an open lead. Putting them on a clinical recall list blurs marketing with care and trains the team to ignore the list.
A spreadsheet beside both systems
Spreadsheets can bridge a week. They cannot chase, they cannot show a transcript, and they quietly become the only place that knows the truth. If the CRM and the PMS disagree, nobody trusts either. Pick the CRM as the enquiry truth and the PMS as the clinical truth, and stop maintaining a third copy.
Two conversations about the same person
The PMS mailbox has one reply. A personal WhatsApp has another. The website chat has a third. The patient experiences a practice that does not remember them. The fix is a shared enquiry inbox that writes onto one lead, with WhatsApp, SMS, email, and Facebook on that lead. The clinical notes still get written once, in the PMS, by the people who are allowed to write them.
Where the two systems should meet
The handover moment is a booked consultation, not the first click. Up to that point the CRM holds the relationship. When the patient books, the team creates or matches the person in the PMS in the way you already do for any new patient, and the CRM stage moves to consultation booked. Source stays on the CRM record so you can later see which enquiries became visits, without asking the clinical system to be a marketing report.
After that, the jobs diverge again. Treatment plans, visits, and recalls live in the PMS. Any further enquiry chase (a missed consult, a patient who asked for finance information and went quiet) can still sit as a task on the CRM, with a link back to the fact that they are now a patient. You do not need a live two-way copy of the chart to do that. You need discipline about which system is allowed to say what.
Some practices later connect the systems so a captured lead can be handed to the PMS, or a booking can update the CRM stage. That is an integration choice, discussed against your actual setup. It is not a reason to collapse the two products into one. Denbot's position matches that split: it handles enquiries, conversations, and follow-up. You keep your existing system for clinical records and the day-to-day running of the practice.
What to buy, in practice
If you have no PMS, that is a different project. Do not adopt an enquiry CRM and pretend it is a clinical record. If you have a PMS and new enquiries still die in inboxes, you are missing the CRM layer, not another clinical module. Buying a second PMS will not answer a Facebook lead at 9pm, and bolting a generic sales CRM on top will not know what a dental consultation is unless you configure it carefully and keep clinical data out of it.
A dental CRM should feel small. Stages a receptionist can explain. An owner on every lead. A next action. Source. A transcript. A stop flag. Reporting that answers "how many of last month's enquiries booked a consultation?" If the demo is mostly dashboards and not a morning list of untouched leads, keep looking.
Denbot is that enquiry layer for practices that want AI replies plus a pipeline across website chat, WhatsApp, SMS, email, and Facebook leads. It is not practice management software, and a practice that needs charting, medical histories, and a day list should not shop for those inside it. Use the table above in the demo. If a tool claims both columns without a pause, ask who is accountable for the clinical record. The answer should be your clinicians and your PMS, not the chatbot.
Frequently asked questions
Can the PMS be our CRM if we are disciplined?
You can store a note and a phone number. You will still struggle with after-hours capture, shared conversation history across WhatsApp and Facebook, and a clear owner for people who are not patients. Discipline does not add features the product was not built for.
Should every enquiry exist as a patient in the PMS?
No. Create the clinical record when there is a booking or a clinical encounter, under your usual process. Keep unsuccessful enquiries in the CRM so the PMS stays a record of care.
Does a CRM replace recalls?
No. Recalls for patients of the practice belong in the PMS. The CRM chases open enquiries. Mixing the lists is how marketing messages land on clinical pathways.
What should we integrate first?
First, make the CRM the only enquiry inbox, with an owner and a stage. Then decide whether a booked consultation should create or match a PMS record automatically. Do not start with a two-way clinical sync and hope the pipeline appears.
Is Denbot a practice management system?
No. Denbot focuses on patient enquiries, conversations, and follow-up. Clinical records and the day list stay in the PMS you already run.
Keep the enquiry layer separate
Denbot is the CRM for patient enquiries, conversations, and follow-up across website chat, WhatsApp, SMS, email, and Facebook leads. Your practice management software stays the clinical record.
Book a demo