CRM and PMS guide
Dental group CRM versus PMS: what stays where
A dental group has to decide, workflow by workflow, what the practice-management system already owns and where a connected layer earns its place. This is the worksheet we use to make that decision with a group, before any build starts.
Why this decision comes before any build
A dental group does not need a new system for every problem. Before any code gets written, the useful question is narrower: for this one workflow, what does the practice-management system already do well, and where does a connected layer earn its place?
Get this wrong and you end up with one of two bad outcomes. Either you build a workflow layer that duplicates something the practice-management system already handled, or you keep pushing a workflow into a system that was never built for it and watch staff route around it with spreadsheets and paper notes.
This guide is the worksheet we use to make that call with a group, before a pilot is scoped. It is useful whether or not you ever talk to us.
What the practice-management system usually owns
Most practice-management systems, across brands, are built around the clinical and financial record: the chart, the treatment plan, the schedule, the ledger. That is the system of record, and it should stay that way. A workflow layer that tries to become a second clinical record creates two places for the same fact to disagree, which is worse than the problem it was meant to solve.
Scheduling, clinical notes, treatment planning, billing and insurance almost always belong in the practice-management system a group already runs, whether that is Open Dental, Dentrix, Eaglesoft, Denticon, Curve or something else. None of that should move.
What a workflow layer can add
A workflow layer earns its place on the steps around the clinical record, not inside it: where an inquiry came from, which location owns it, who is responsible for the next action, what a patient prefers, and what happened at the end. Those steps often live across a call center, a front desk, a coordinator's inbox and a few spreadsheets, with no single record of where any one inquiry stands.
The shape of the work is usually the same: an inquiry arrives, a coordinator takes ownership, a consultation is booked and attended, a plan is discussed, the patient decides, care is scheduled, and someone follows up. A workflow layer tracks that chain across locations and staff. It does not decide anything clinical, and it does not touch the ledger.
Three ways to close a gap
Once you know which step is missing, there are three ways to close it. Which one fits depends on the workflow, not on a general preference for building or buying.
Configure what you already have
Many practice-management systems, and the engagement tools that sit on top of them, already have a field, a tag or a report that covers a specific gap. If a location's real problem is that a report does not exist yet, configuration is usually the cheapest fix, and the fastest to try first.
Connect a layer beside it
When the gap is a handoff between people or locations, a thin layer that reads and writes a few fields is often enough. It does not duplicate the clinical record. It watches for a status change and carries the handful of facts a coordinator needs to pick up where someone else left off.
Build a custom workflow layer
If the gap spans multiple locations, multiple systems after an acquisition, or a workflow specific enough that no configuration option covers it, a custom layer is worth considering. That is the option this site is built to talk about. It is also the most work of the three, so try configuration and connection first.
A scope worksheet, one workflow at a time
Fill this in for each candidate workflow before deciding anything.
| Question | Why it matters |
|---|---|
| Which step is missing: routing, follow-up, reconciliation or referral status? | Names the actual gap instead of "a CRM" in general |
| Does the practice-management system already have a field or report for this? | Rules out configuration before anything gets built |
| How many locations and systems does this workflow touch? | A single-location gap rarely justifies a custom build |
| Who owns the workflow today, and would they use a new tool? | A workflow with no owner will not be maintained either way |
| What would you measure to know it worked? | Sets the terms of a pilot before it starts |
Signals that point toward each option
| Signal | What it usually means |
|---|---|
| One location, one system, one clear reporting gap | Configuration of what you already have is probably enough |
| Multiple systems after growth or acquisition | A connected layer earns its place, so records agree across systems |
| The gap is a missing handoff between people or locations | That is close to what a custom workflow layer is for |
| No one can say who owns the workflow today | Settle ownership before you settle on software, of any kind |
Questions worth asking any vendor, including us
- What exactly does this system see and write in our practice-management system, and under whose permission?
- What happens to a record if a sync fails partway through?
- Who owns the code and the data if we stop working together?
- What does a pilot cost, and what does it cost to keep running afterward?
- Has this been built for a dental group before, and if not, what has it been built for?
That last question deserves an honest answer from anyone you ask it of. Ours: we have not delivered a workflow system for a dental group yet. We have built CRM, communications and multi-role portal systems in other fields, and the synthetic demonstration on this site was built to show the shape of a handoff, not to stand in for dental experience we do not have.
What we do not know yet
Every practice-management system publishes its own rules about what an outside system may read, write and connect to, and those rules change by vendor, by version and sometimes by account. We confirm the specifics for your system during discovery, not before. We also have not run this workflow with a practicing dentist or a group's own staff yet. A synthetic demonstration shows the shape of an idea. Practitioner review and real use are what would validate it.
Using this with us, or without us
This worksheet is useful whatever you decide, including staying with what you have. If you want help filling it in, that is the first step of our process, before any pilot is scoped, and you keep the result either way.
We start with one workflow and a few of your people, on your own data.
Discuss a group workflow