Custom CRM for dental groups
Custom CRM and connected patient-coordination workflows for dental groups
We build the workflow layer that sits beside your practice-management system, so a group sees every inquiry, referral and follow-up in one place across locations. We start with one workflow and a few of your people, on your own data, before anyone discusses a wider rollout.
Said plainlyWe are new to dental groups. The example below is a synthetic demonstration, built to show the shape of the work. The first engagement is a discovery call and a small pilot.
An inquiry or a referral can lose its owner between locations
These situations come up as a dental group adds locations. We have not measured how often. Compare this list against your own.
-
EX-01Routing
An inquiry can land at the wrong location
A call center or a web form takes the first inquiry. Routing it to the right location is a manual step today, and a missed one leaves the inquiry with no owner.
-
EX-02Follow-up
Follow-up after a consultation depends on one person remembering
A plan is discussed after a consultation, and the next action often lives in one coordinator's head. If that person is out, follow-up does not happen on its own.
-
EX-03Mixed systems
A newly acquired location runs a different system
A group that grows by acquisition can end up running more than one practice-management system. Seeing status across locations means reconciling them by hand.
-
EX-04Referral
A referral between a general practice and a specialist can go quiet
The general practice sends a referral. Whether the patient was seen is not always visible back home, so someone has to call and ask.
We are not claiming every group has all four, or that your current tools cannot solve them. Tell us which sounds like yours. We also read what practice-management vendors publish about API access and what it costs, including which ones publish nothing without a partner login.
A coordination layer beside your practice-management system
This is the list of things call-center staff, front-desk staff and coordinators do around an inquiry or a referral, connected to the system that already holds the patient record.
Who uses it
Call-center and front-desk staff
Take the first call or form and route it to the right location.
Treatment and referral coordinators
Own a case from consultation to scheduled care, visible across locations.
Group operations and IT
See inquiry volume, coverage and exceptions across the group at a glance.
Clinicians
Keep every clinical decision. The layer tracks only the administrative step.
What it connects to
The workflow layer
Tracks inquiry source, location, responsible staff, next action and outcome.
- Feeds in
Call intake, phone or web
Recorded once, wherever the first inquiry lands, then carried into the workflow.
- Feeds in
Email and calendar
Consultation and follow-up messages attach to the record they belong to.
The practice-management system
Stays the clinical and billing record. The workflow layer only connects to it.
Synthetic demonstration: invented records
Harbor Dental Group: a referral moves between two locations
Harbor Dental Group is invented for this demonstration. So are its two locations, Harbor Dental North and Harbor Dental South, its staff and the patient in the example below. No real practice, group or patient appears here.
A patient calls Harbor Dental North about a consultation. North cannot see them for two weeks, so the inquiry goes to Harbor Dental South. The reason for the call and the patient's availability travel with the handoff, so South does not ask the patient to repeat anything.
- 01North
Inquiry
Logged once at Harbor Dental North, with the reason for the call and the patient's availability.
- 02North
Handoff
North marks the inquiry routed to Harbor Dental South, with the reason and availability attached.
- 03South
Consultation booked
South books the consultation in the practice-management system and marks it scheduled in the workflow layer.
- 04South
Outcome recorded
After the visit, South records the outcome. North sees the result without a phone call to ask.
What this does not show. An invented scenario, built to show the shape of a handoff. No real practice, group or patient is shown, and no practitioner has reviewed this demonstration yet. We have not delivered a dental system for a client.
The questions that decide whether this is a good idea
- Q1Who owns the code?
- You do. The code lives in your repository. If we build on an open-source foundation, we name it and its licence first.
- Q2Who maintains it after handoff?
- Settled before the pilot, in writing: who upgrades it, who secures it, and what it costs each month. Us, your team, or both.
- Q3Does the workflow layer take over our practice-management system?
- No. The practice-management system stays the clinical and billing record. The workflow layer sits beside it and tracks the administrative steps.
- Q4Will it connect to our practice-management system?
- That is most of the early work. We confirm what your system's permissions allow and test the connection in the pilot.
- Q5What about patient data and privacy?
- Before any build touches real patient data, we settle how it is handled, a business associate agreement, and your system's own access rules, in writing. A first conversation needs none of it.
- Q6Where does AI fit?
- Inside the administrative workflow, with a person handling exceptions. Every clinical decision stays with your clinicians.
Discovery, one workflow, a pilot, then a decision
Each step produces something you keep, whether or not you continue. The first engagement is a discovery call and a small pilot.
-
Step 01
Discovery call
ProducesWe learn your locations, your practice-management system and the costliest workflow. You get a short written summary.
-
Step 02
Map one workflow
ProducesA map of one workflow: who does what, in which system, and where it breaks today.
-
Step 03
Scoped proposal
ProducesA fixed scope for a pilot: what gets built, for which locations, and what it costs.
-
Step 04
Working pilot
ProducesA small group of your staff use it with real data while the practice-management system keeps working.
-
Step 05
Your decision
Decision gateYou compare the pilot with the old workflow, then stop, extend it, or plan a wider rollout.
-
Step 06
Rollout and support
ProducesMore locations join on a schedule you set. Maintenance is agreed in writing.
Seven things to know before you talk to anyone about a dental group workflow
Gather these in an afternoon. They make every later conversation shorter. If referrals are the workflow that worries you, the referral tracking audit shows you how to test your own handoffs.
- Which practice-management system each location runs, and whether it is the same across the group
- Who takes the first call or web inquiry today, and where it goes next
- The one workflow that costs you the most time or the most lost inquiries
- Every system that workflow touches: scheduling, billing, a call center, a referral partner
- Who would maintain a new system, and whether you have IT staff
- Whether any acquired or newer locations run a different system than the rest
- What result would make you stop the pilot
Plain answers
- How long does a pilot take?
- It depends on the workflow and how many locations are involved. We set the length after the mapping step, not before.
- What does it cost?
- We quote a fixed scope once the workflow is mapped. We publish no price list; the scope decides the cost.
- We are a small group. Is this for us?
- It can be. A small group with one clear workflow is a good pilot. If configuration already solves it, we will say so.
- Have you built this for a dental group before?
- Not yet. We have built CRM, communications and multi-role portal systems elsewhere. The example here is a labelled synthetic demonstration; we have not shipped a system for a dental client.
Two people who have shipped software together for nearly ten years
Dental Group CRM is a site of The Goodstack Company. There is no sales team. You talk to the people who do the work. This is our first dental group work, and we say that plainly.
- Engineering and delivery
David
This is our first dental group work and David says so on the call. What he brings is the pattern: he runs beLoved Health, a distribution company, and built the workflow layer it runs on, which sits beside the systems that hold the records and tracks who owns the next action across locations. He writes the code here, and he expects to learn your clinical vocabulary from you.
- Product and design
Vidur
Vidur is the co-founder of Goodstack and leads product and design. He designed the original Goodstack and ran the studio with David. On this work he owns what a coordinator sees between patient calls, which has to be readable in seconds, and he has experience with SOC 2 compliance, which shapes how access is scoped before a build touches real records.
Start with one workflow
Tell us which practice-management system you run, how many locations, and the workflow that hurts most. We will reply with what we would look at first.