By Dave Salciccioli, Co-Founder and CEO, Relay.
Most technology rollouts are decided before go-live. By the time the kickoff call is on the calendar, the things that determine whether a tool gets adopted are either in place or they aren't, and very few of them have anything to do with the software.
In the DSO board meetings, L10 meetings, and quarterly business reviews I sit in, the conversation about a new platform usually runs through the vendor, the price, and the go-live date. All three matter. What gets far less airtime is what the group itself needs to have ready, and that's where I'd spend the time. We all want what these tools can do. It's the transition that needs a plan.
Here are ten things I'd want established before the first location goes live.
1. The operational result you're buying
"Go live by March 1" is a date. It isn't an outcome. Before anything gets scheduled, the leadership team should be able to write one sentence that says which number moves, at which locations, and by when, in the terms the business already tracks: case acceptance, days in AR, hygiene reappointment, production per hour.
That sentence does a lot of work. It tells the vendor what you're really solving for, it gives the team a reason beyond "corporate bought something," and it gives you something to measure against six months from now. I'd also hold it up against what I call the triple win, which asks whether this is a win for the business, for the people on the team who have to use it, and for patients.
If the group can't agree on that sentence, pause there. The wrong tool implemented perfectly is still the wrong tool, and no rollout plan will fix a selection that wasn't clear on the problem.
2. A baseline you trust
Once the outcome is clear, capture where you are today, location by location. Pull the metric you're trying to move and write down how the work gets done right now, because the gap between your best office and your worst one is usually where the opportunity sits. Without a baseline, the six-month review turns into a debate about anecdotes.
3. A clear picture of your tech stack before you buy
We have an evaluation problem in dentistry. Too many purchases get made on a strong demo or a peer's recommendation, before anyone has looked hard at what the group already owns. A 40-location group can be running 10 or 15 separate systems. Often a tool already in the stack does much of what the new one promises, or nobody can say whether the current tools are producing real outcomes.
So before you buy, get clear on four things about what you have today:
- Usage: what's actually being used, by whom, and where
- Cost: what each system costs, when contracts end, and where you're paying twice
- Readiness: how much change the team can take on right now
- Gaps: where the real gaps are across the RCM, Patient, and Clinical journeys
This is the work we do at Relay with our Tech Stack Diagnosis, and the answer isn't always a new purchase. One group we worked with was far down the path to a new PMS. After looking at the full picture, the group stayed on its current system, renegotiated the contract, and saved hundreds of thousands of dollars. The savings mattered, but the bigger win was avoiding the opportunity cost of a platform switch the team didn't need to live through.
When a switch is the right call, plan for it as a switch. There's a contract end date, a data migration, a cutover weekend, and a vendor on the way out. Build those costs in up front and give the outgoing vendor ample notice. At the end of the day, you want to treat people well.
4. Your data supply chain
Thomas Terronez, founder and CEO of Medix Dental IT, talks about a DSO's "data supply chain," and I've borrowed the phrase because it describes the problem so well. Every number a group runs on starts with a person, usually someone at the front desk or chairside entering it, and then moves through the PMS into other systems, reports, and dashboards before it reaches whoever is making a decision with it.
Before adding a tool, map that chain for the data it will touch:
- Where it starts: who enters it, and at what point in the visit
- Where it lives: which system is the official record
- How it moves: through an integration, an export, or by hand
- Who uses it: which roles and reports depend on it
- Who owns it: who's accountable for keeping it accurate
A new tool plugs into this chain somewhere, either pulling data out or creating more of it. If nobody has mapped the chain ahead of time, the group learns where it breaks after go-live, when the reports don't match and the team stops trusting the dashboard. That matters even more with AI products, which are only as good as the data feeding them.
5. Clear and documented processes
Technology runs on top of process. If the way you verify insurance, present treatment, or follow up on unscheduled care lives in the heads of your best office managers, the new tool has nothing consistent to sit on, and every location will end up configuring and using it their own way.
So write down the core processes the tool will touch before the rollout starts: the steps, who does each one, and what done looks like. These don't need to be long. A page that a new hire could follow in their second week is the bar.
I think of this as fool-proofing success, and I mean that as respect for the team. Results shouldn't depend on who happens to be working that day. Documenting the process also shows you where locations differ today, and it gives the vendor something real to configure to instead of their defaults.
6. One owner with the authority and the time
Most DSOs don't have a dedicated implementation function, and that's a fair decision for an operating company to make. What it means in practice is that the rollout lands on a regional manager or a director of operations who's already running practices full time.
So name the owner before kickoff, and be honest about what comes off their plate to make room. That person needs the authority to make workflow decisions across locations and an executive sponsor who'll back those decisions when they get uncomfortable.
Around the owner, I'd put a small cross-functional group in place: operations, clinical, RCM, IT, at least one doctor, and at least one office manager. Doctors and teams both judge a tool on how it was rolled out, so both need a voice in how it's rolled out.
7. How the work will change, role by role
Training teaches people where to click. Adoption happens when the workflow changes, and that has to be designed before anyone logs in.
For each role the tool touches, I'd want three things written down: what they stop doing, what they start doing, and who decides when something doesn't fit. That includes the front desk, the treatment coordinator, the hygienist, the office manager, and the doctor. It also means deciding what's standard across every location and where a practice is allowed to do it their own way.
This is why operations come first. A fancier car doesn't make you a better driver, and a new platform dropped onto an unclear workflow will give you the same variance you had before, with a new login.
8. A shared plan with the vendor
A rollout is a shared job, not a handoff. Vendors are built to sell software and activate accounts, and most aren't staffed for change management across dozens of locations. That's how the commercial model works, and it means the two sides need to agree on who carries what before the contract is signed.
A few things I'd get in writing:
- Handoff: what was promised in the sale, and whether implementation knows it
- Timeline: dates for the pilot and each wave, and who can change them
- Enterprise readiness: cross-location reporting, role-based access, and fit with your stack
- Support: how long hypercare runs, who's on it, and what happens after
Strong implementation is ROI, and the vendors worth partnering with are honest and clear about how they'll deploy with you.
9. Room on the team's plate
Before picking a go-live date, look at what else the team is absorbing that quarter. An acquisition being integrated, two other pilots, a staffing gap at four locations. Every one of those draws from the same pool of attention, and a rollout stacked on top of them often gets whatever's left.
A rollout also draws on the team's goodwill. Each one that fizzles makes the team more skeptical of the next recommendation, so the sequencing matters as much as the software. Choose pilot locations on purpose, learn from them, and then move in waves the owner can really support.
The people side has to be planned with the same care as the configuration. In the 2023 edition of its Best Practices in Change Management study, the research and training firm Prosci found that projects with excellent change management were about seven times more likely to meet or exceed their objectives than those with poor change management (88% versus 13%). In a dental office, that starts with something simple, which is the team hearing why this is happening from their own leader well before the training invite shows up.
10. How you'll know it's adopted
Activated and adopted are different things. Logins, completed training, and a deployment marked complete tell you the account is live. They don't tell you the work has changed.
Decide ahead of time what adoption looks like for each role and how you'll see it, then put the review on a calendar that already exists. A standing item in the L10 at 30, 60, and 90 days works well, with the owner reporting by location against the baseline. Agree now on what happens when a location slips, so the response is support and not a surprise.
I'd pay particular attention around day 90. When the support tickets go quiet, it's tempting to read that as a good sign, and it often means the team went back to the old way.
The work before the work
None of these ten is exciting, and none of them shows up in a demo. They're unglamorous work, and in my experience they do more to decide whether a group gets what it paid for than anything that happens on go-live day.
If you're heading into a rollout and want to talk through any of them, shoot me a message.
Before your next purchase, Relay's Tech Stack Diagnosis maps what your group is actually using, what it's paying for, and where the real gaps are across the RCM, Patient, and Clinical journeys.