On the Salesforce Stack Exchange, a lot of moderation is performed directly by the community,
User adoption is a tricky thing, some organisations seem to adapt to change without so much as a blink of an eye, while others find that they have woes long outlasting the lifetime of the project that initiated them. Over the last couple of weeks I've been following an interesting discussion in a LinkedIn Group, and the question which generated such discourse was "Is Salesforce really working?". At first glance this may not seem like a question regarding user adoption directly, but the full question reveals all and the final line demonstrates the real problem:
Are sales users updating it because they have to or because they are getting value from it?
Developers sometimes talk about 'code smell', and although it encompasses many things it could be boiled down to simply knowing when something isn't quite right and code needs refactoring; either the parts don't fit together well and joining them requires excessive effort, or the parts have become overly complex and convoluted. When I read the sentence quoted above, my code smell alarm bell started ringing, with the phrase "because they have to", being the agitator.
Sometimes a system isn't a good fit for your business, and that does happen. But when you know a system works so well for so many businesses across so many industries, and you know it's flexible enough to build almost anything, then you have to start being introspective. If you question whether your users are using a system because it works for them or because they have to, then chances are it's the latter, and the reason it's not the former could probably be traced to a poor implementation or ineffective change management.
I'm not going to talk about bad implementations directly, but I do want to discuss three key areas which are vital to user adoption and effective use Salesforce, and for that matter, any other system.
Every Salesforce org I've ever touched has been unique (even freshly-minted Developer Editions change with each release, and they're all different within 30 seconds of me clicking things) and there's always a few intricacies that can catch you out, different workflow and validation rules for instance.
Regardless of whether your most recent project was a move to Salesforce, or an update to existing functionality in your org, you still need to provide your users with training. For brand new implementations you can't assume anything: related records are a mystery to many of those coming to the platform for the first time, object names may be unfamiliar, and small hover links to get help don't jump out at you.
When implementing Salesforce or simply adding new functionality to it, invest in comprehensive training for your users. You may even consider splitting them into different streams, as it's all too easy for those who know a little to get bored and then miss a key point as it is for those completely new to the system to be overwhelmed.
Skimping on training is not a good way to recoup the costs of a project that's run over budget, but it is a great way to ensure that the project will cost you even more in the months or years ahead.
2. User Champions
Not many people are fans of change, not least when that change is in a workplace where they're using tools they know (if not love) and have been doing so for a number of years. A CTO telling the users that this new system will cure all their woes will only go so far, and that can be a surprisingly short distance.
Some people however, embrace change. They get a thrill from it, or can simply see through the teething problems and know that the bigger picture looks a whole lot better than it did before; either way, they're your new ally in encouraging adoption. One thing we're all good at is taking advice from our peers, sometimes that advice may not be good advice of course, but even then we listen, and when it is good, we benefit.
Find that one person who gets it, and after a period of weeks or a few months, ask them to become your champion. I've seen this work brilliantly in the past when a client found a single user who loved both Salesforce and the mobile counterpart we built, and quickly created processes to make it work for them as a user. That person then presented to the entire sales team, demonstrating how they used the system throughout their day, why they did things a certain way, and explained the benefits they got from doing so. The change in perception of the benefits offered by the system was dramatic.
If you think you just implemented Salesforce and the project is complete, then I hope you're wrong. If you're not wrong then I wouldn't want to be one of your users. Both the champion you've found, and the users they've taught, will be able to tell you what works for them, and crucially they'll be able to tell you what doesn't.
This communication need not be verbal, for instance if you have a hunch your users are only using a system because they have to, and they're using alternative means to get the job done then you know it doesn't work for them. There should be no choice of systems, there should be one, and if you're users don't like that one system then it's up to you to fix it, because good morale is of utmost importance. Unhappy employees are not a boost to your bottom line.
Successful implementations are those that never stop: training is ongoing and reinforced regularly, and the system is adapted according to feedback from those that use it. When a platform such as Salesforce offers so much that you can customise, you have a responsibility to never stop refining it to meet the needs of your users. As a species we never stop evolving, and so why should the tools we use?
Happy Users, Happy Days
User adoption is a subject that will inspire discussion for a long time yet, and there is a lot I've not covered here such as gamification and the like, though I believe the points covered here are those that address the cause, rather than the symptoms of poorly-fitting system.
Training reinforcement and being on hand to provide advice is vital to a smooth operation, and it's one of the reasons we collaborated with a training company, Train The Crowd, to build CrowdGuide, an application that lets administrators define their own context-sensitive help for their Salesforce org. Rather than being limited to small, pop-up descriptions of fields it lets you reinforce processes and explain concepts using images and videos. When we were approached with the idea we knew straight away that it was something so many organisations could benefit from and so we didn't hesitate to get involved.
Discussion is imperative; listening to and talking to your users is the only way to make them successful, and facilitating discussion between them with tools such as Chatter, helps them help themselves. Remember: you can't tell your users to be happy, you have to make them happy, and by doing so you will provide an unparalleled service to your business.