Choosing clinic software is a decision. Going live with it is an operation, and it is the part that determines whether the decision looks good six months later. Practices that struggle usually did not pick the wrong product. They picked a reasonable one and then switched to it on a Monday in December with no plan for the first hour.
This is a checklist for the fortnight around go live: what to settle before, what to do on the day, and what to watch in the weeks after. It assumes the data migration is a separate piece of work already in hand.
Choosing the date
The date does more work than any other decision here, and it is usually chosen by when the contract starts rather than by when the clinic can absorb it.
Avoid your busiest weeks, obviously, but also avoid the quietest. A clinic with three patients a day does not exercise the system enough to find problems, and staff build confidence from repetition rather than from calm. A normal week is the right week.
Avoid going live when any key person is away, and that includes the person who is quickest with computers regardless of their job title. Every practice has one, and their absence in week one is felt disproportionately.
Pick a day early in the week. Going live on a Friday means any problem sits unresolved over the weekend and staff return having lost the thread. Tuesday is often better than Monday, because Monday carries whatever the weekend generated.
The fortnight before
| Task | Why it belongs before rather than during |
|---|---|
| Set treatment types, payment modes, appointment durations | Configured under pressure becomes permanent by accident |
| Create every user account with its own login | Shared logins created on day one are never undone |
| Enter appointments already booked beyond the date | The calendar has to be complete on the morning itself |
| Decide who arbitrates when old and new disagree | Inconsistent answers are what erode trust in the data |
| Agree what still gets written on paper, and where | Staff will write things down; give them a temporary place |
| Identify the first person to call when something breaks | Finding out during the incident wastes the worst hour |
The third row is the one that causes visible failure if skipped. A clinic that goes live with an empty forward calendar has patients arriving who are not expected, which is the single worst first impression the system can make on the team.
Enter those forward appointments with one person rather than sharing the task. Two people working the same list create duplicate bookings, and duplicates are harder to notice than omissions because both entries look correct.
Training that survives the first week
Most clinic software training happens once, a few days before go live, covers everything, and is forgotten by Tuesday.
A better shape is two shorter sessions. The first, before go live, covers only what each person does in their first hour: for reception, finding a patient, booking, taking a payment. Nothing else. The second, about a week in, covers the rest, once people have questions arising from real use rather than hypothetical ones.
Train by role rather than as a group where you can. A dentist and a receptionist need different things, and a combined session spends half its time on material each of them will not use. Where roles are defined in the system, training to the role rather than to the software is straightforward.
Write down the five sequences each role performs most often, in order, as a single page. Not a manual. A page. This is the artefact people actually use in week one, and it is also what you hand to the next person you hire.
Expect to repeat yourself. Someone will ask on Thursday the thing you covered on Monday, and that is normal rather than a sign the training failed. Retention comes from doing, not from being told.
The day itself
Go live day has a shape worth planning to.
Start earlier than usual. Half an hour before the first patient, with everyone logged in and the day's list visible on screen, removes the scramble that otherwise colours the whole morning.
Reduce the list if you can. Not dramatically, but a day with a little slack absorbs the extra minutes each task takes when it is unfamiliar. A full day on go live means running late by eleven, which is when people revert to paper.
Have the old system available and read only. Staff will check it. Letting them check it, and finding that it agrees, is how trust gets built. Forbidding it produces anxiety and shadow records.
Keep a written list of everything that goes wrong, including trivial things. Not for blame, but because the same handful of issues will recur and each has a one time fix. Clinics that solve the same problem eleven times are the ones that never wrote it down the first time.
Do not tell patients. A system change is invisible from outside if it goes well, and announcing it only invites questions staff have to field while learning the system themselves.
The first month
Three checkpoints are worth scheduling rather than leaving to chance.
End of week one. Fifteen minutes with the team. What is slower than it was, what is missing, what is being worked around. The last question matters most and needs asking directly, because workarounds are invisible unless someone volunteers them.
End of week three. Look at the data rather than the feelings. Are appointments being recorded with the right types. Are payments going in on the day. Are there duplicate patients. Three weeks is early enough to correct habits before they set.
End of month one. Decide the date the old system goes read only for good, and whether any configuration needs changing now that you have seen it used. This is the moment when changes are cheap and informed, which is a combination that does not last.
Tell the team what you are watching and what you found. A changeover where staff report problems into silence becomes a changeover where staff stop reporting problems. Five minutes at the end of week one saying which three things are being fixed does more for adoption than any amount of training.
Resist adding features during this period. The temptation to switch on reminders, reporting and everything else in week two is strong and usually a mistake. Let the core become routine first. A clinic that is still uncertain about booking does not need a new module.
Who runs the changeover
Implementations drift when they belong to everyone. Somebody has to own the fortnight, and in a small practice it is rarely obvious who.
It should not default to the owner if the owner is treating patients that week. Attention is the resource in shortest supply during a changeover, and a dentist between appointments cannot give it. It equally should not be the most junior person, however capable, because half the job is making decisions about how the clinic will work.
The practice manager is the natural holder where one exists. Where one does not, the best arrangement is usually the senior receptionist for operational questions with the owner available for decisions, agreed explicitly rather than assumed. The distinction matters: one person runs it, another settles anything that changes how the clinic operates.
Give that person authority to reduce the patient list, to decide what waits until next month, and to say that something is not working. An implementation owner who can only escalate is a coordinator, and coordination is not what the fortnight needs.
Agree in advance what would cause you to pause. Not abandon, pause. If the calendar is unreliable, or patient records cannot be found at the desk, continuing on momentum makes things worse. Naming the threshold beforehand makes the decision calm rather than fraught, and in practice it is almost never invoked, which is the point.
Signs it is going wrong, and what they mean
Four early signals are worth knowing, because each has a specific remedy rather than requiring general concern.
Staff are keeping parallel paper notes after week two. This means something they need is genuinely missing or hard to find. It is information, not disobedience, and the fix is to ask what they are writing down.
One person is doing all the data entry. The team has not adopted the system, they have delegated it. That person becomes a bottleneck and the clinic has recreated its dependence on one individual.
The same question keeps being asked. The answer is a one page note, not more training.
Nobody is using the reports. Either the numbers are not trusted yet, which is reasonable early on, or nobody agreed what would be looked at. The second is fixable in a conversation.
If you want to see what the first week actually looks like on a working system, the overview of what changes day to day is the practical version, and you can book a demo to plan the sequence against your own clinic.
