Most clinic software rollouts do not fail because of the software. They fail because the week was too busy, because nobody asked the person on reception first, and because nobody inside the clinic actually owned it. The feature list wins the purchase. Daily work decides the rollout. Here is what a rollout looks like when the team genuinely comes with you: roles, timeline and numbers.
Why rollouts fail on people, not features
Behind almost every failed system change sit the same three patterns.
The date was wrong. Go-live landed in the busiest week of the quarter, because a quarter end looked like a clean cut. Accounting-wise it is. For reception it means learning a new interface under maximum pressure.
Nobody owned it. Every question landed with the owner, who was still finding her own way around. Two people got two different answers to the same question, and from then on the system was "unreliable".
The old system stayed switched on. First only for emergencies, then for the tricky cases, then for anything that mattered. Eight weeks later both were half in use and nobody could say where the binding appointment lived.
Then there is the cause that rarely gets said out loud. To the owner, new software is a strategic decision. To reception, it is a change to a habit performed twenty times a day, and the new version is slower at first and feels exposed in front of a patient. That is not resistance to progress. It is a craft problem, and it can be solved like one.
The internal champion, and who it should not be
One person owns the rollout. Not "the team", not "reception", but a name everyone knows. That person answers the small questions, collects the big ones, and is the single point of contact with the vendor.
What that person needs to bring:
- They do the daily work themselves. Watching from a distance hides where things snag.
- The team takes them seriously. Being trusted beats being technical.
- They are present throughout. Not on holiday in go-live week, not leaving in three months.
It should not be the owner. When the boss carries the rollout, nobody feels able to say something is not working, and she does not have the reception routine in her hands anyway.
The champion needs three things, or the role is just a title. Blocked time in the rota, meaning actual hours rather than goodwill. A direct line to the vendor rather than a general inbox. And the authority to settle small conventions alone: how treatments are named, which fields are mandatory, what a follow-up looks like in the calendar. Escalate questions like those and the project stalls.
If you are still choosing, put this into the comparison itself. Who supports the rollout and what it costs on top of the licence often separates vendors more sharply than the feature list does. We compared the common systems in this look at clinic software for aesthetic practices.
What to migrate and what to leave behind
Data migration is where projects quietly disappear. The reflex is to bring everything across, just in case. The result is a new system as untidy on day one as the old one, minus the familiarity that made the mess bearable.
The rule that works: migrate whatever you would have to account for in front of a patient. The rest gets archived, not carried over.
This comes with you:
- Core records: name, contact details, date of birth, home location
- Open obligations: paid but unused sessions, packages, gift cards, credit balances
- Live memberships with start date, price, payment method and cancellation status
- Treatment documentation to the depth your retention obligations require
- Consents with a timestamp, the channel, and the wording that was agreed to
This stays behind:
- Contacts with no activity for years. A dead address does not come alive by moving house.
- Duplicates. A system change is the best moment to clear them, and the only convenient one.
- Mailing lists that grew organically without documented consent
The last item on the first list is where this gets expensive. A consent record with no timestamp and no record of what was agreed to is not evidence in a dispute. Lose it in the move and you have quietly devalued your marketing list. What has to survive a migration is set out in our guide to GDPR-compliant patient communication.
In practice: export both sides, freeze the old system on a fixed date, and reconcile three numbers before go-live rather than after. Active patients, open prepaid sessions, live memberships. The second is the number a patient notices immediately if it is missing.
The realistic learning curve
Tell your team the truth about the pace before they discover it themselves. Day one is slower, the first week noticeably slower and full of questions. After that it settles step by step. Promise "it is simple, you will have it in an hour" and by day three you have a credibility problem on top of a software problem.
The curve is not the same for everyone. Reception has the steepest climb, because it touches almost the whole system. Practitioners are least affected, because they typically need three screens. The practice manager feels it latest and longest, because she has to rebuild her reporting and needs enough data in the new system first.
What works in training:
- Three short sessions across a week rather than one long block
- Practising on your own catalogue with your own prices, never on demo data
- The five most frequent actions recorded as short screen clips: create an appointment, move one, take a payment, log a package session, create a new patient
- One person drives, the other takes notes, then swap
- An open round at the end of each session: what did not work?
What does not work is training everyone on everything. Walking a practitioner through the reporting module costs her time and creates the exact impression you are trying to avoid. Train by role. The rest arrives when it is needed.
The parallel period, short and with an end date
Running two systems at once feels safe, and that is what makes it the most dangerous phase of the project. As long as the old system is reachable, everyone falls back to it under pressure and the learning curve restarts every morning.
- The calendar has exactly one system of record from day one. Double-booked appointments are the most common and most embarrassing damage a change does, and it always lands on the patient.
- The old system stays readable, not writable. Looking things up, yes. Entering things, no.
- Set a date, not a condition. "Once everyone feels confident" never arrives. A date in the calendar does.
- Two to three weeks is enough. After that you export, archive and close the access.
For the switch-over day itself: the quietest week you can find, a midweek day rather than a Monday, the champion plus one other person in the building all day, and deliberately fewer appointments. It costs revenue once and saves three weeks of bad atmosphere.
The sceptic at reception
Nearly every team has one, and she is usually one of the strongest people you have. Whoever knows the old system best has the most to lose in a change. The scepticism comes from two concrete worries: being slower, and looking unsure in front of a patient. Both are reasonable and both can be addressed.
- Early access before go-live. She should be allowed to try it and break it while nobody is watching.
- Collect objections in writing. Answer each one, dismiss none. A list of twelve points is something to work with. A bad feeling is not.
- Count instead of arguing. Take the most frequent task and count clicks and seconds, old system against new. Sometimes the old one wins, and then you know exactly where to push the vendor.
- Give her something back. A double entry that disappears. A printout nobody needs any more. One phone call fewer per day.
- Go-live must not be the first day she uses the system in front of a patient. A single dry run in an empty room removes most of the fear.
And the point that changes the most: some of her objections are simply correct. Write them down, pass them to the vendor, and report back. Nothing converts a sceptic faster than seeing her own objection fixed in the next release, and nothing hardens one faster than being told she will get used to it.
What to measure in week 1, month 1 and month 3
Each stage has its own question. Looking at revenue in week one measures the weather, not the software.
Week 1: is it running at all?
- How long a check-in takes, timed once in the morning and once in the afternoon
- Number of questions per day, counted by the champion
- Appointments entered wrongly or twice
- Payments that do not reconcile cleanly at the end of the day
- Three sentences per person at closing: what snagged today?
Month 1: is it being used?
- Share of appointments created in the new system
- Share of payments going through it
- How many staff actually logged in during the current week
- If there is a patient app, how many patients have registered
- How many processes still run in parallel on paper or in a spreadsheet
Month 3: is it doing anything?
- No-show rate compared with the same period last year. If that is where you want to push, it is worth reading what actually moves a clinic's no-show rate.
- Share of patients leaving the clinic with a follow-up booked
- Rebookings inside the recommended interval
- Memberships or packages signed
- Admin time per week, roughly estimated, but estimated by the same people as before
The most important line in this section: write down the starting numbers before you switch. Skip that and you will be comparing against memory in three months, and memory is always generous towards the old system.
A six-week rollout plan
Six weeks is a realistic frame for a single site. With several sites, roll out one after another. The first site learns on behalf of the rest.
| When | Who | What |
|---|---|---|
| Week minus 4 | Owner | Name the champion, block time in the rota, fix the go-live date and put it on the wall |
| Week minus 3 | Champion and vendor | Export data, agree the migration list, run a test import and reconcile the counts |
| Week minus 2 | Champion | Set up catalogue, prices, rooms, staff and opening hours in the new system |
| Week minus 1 | Whole team | Three training sessions, record the short clips, collect and answer objections |
| Week 0 | Everyone | Go live on a quiet Wednesday, old system read-only, appointment volume deliberately reduced |
| Weeks 1 to 2 | Champion | A ten-minute stand-up daily, clear open points, capture the week-one numbers |
| Week 3 | Owner | End the parallel period, export and archive the old system, close the access |
| Month 3 | Owner | Compare before and after, take the remaining irritations to the vendor as one list |
Frequently asked questions
How long does a rollout realistically take?
Budget roughly four weeks of preparation, a noticeably slower first week, and two to three weeks before daily work feels normal again. Reporting and automation come afterwards, once enough of your own data is in the system.
Should we take fewer appointments during the switch?
On go-live day and the day after, yes. Otherwise no. A lighter calendar for two days costs revenue once. A full calendar in the first week costs you the team's acceptance, and winning that back takes considerably longer.
What if the champion leaves?
That is why the champion writes things down. The clips, the agreed conventions and the open points belong somewhere other people can find them. A role that exists only in one person's head is a risk, not a role.
How much training does a practitioner really need?
Usually far less than reception. See the calendar, document a treatment, trigger a follow-up. A practitioner working confidently after twenty minutes is not a sign of shallow training. It is a sign that her access was scoped sensibly.