Every dental practice is slightly unusual. Treatment names differ, payment arrangements differ, what counts as an appointment type differs, and the vocabulary a clinic uses with its own patients has usually evolved over years. Software arrives with defaults that match none of this exactly.
What happens next determines whether the system fits the clinic or the clinic bends around the system. The deciding factor is rarely how flexible the software is in principle. It is whether changing something requires a developer, a support ticket, or five minutes at the desk.
Why this matters more than it sounds
The consequence of hard to change configuration is not inconvenience. It is data that quietly stops being true.
Consider a clinic that introduces a new treatment. If adding it to the system is easy, it gets added and every instance is recorded correctly from day one. If it requires contacting the vendor and waiting, staff need something to select today, so they pick the nearest existing option. That choice is made once, under pressure, and then repeated for months.
A year later the clinic asks how much of that treatment it performed. The answer is unobtainable, because it was recorded as something else. Nobody did anything wrong at any point, and the data is still wrong.
The cost is not only in reporting. A patient asking what they were charged for, or an insurer asking what was done, gets an answer drawn from whatever label was convenient that day. The clinic is not being inaccurate deliberately; it is reading back a record that was compromised at the point of entry by a list it could not change.
The same pattern applies to payment modes, appointment types and anything else staff must choose from a list. The rule is consistent: a list that cannot be changed easily will be misused rather than left incomplete, because the work has to be recorded somehow.
What a clinic should be able to change itself
| Setting | How often it changes | Cost of not controlling it |
|---|---|---|
| Treatment names and types | Several times a year | Work recorded under the wrong label |
| Payment modes | Occasionally, but urgently when it happens | Payments recorded as cash that were not |
| Appointment types and durations | As the clinic learns its own timings | A calendar that does not reflect reality |
| Staff roles and permissions | On every hire or departure | Access that outlives employment |
| Document and message templates | Rarely, then all at once | Out of date wording going to patients |
| Clinic details and hours | Seasonally | Patients told the wrong thing |
The second row deserves attention because it is the one clinics discover at the worst moment. A practice that starts accepting a new payment method on Monday needs it in the system on Monday. If it is not there, every transaction that week is recorded inaccurately, and reconciling that later is tedious work that produces a worse record than doing it right would have.
Roles change more often than anyone plans for. Hires, departures, someone taking on responsibility for the cash. Where treatments, payment modes, templates and clinic settings can be adjusted without a developer, these arrive as five minute tasks rather than items on a list that waits for the vendor.
Configuration is not customisation
These get used interchangeably and mean quite different things, with different risks.
Configuration is choosing within what the software already supports: adding a treatment, defining a role, setting an appointment length. It is reversible, it does not affect anyone else, and it survives updates.
Customisation is changing how the software itself behaves, usually built for one customer. It solves a specific problem precisely and carries a long tail: it may not survive an upgrade, it is often the reason a clinic cannot move to a newer version, and the person who understands it eventually leaves.
The practical guidance for a dental practice is to treat customisation as a last resort and to be suspicious of needing it early. A clinic that requires bespoke development in month two has usually either chosen software built for a different kind of practice, or is trying to reproduce a workflow that existed because of a limitation it no longer has.
Deciding before configuring
The mistake is configuring as you go, letting whoever hits a gap first decide how to fill it. Lists assembled that way are inconsistent within weeks: two entries meaning the same thing, spelled differently, both in use.
Set the lists before go live, in one sitting, with the people who will use them. That means a dentist for treatment names, reception for appointment types and payment modes, and the owner for roles. It takes an hour or two and is the highest value hour of the whole implementation.
Agree naming conventions at the same time, because they are what keeps a list legible as it grows. Decide whether entries are sentence case or title case, whether abbreviations are allowed, and whether the tooth or site forms part of the name or a separate field. These sound trivial and are the difference between a list that can be scanned in two seconds and one that has to be read.
Keep the lists short at first. Every option is a decision someone makes at the chair or the desk, quickly, and a list of forty treatments produces inconsistent selection because people pick whichever plausible entry appears first. Start with the twenty you actually perform and add as needed.
Write down what each entry means where it is not obvious. The difference between two similar appointment types is clear to whoever created them and opaque to a receptionist hired next year. A one line note beside each is enough and prevents a category from drifting in meaning.
Who should hold the keys
Being able to change configuration and letting everyone change it are different things, and clinics often collapse them.
If any user can add a treatment type, the list grows in several directions at once. Two people add the same procedure under different names in the same week, both use their own, and the reporting is split from then on. The fix is not to lock it down to one person but to make the change deliberate rather than incidental.
The arrangement that works in most practices is that two people can change configuration, and there is an understood route for everyone else to request it. Two rather than one, so a holiday does not block anything. An understood route, because the alternative is a workaround, and workarounds are exactly what good configuration is supposed to prevent.
Make the request route genuinely quick. If asking takes a week, staff will stop asking, and the whole arrangement collapses back into people selecting whichever existing option is closest. A practice where a new treatment can be added the same day it is first performed has the right balance.
Keep a note of who changed what and when, even informally. When a report looks odd six months later, the usual explanation is that a list entry changed meaning at some point, and knowing when turns a mystery into a fact.
Keeping it tidy over time
Configuration decays in a predictable way. Entries get added for a specific situation and never removed. Two people add the same thing under different names. A treatment stops being offered and stays on the list.
Review the lists annually, at the same time as the permissions review. Three questions cover it. Is anything here that we no longer do. Are there two entries that mean the same thing. Is anything missing that staff have been working around.
The third question is the one that needs asking out loud, because workarounds are invisible from above. Staff rarely report that they have been recording one treatment as another; they simply do it, and it looks like data. Asking directly, without any suggestion that it was wrong, is the only reliable way to find out.
Retire rather than delete where you can. An old treatment name still appears in historical records, and removing it entirely can make past work unreadable. Marking it unavailable for new entries keeps the history intact while stopping the list growing.
Questions to ask before you buy
- Add a treatment type now, during this demo. Not describe it. The answer to this question is a demonstration.
- Who can change configuration? If it is only an administrator, and you have two, holidays become a constraint.
- What happens to existing records when a list entry is renamed? Do past entries follow the change or keep the old label.
- Can an option be retired without deleting it? This determines whether your historical data stays readable.
- Is anything on the list that only the vendor can change? Ask for the specifics rather than a reassurance.
Question three is more consequential than it sounds. If renaming a treatment rewrites every historical record, your past data silently changes meaning whenever the list is tidied. If it does not, you end up with two labels for the same thing in reports spanning the rename. Neither behaviour is wrong, but you need to know which one you have before you rename anything.
Question one is worth insisting on. It takes under a minute when the answer is good, and the way a vendor responds to being asked tells you most of what you need to know about how the rest of the relationship will go.
If you want to see what a clinic can adjust for itself and what it cannot, the feature overview sets out the structure, and you can book a demo and ask to add a treatment type while you are on the call.
