Tips for user adoption
Updated: Jul 1, 2020
We all know that one of the big bugbears of any changes you make as an Admin or Developer is getting users to like it. Here are some of the main tips for making sure you really get across to your users why changes will help them.
Your Admins and Devs have been working hard to produce a platform that’ll make your sales reps and users more efficient to increase sales. Before anybody can get their hands on the system, it’s important that they’re properly trained, so they can understand how to use the changes as well as understand what’s different and exactly why the change was needed.
Within the training of teams, you might want to create some exercises to make it more engaging and less of a “this is what’s happening, tough luck” approach. Make sure these exercises are appropriate for each team you train, as different areas of the business might be using Salesforce in a different way.
When you’re training users, whether this is on a new Salesforce org, or on some changes within a current one, users can get quite tired as there is usually a lot to take in. You need to make sure that breaks are used to allow trainees to get the most of the session.
Train the trainer
You’ll also need to choose who’s going to be training. You might have multiple Admins/Devs or even some super-users who’ll be going away to teach these users. One approach to training is a ‘train the trainer’ approach. This means the admins and people who are very familiar with the system will train some key users of the system.
These users will then go away and train the rest of the team. This can sometimes be a better approach because usually the users will be more comfortable with these key users, so feedback will come more easily.
If you’re just making changes in the system, it might be worth getting some opinions on where training should be given in other areas of the system, which don’t necessarily relate to the change in hand. This can be used as a refresher to the team to help them understand the capabilities of Salesforce and make their job easier.
The rollout can be done in a few different approaches, and one that is recommended is giving access to some key users within the company. These key users can then get their hands on it to see how it handles normal, day to day operational use. This can then be rolled out to other teams in the business.
For example, say you’ve changed the fields on the opportunity object and want to let some key ‘super-users’ test it out and give any initial feedback before rolling it out to different areas of the team.
In the early stages of the rollout, it's best to take things slow — allow time for users to get used to the new system. They will more than likely struggle to navigate, and whoever deals with internal cases/questions will be getting a lot of enquiries.
Be aware there might be a lot of errors as well. When users get their hands on things, they usually find things you didn’t when initially testing. There will probably be some permissions errors where users get too much/little access to areas of Salesforce. At this stage, it is up to the implementations team to keep everybody happy and get them all through this learning curve.