“Can’t wait to use Salesforce today!” – No one ever
What is the the most dreaded word in any Salesforce implementation? The one that jumps into my mind almost immediately is adoption (*GASP*). People spend so much time talking about RFPs, business requirements, implementation timelines and goals/metrics that they often forget about the end-user who is actually going to be using Salesforce on a day-to-day basis. All the license types and app clouds in the world aren’t going to replace a well-designed system that’s not a pain to use.
The good news is, Salesforce has drastically improved it’s UI (Lightning), is helping you do more with less data (Einstein), and continues to improve automation tools. It’s going to get easier and easier to use the system. However, it’s important to be very intentional in how you design the system- adoption is not a by-product, it’s a priority.
In my experience, companies try to go for way too much at once, especially during initial implementation. The reason is obviously complicated, but there are two big factors at play. One, after being promised everything under the sun by their Salesforce exec, leaders sponsoring implementation are often looking to get their implementation to be revolutionary. Second, the consultants leading these implementations are interested in impressing their customers with all the bells and whistles, so they’re happy to say yes to as many requests as they can.
The end result is often a bloated system that sounds incredible on paper and is avoided like the plague by many uses. “If it’s not in Salesforce, then it doesn’t exist” makes for a great sound-bite, but it’s not the most effective rallying cry. The end-user is ultimately the most important stakeholder in your Salesforce org, because they’re the ones capturing all the info- make them your priority.
Effective adoption is a complicated topic, so I’m going to highlight two important factors to keep in mind when you’re implementing or configuring your Salesforce instance. I’ve put some resources related to these factors next to them, as well another resource at the bottom.
1. An iterative design and implementation process that focuses first and foremost on business goals and metrics: It’s important to figure out what your business goals are with your Salesforce implementation, and the customer data you need to work towards those goals. Everything beyond that (at a given stage) is noise. There is often customer data that is mandatory for compliance reasons, and that is definitely non-negotiable. I’ve seen way too many existing implementations that have way too many fields that are unnecessary and create clutter. Focusing on your goals and metrics allows you to make sure you’re capturing the data you care about, while also reducing potential inertia that stems from too many fields and too little time.
2. Qualitative and quantitative measuring of adoption: You set metrics and create reports/dashboards for your customer data- make sure you do it for your internal Salesforce use too! Setting metrics for internal use are as important as metrics for customer data, and is definitely an area I find many companies are lacking. If you’re going to understand and influence adoption, you need to have actual data to assist you.
Maximize User Engagement and Adoption with Your Salesforce Deployment (from Salesforce): This is a Dreamforce 2013 Session from that’s one of my favorite resources on adoption. It’s about an hour long, so it’s not a quick resource. However, it’s well worth your time as a leader before and during your implementation, because it’ll make all the difference in the world about how you think about your adoption.