A demo is a performance of the best possible day. Everything is already set up, the data is clean, nobody is on the phone, and the person driving has used the product for two years. You will not see the Tuesday when a patient arrives whose record was half-migrated.
That is not dishonesty; it is what a demo is. The work is finding out what happens on the other days, and most of that has to be done before you sit down for one.
Settle your requirements before you meet a vendor
Write down what the clinic does, in the order it happens, and mark the three or four steps that hurt today. Not features — steps. "Finding out which patients still owe us money" is a step. "Reporting" is a category, and every product will tell you it has one.
Then separate the list into two: things that must be true on day one, and things you would like within a year. Vendors are good at the second list. It is the first list that determines whether you can actually switch.
Do this on paper before the first call. Once you have seen three products, your requirements quietly rearrange themselves into whichever one you liked, and you will never notice it happening.
The questions a demo will not answer
- What does the front desk do when the internet is down? Every clinic loses connectivity. Some products show you nothing; some keep today's schedule readable.
- Who can see clinical notes? Ask them to show you the same patient as a receptionist and as a clinician, in the same session. The answer should be visibly different.
- What happens when two people edit the same appointment? This occurs daily at a busy desk and is rarely designed for.
- How does a patient cancel at eleven at night? If the answer involves the phone, your no-show rate is a product decision you are about to inherit.
- What does month end look like? Ask to see the finance screen with a month of real-shaped data in it, not four rows.
- Which parts are extra? Ask directly which modules are not in the price you were quoted.
Ask these while sharing your screen with the vendor driving. "Can it do X" is answered yes by everybody; "show me" is answered differently.
Understand what you are actually paying for
Practice management software is sold in about four shapes, and the cheapest one on paper depends entirely on the shape of your clinic.
| Model | Suits | Where it hurts |
|---|---|---|
| Per seat / per user | Small teams where most people work full time | Part-timers and locums cost the same as full-timers |
| Per clinician | Clinics with many admin staff | The receptionist becomes free and the second dentist expensive |
| Per appointment or per patient | Very small or seasonal practices | Your bill grows exactly when you are busiest |
| Modular, priced per feature | Clinics that genuinely need only one part | The quote and the invoice are different documents |
We charge per seat, so it is fair to say where that is a poor deal: a clinic with eight people who each work one day a week pays for eight, and a per-clinician product would be cheaper. Any vendor who cannot tell you where their own pricing is a bad fit is telling you something else.
Whatever the shape, price the second year, not the first. Discounts land in year one; the number that matters is what you pay once the discount and the migration help have both ended.
The migration is the project
Choosing takes a few weeks. Moving takes a few months, and it is where switches fail. Ask three things about it, early, and get the answers in writing.
- What comes across? Patients and contacts usually. Appointment history sometimes. Clinical notes, attachments and financial history frequently not — and those are the three that matter in a dispute.
- In what form? A note imported as one undated blob of text is technically migrated and practically useless.
- Who does it? If the answer is you, ask what format they need, and check you can actually get that format out of your current system.
Ask your current vendor for a full export before you sign anything with a new one. Not a sample — the real thing. The answer to that request tells you more about your next contract than any demo will.
Getting out, and who owns what
The clinical record belongs to the clinic and the patient, not to the software. That is the principle nearly everywhere; what varies is how easy the vendor makes living up to it.
- Can you export everything yourself, without asking?
- In an open format — CSV, PDF, something a person can read — or in theirs?
- How long do you have after cancelling before the data is deleted?
- Where is it stored, and who processes it on their behalf?
If you handle patients in the EU, the UK or Türkiye, the last two questions are not paperwork — they belong in the agreement, and a vendor who has thought about them will have a document ready rather than an email promising one.
Run a trial that resembles a real week
A trial spent clicking around teaches nothing. Pick one real week and put it through the product in parallel with whatever you use now — the same bookings, the same cancellations, the same two awkward patients.
Have the front desk do it, not the owner. The person who spends six hours a day in the software should be the person who decides whether it is bearable, and they will notice in one afternoon what a buyer misses in three demos.
A shortlist worth using
- Write the day down and mark the three steps that hurt.
- Ask each vendor to show you those three steps, driving your scenario.
- Get the migration scope in writing, including what does not come.
- Price year two, with every module you actually need.
- Run one real week with the people who will use it.
- Check the exit — export, retention, and where the data sits.
If a product survives all six, the demo was the least informative part of the process, which is how it should be.
Common questions
- What is the difference between practice management and an EHR?
- Practice management runs the business of the clinic — scheduling, billing, stock, reporting. An EHR holds the clinical record. Many products do both to some degree, and the labels are used loosely, which is worth untangling before you compare quotes.
- How long does switching take?
- Plan for months rather than weeks, and for running both systems in parallel for part of it. The technical import is rarely the slow part; agreeing what the data means, and retraining the people who use it every day, is.
- Should a small clinic buy something built for large ones?
- Usually not. Software built for large organisations assumes roles, approvals and administrators you do not have, and the cost lands as configuration work rather than licence fees. The reverse also holds: outgrowing a very simple tool is a real cost, so ask what happens at three times your current size.
- Is cloud or on-premise better for a clinic?
- For almost every clinic under a hospital in size, hosted software wins — you are not staffed to patch a server or test a restore, and an unpatched machine in a back room is a bigger privacy risk than a reputable host. What matters is where the host keeps the data and what the agreement says about it.
Read next
Run the same six questions at us.
Every plan, every seat price and every module line is on one page, with nothing behind a "contact us" — including the per-seat model this post has just told you when to avoid. Price your second year before you speak to anybody.
See the pricing