.jpg)
No one likes change.
Okay, maybe a few weirdos thrive on change and challenge, and the majority of us are concentrated in operations roles.
But the people we support are often averse to change. Your carefully crafted CRM is not where they want to be spending their time, and they, more often than not, view it as something that steals time away from their real jobs. Like selling more product.
It’s not a completely unfounded stance, but you work hard to improve their experience so they can stop looking at a CRM as a hindrance and start viewing it as something that helps them do their job.
You can take steps to ensure they are aware of the benefits and that leadership backs the impending change.
Ideally, before you even start your project, you've done some work to establish your project's benefits and opportunity costs. Steps you can take to quantify the impact of your project can be found here.
Why go through the effort?
When you have actual numbers (# of hours saved, $ that is lost, etc.), leadership is more apt to buy into disrupting their workforce with change. And psychology shows us that employees are more likely to adopt processes if they know there's a benefit.
Weigh for yourself which statement is more compelling:
“We’re overhauling the opportunity page layout and process to make things more efficient for sales.”
“By overhauling the opportunity page layout and process, salespeople will save 40% of the time they previously spent on Salesforce opportunity maintenance.”
Once you have your costs and benefits, it’s time to sell the leadership team.
Getting leadership buy-in is less about the benefits you reap with their blessing and more about the havoc a rebellious manager can cause for user adoption.
A team that knows their manager thinks these changes are a waste of time has sufficient cause to get away with using a Google spreadsheet or some other nightmarish system to keep track of their deals.
If you can't get every leader on the teams you support to approve of the change, you can move up the food chain and recruit upper management to push down the change. However, provided you have a solid benefit statement, this shouldn't be a problem.
Before you roll out any functionality to a team, you need to test to make sure it works flawlessly. Think outside of the box and skip steps and go backward in the process. Do everything you can to mimic someone who doesn’t like or listen to rules.
Your goal is to try to break your new design so you can make sure it’s bulletproof when it goes live.
Recruit people on your team who can test in a sandbox to try to break the process. Don't explain anything to them and see where they get stuck. Then have them walk through a test script.
Write a testing script with step-by-step instructions to walk through different scenarios. Using a spreadsheet with the following fields can be very helpful:
I’ve found that turning around my most vocal detractors has been the biggest lift to adoption. If I can get someone who ripped apart something on a department-wide call to review the new change, understand how it benefits them, and express gratitude for the change, I know they’ll tell other team members that I’m on their side and fighting the good fight to make their lives easier.
People gossip and complain to one another. When people promote your work, they’re endorsing the adoption of the new process and paving the way for a smoother transition.
I mentioned that part of the process of recruiting champions involves giving them a sneak peek. So do one better and convince them to try the change out for themselves in the sandbox.
Give them a very abbreviated version of the test script.
The point of user acceptance testing is two-fold. First, you get feedback on potential deal-breakers that could prevent adoption. Second, your champion feels they had a significant role in the process and feels a little bit of ownership in what happens once the change is rolled out.
End-users hate to be surprised by changes to a process they’ve gotten used to, even if they don’t particularly care for the process. By communicating the reason for the change, the benefits they can expect to see, and the go-live date far in advance, you’re mentally preparing them for change.
If you have kids, you’ll know that the best strategy for avoiding a meltdown is to give them plenty of warning before it’s time to stop any activity. And communicate it often.
“We can only stay for 30 minutes.”
“We have 20 minutes left.”
“We need to leave in 10 minutes.”
“You have five minutes, and then we have to pack up.”
Does it seem overly repetitive? Absolutely. But if it reduces the tantrums by 50% or even 30%, I’m going to overcommunicating as part of my toolkit.
I’m not saying the teams we support are full of children. I am saying that the same psychology applies to adults who change-averse. Letting them know it’s coming far in advance lessens the chance that you have an irate person waiting at your desk when you get into the office on Monday.
Keep the communications as short as possible, put the benefits at the top, and use bullet points where applicable. It would be best to recruit some of your stakeholders to either piggyback on your communication or send out their own before launch.
Asia Corbett, Director of Revenue Operations at Postal.io:
“Set up a cadence for communication of your work to your stakeholders and end-users. It can be email, slack, or meetings. For business process changes, start communicating about it EARLY. 1) Email at the project kick-off 2) Email when a major milestone is completed 3) Email 1 week before go-live 4) Email on go-live. On go-live day - it's probably beneficial to have a quick presentation with a few slides of the BEFORE vs. AFTER process change. Over-communication here is the key.”
Before your changes go live, think through key metrics that indicate success. Is it fewer opportunities left in open status with a close date in the past? Is it a higher case resolution rate? Is it fewer campaign members associated with the incorrect campaign?
Try to define 3-5 metrics because chances are you won't see improvement in every category. Expect a slight lift, and be sure to communicate your expectations about progress before communicating your goals to the leadership team. Create a private dashboard and prepare to monitor it often in the first few weeks or months of deployment.
For major process changes, you’ll want to deploy the changes over a weekend to give yourself (and hopefully a team member or two) time to test the updates. Have test scripts ready to make sure that everything works in production as well as it works in your sandbox.
Once you’re done, send a final communication to the people impacted by your changes to let them know it’s live, how to reach you if there’s an issue, and what information they should give you if they spot a problem. Encourage them to send you screenshots and URLs to make troubleshooting as fast as possible.
Once your changes are deployed, you’ve communicated a ton, and you’ve worked through the initial firestorm of system issue reports, it’s time to monitor whether people are using the process. This should include monitoring your wins dashboard created in step seven.
If you see a win worth celebrating, share it with the stakeholders and treat yourself to something nice.
Thank you to our community partner Postal.io and Asia Corbett for inspiring this post.
