Rolling Out New Systems: changes your people will actually use

You've decided on a new system or a new way of working. Now it has to become how the work gets done.

Articles The overview Questions

A person in a cream cardigan turns a large brass key in a lock set into a garden wall, while a row of glowing lanterns along the wall grows fainter into the distance.

Getting a new system or way of working into daily use

You know what needs to change. Maybe it came out of a redesign, or maybe it has sat on the list for a year. The plan exists. The new system is bought and set up, or the new way of working has been decided and announced. And the old way keeps winning.

You have probably seen what that looks like. The booking link went out, and clients still text you to book. The new CRM has every client in it, and the team still keeps its own spreadsheet on the side. The new process is written up in a document nobody has opened since the meeting where it was announced. Nobody said no to the change. It just never became anyone's job to make it happen.

A new system is finished when people use it

Buying the software or writing the new process is the part you can point to, so it is easy to treat it as the end. It is closer to the start. A system changes nothing while people work around it. The change lives in what people do on an ordinary Tuesday, and getting there is a piece of work of its own.

That holds whatever you're changing. It might be one new tool, like a CRM or a booking system, already chosen. It might be a new way of working with no software in it at all. Or it might be a whole list of changes that came out of a redesign. Each rolls out a little differently. In all three, people have to stop doing one thing and start doing another.

So treat the rollout as a project. It needs a plan, an owner, training, and someone to answer questions afterward. Skip those, and you have paid for a new system and kept the old way.

An implementation plan turns a list of changes into work someone owns

If the change came out of strategy or redesign work, you probably have a list. A new website, a new way of taking bookings, a new place for client records, new steps behind the scenes. That list says what to build. It doesn't say how any of it gets built, or by whom.

An implementation plan does. It starts where the strategy stops, and gives each change on the list what someone needs to pick it up and finish it, including who that someone is. That last part is the hardest to fill in, and it decides whether anything else on the page happens. For turning that list into finished work, there's our article You have the new plan. Now who implements it?

Getting people to use a new system is the hard part

Setup is the visible part. People changing how they work is the hard part, and it is where a rollout succeeds or stalls.

If you've been reading about change management or staff buy-in, this is what those terms point at. In a small business it needs no program and no new vocabulary. It needs the people affected to believe the change is worth what it costs them while they learn. Plain words do more than any framework. Tell people what's changing, what it means for their own day, and why it's worth the bother, the way you'd explain it to one person at their desk.

It helps to see it from their side. A team that keeps the old way usually isn't being difficult. They have today's work to get through, and the new system slows them down before it speeds anything up. That gives the rollout its order.

The order follows the path people take through a change: the reason first, then how it goes live, then training, then someone to ask once it's running. That's also why a rollout tends to go in stages instead of all at once, and why one round of training is rarely enough. To get the old way to stop running beside the new one, start with How to introduce a new system to your team so they actually use it.

Changing a way of working takes a few extra steps

Some changes involve no new software at all. It might be a new way of handing work between people, a new rhythm for updates, or people working from different places. People still need to know why it's changing and who to ask.

What's different is that nothing gets switched off. You can retire an old tool. You can't uninstall a habit. So the rollout has to suit how your team works today, take on one problem at a time, and bring the rules people work by into line with the new way.

If you need the new way to hold up when everyone's busy, follow how to roll out a new process to your team so it sticks.

Give every new system an owner so it sticks

Even a well-run rollout fades. Launch day passes, attention moves to the next thing, and small workarounds creep back in. Nobody decides to go back to the old way. It just happens one shortcut at a time.

Drift is easy to miss, because the system still looks in use. People log in, and records still get added. What matters is whether it does the job you brought it in for, or only the parts somebody checks.

It usually starts in the stretch right after launch, when people hit the questions training didn't cover. With no one to answer them, each person finds a fix of their own, and before long those fixes are the real process. The cost shows up slowly. Reports stop matching what happened, people ask each other where things are, and the system you paid for takes the blame for the habits around it.

Once the rollout is over, the system needs an owner on your side. That is one person whose job includes keeping the system in use, spotting the workarounds, and changing how it's done when the work changes. It also helps to record how your business uses the system, so it doesn't depend on anyone's memory. Processes and SOPs covers keeping that record current and in use.

A rollout needs someone whose job it is

If nobody's job includes the rollout, it waits behind everyone's real work. It needs someone whose job it is, whether that is one of your people with room made for it or outside help. Who that should be is its own decision, and Outsourcing and Delegating covers it.

Start with whatever is still undecided

Still deciding what the business should be? That's Christina's business design work.

The day your people stop working around the new system is the day it starts earning its keep. Sparkitive can run the rollout for you, with your team in it wherever you want them. Which change is next, and who does it touch? Christina's free 30-minute discovery call is a good place to lay it out.

Book a discovery call

Questions about rolling out new systems

When is a new system finished?

When people use it on an ordinary day without being reminded. Buying it and setting it up come first, and they're closer to the start than the end. Until the old way stops winning, the rollout is still a piece of work, and it needs someone to see it through. To get your people there, read How to introduce a new system to your team so they actually use it.

Is changing how people work different from bringing in a new tool?

Partly. People still need the reason and someone to ask. The difference is that the old way never switches off, so the new one has to become what people reach for without thinking. How to roll out a new process to your team so it sticks gives you the steps, in order.

Who should run the rollout of a new system?

Someone whose job includes it, with room made for it. That can be one of your own people or outside help. If nobody's job includes the rollout, it waits behind everyone's real work. Once it's live, one person on your side keeps it in use. For putting a name next to every change, see You have the new plan. Now who implements it?

A glowing firefly carries a sealed letter through the night sky

Get The Spark Post, Sparkitive's newsletter

Practical strategies for the big projects, the run of small ones, the processes worth rebuilding, and the work you'd rather pass on, plus the occasional magical blueprint, delivered to your inbox with a spark. You can unsubscribe at any time.

Privacy and terms

You're on the list. Thanks for joining.