The benchmark is done and the contract is signed. All that's left is to tell the team that, from Monday, everything goes through the new tool. Except that three months later, usage has stalled, the old spreadsheets are still doing the rounds and everyone has found a good reason to work around the system. The problem is almost never the tool. It's how the change was managed. Here's how to structure it so your teams genuinely get on board.
In B2B SaaS, things never stand still. A new CRM, a ticketing tool, a Customer Success Platform to roll out, a CSM team being split between onboarding and account management, a renewal process being overhauled... And that's normal: a growing company has to rethink its organisation and its tools on a regular basis.
The problem is that change management is often treated as a box-ticking exercise. An announcement email, a demo, a training session, and on to the next thing. Yet it's precisely during this phase, and above all before it, that a project succeeds or fails. An excellent tool that's poorly introduced will always underperform an average tool the team has made its own.
Without buy-in, the project is dead before it starts
I've seen this first-hand. When I was VP Operations, a customer asked us for more statistics on their support requests. A perfectly reasonable request. They discussed it with one of the co-founders, who set up Zendesk a few weeks later. He ran the benchmark on his own, configured the tool on his own, and then one day asked my team and me to switch over to it.
It never took.
Not because of the choice of tool. Because of the way it was done. We were presented with a fait accompli, and the rejection was immediate, from the team and from me (yes, the VP Ops was part of the problem!). We never really got past that point: adoption stayed poor for a long time.
In hindsight, the mechanism is fairly simple. When a tool people use every day arrives fully formed, the implicit message to the team is clear: your view on how you do your job doesn't count. The people who will use the tool day in, day out are precisely the ones who had no say.
There's also a well-known bias at play: the IKEA effect, our tendency to overvalue what we've built ourselves. The co-founder had chosen and configured the tool, so he was attached to it. We hadn't built anything. The attachment to the project was on the wrong side: with the person driving it, not with the people who had to make it work.
And a bad first impression is very hard to recover from. Once a tool is labelled 'the thing that was forced on us', every bug and every extra click becomes evidence for the prosecution. You don't get a second chance to launch a tool.
What the numbers say
Consultancy Prosci has been tracking the link between the quality of change management and the achievement of objectives for years. Among respondents with excellent change management, 88% met or exceeded their objectives, compared with just 13% of those whose change management was poor. In other words, a well-supported project is roughly seven times more likely to hit its objectives. It's a self-reported correlation, but the gap is wide enough to give pause.
Another, more worrying finding: your teams are tired of change. According to a Gartner survey reported in Harvard Business Review, the average employee experienced 10 planned changes in 2022, up from 2 in 2016, and the share of employees willing to support those changes fell from 74% to 43% over the same period.
Apply that to a growing SaaS business: new segmentation in Q1, new CRM in Q2, new pricing in Q3... Your project never lands on a blank slate. It lands on a team that has already absorbed several changes and has learnt to wait for things to blow over.
Prepare the ground before you announce anything
Change management doesn't start at launch. It starts the moment you identify the problem to solve. That's counter-intuitive, because it's precisely when you least want to spend time consulting people. Yet it's where everything is decided.
Start with the problem, not the solution
Before talking about tools or org charts, lay out the problem. What isn't working today? For whom? What is it costing, in time, customers and revenue? How will we know it's solved?
A team that shares the diagnosis accepts the solution far more readily, because they see it as the answer to a problem they recognise. Conversely, a solution that arrives without a shared problem always looks like a whim handed down from above. And you may discover along the way that the real problem wasn't the one you had in mind.
Involve the people who will live with the change
In practice, bring two or three key users into the benchmark, have them test the shortlisted solutions, and run a pilot on a limited scope before rolling out more widely. These people will become your best advocates: when a colleague grumbles, it's a peer who answers, not management.
Gartner backs this approach with what it calls an 'open-source' change strategy. According to Gartner, organisations that apply it are 14 times more likely to succeed with change, see the risk of change fatigue fall by 29 points and intent to stay rise by up to 19 points.
Be careful, though: involving people doesn't mean putting everything to a vote. Gartner is clear on this: it isn't a democracy where everyone votes on every change, but a meritocracy where the best ideas win, wherever they come from. You keep the final decision, but you make it with the right information and you explain how you reached it.
Get leadership on board (or win them over)
There are two scenarios. If the change comes from the top, leadership must be visible and consistent: they explain the why, protect the time needed for adoption and, above all, use the new tool or process themselves. A CEO who keeps asking for figures from the old Excel file can undo weeks of effort in a single meeting. Prosci finds that projects with extremely effective sponsors meet their objectives 79% of the time, compared with 27% for those with extremely ineffective sponsors.
If the change comes from you, it's the other way round: you have to sell it. Put a figure on the problem, show what the change frees up, and ask explicitly for what you need, budget AND time to support the roll-out. This is where doing the work is not enough: you also have to make sure it's seen. A leadership team that hasn't grasped what's at stake will drop you at the first difficult trade-off. You can count on it.
Spell out what changes, what doesn't... and what stops
Formalise the 'before and after' for each role affected. What changes in their day-to-day work, what stays the same (that's reassuring, so say it!) and, an often overlooked point, what they will stop doing. A change that adds work without taking any away is a change people will work around. If the new tool means double data entry for three months, anticipate it and say so.
Think about timing too. Launching a new tool in the middle of renewal season or at quarter end is a guarantee it will drop to the bottom of everyone's priorities.
Support the roll-out
A kick-off isn't change management. It's a starting point. Adoption is built in the weeks that follow, through repetition and consistency. Hence the importance of short rituals set up from day one:
- A 15-minute weekly check-in during the first few weeks, to surface what's blocking and what's working.
- Go-to people within the team, clearly identified and available for everyday questions.
- A monthly adoption review, backed by usage data.
- Retrospectives at 30, 60 and 90 days, to agree on adjustments together.
OKRs are also a useful lever, provided they're built intelligently. The classic mistake is setting a usage objective ('100% of the team logged into the tool'). A usage objective measures compliance, not value. It's better to anchor the objective in the expected outcome, and treat usage as one means among others.
Take the roll-out of a Customer Success Platform and a health score. Here's what it might look like (fictional example):
- Objective: spot at-risk accounts earlier so churn no longer catches you off guard.
- KR1: 100% of accounts tracked with a health score by the end of the quarter.
- KR2: every account that moves into the red triggers a CSM action within 7 days.
And the best way to make these objectives motivating is still to involve the team in setting them. A target you've set yourself is far easier to stand behind than one you've been handed.
One last, often neglected point: set an end date for the old system and announce it in advance. Not too early, or you'll create panic, and not too late. As long as the old file or process is still available, it remains the most comfortable option. Habit wins by default every time.
Keep your ears wide open
Many leaders are convinced they've brought their teams along. The teams often see it differently. One figure regularly cited in studies on the subject illustrates the gap: according to ChangingPoint, 74% of leaders say they involved employees in shaping the change strategy, but only 42% of employees feel included.
The only way to close that gap is to go looking for feedback rather than waiting for it to come to you. Several channels complement each other:
- A dedicated channel (Slack, Teams) for questions and frustrations, unfiltered.
- Manager 1:1s, with a standing question on the new process.
- Usage data, which shows who uses what and, above all, who is dropping off.
- Informal conversations: 30 minutes over coffee with a colleague will teach you more than a survey.
And change how you view resistance. The people who grumble are often those who care most about doing their job well. Resistance is information, not a personality problem. It tells you where the process doesn't fit reality on the ground, where training fell short, or where the tool has complicated something that used to be simple.
Be wary of silence instead. A team that raises nothing isn't necessarily a team that's convinced. Sometimes it's a team that has quietly decided to work around the system. Until the day you find out.
Iterate to prove it's a joint effort
Listening isn't enough. If feedback disappears into a black hole, you'll get the opposite of what you wanted: the team will conclude the consultation was just for show and stop playing along.
Close the loop, every time. 'You told us the account view was hard to read, so here's what we've changed.' A simple changelog, shared every two weeks, is often enough. It shows the set-up is evolving thanks to its users, and it gives credit to those who contributed.
To make this iteration possible, start simple, then build out once the foundations are solid. A 'big bang' roll-out with every module, every automation and every custom field from day one leaves no room for adjustment. And it overwhelms the teams.
Prioritise the small frustrations raised by people on the ground. A pointless field removed, a shortcut added, a process step simplified: these quick wins cost little and prove the listening is real. And when you turn a request down, explain why. A reasoned 'no' builds far more trust than a request left unanswered.
Finally, remember that iteration isn't only about the tool. Sometimes it's the process itself that needs rethinking, or even the organisation. If three pieces of feedback all say the new split between onboarding and CSMs is letting things fall through the cracks, that's not a configuration problem.
The mistakes that kill buy-in
A few pitfalls come up again and again, whatever the nature of the change:
- Confusing training with adoption. Training shows people how; it doesn't make them want to. Without the why, training is forgotten within a fortnight.
- Forgetting middle managers. They carry the message day to day. If they're not convinced, their teams will sense it immediately.
- Measuring logins rather than meaningful use. A user who logs in to tick a box hasn't adopted the tool.
- Stacking changes. If three projects land in the same quarter, prioritise and sequence them. Your teams can only absorb so much.
- Declaring victory too early. Adoption is measured at six months, not at the end of the first week.
Conclusion
If you remember one thing, make it this: change management starts before you choose the solution, not after. The time you think you're saving by deciding alone, you'll lose tenfold in failed adoption, workarounds and energy spent convincing people after the fact. So take that time upfront. Your teams will repay you!
Further reading:
