As a Salesforce consultant, it’s sometimes easy to predict the success of a client’s CRM implementation well before the project is finished. While our goal is to provide the full value of the technology to every client, there are sometimes telltale signs that a team will not adopt Salesforce the way it needs to.
These signs always tie back to the company’s Salesforce strategy.
In a previous blog, I’ve mentioned that the Salesforce strategy you pursue can have a major impact on how the platform is perceived when it’s rolled out to users. The question: Do users see Salesforce as their tool, or something that’s being pushed on them?
In my time consulting on CRM implementations, I can think of two examples that illustrate this difference best. These cases demonstrate pitfalls to avoid when setting up Salesforce, and how to build a tool that your users can see as their own.
Salesforce Strategy #1: The Top-Down Approach
One of my first projects involved a brand new implementation for a company we’ll call Company X. Its CEO was forcing the company to start using Salesforce; he had success with the CRM at his last organization and wanted to see the same results.
Right off the bat, however, it was clear that it would be difficult to engage employees in the project, or with Salesforce in general.
What were the signs?
1. There was a lack of direction from leadership.
Though Company X’s CEO was the sole reason for the project, he was never in any of the meetings throughout the implementation. As a result, he never reinforced his message to the team about the importance of using Salesforce. Instead, the VP of Sales was responsible for the project. This VP didn’t seem to see the use case for Salesforce. He understood what the CEO wanted, but didn’t buy into the vision and never passed that vision down to his team.
2. End users had suspicion of leadership oversight.
The VP’s attitude toward Salesforce became contagious. It was hard for us, as consultants, to miss the wider team’s mistrust of the CRM. They were all used to maintaining their own platform of spreadsheets to keep track of all of their relationships and deals. They thought this tool was being forced on them. They believed that it would constrain their personal working style and allow their CEO to keep better tabs on them.
3. There was little team participation.
For the reasons mentioned above, it was difficult for the Torrent team to find time with Company X’s sales users to discuss the Salesforce implementation. They were always on the road — understandable for salespeople — and didn’t seem to make the implementation a priority. It was rare for us to have full team attendance during our project meetings. We were tasked with designing a tool for them, but because Company X’s users didn’t understand that the tool could help them, we were unable to build the right platform for them — or even convince them we could.
A vicious cycle that can plague any implementation.
The result:
When we finally got to our training session at the end of the project, the sales users were unsurprisingly disengaged and distracted. Many users didn’t remember details of the platform that we had discussed in meetings only weeks or days prior; they either weren’t on that call or didn’t remember it. Nobody completed their Salesforce training exercises during the time we had planned for them.
Then, a few months after the project ended, we heard back from Company X. We asked them about Salesforce.
Turns out, nobody was using it. User adoption was almost at 0%.
Salesforce Strategy #2: The Build-for-end-users Approach
Company Y’s story starts similarly to Company X. Company Y’s customer service team was using personal notebooks to keep track of all of their customer calls. Their director wanted to put this information in Salesforce, to share it among employees and speed their response times.
However, Company Y’s strategy for implementing Salesforce was drastically different; it made a huge impact on user adoption.
What did they do differently?
1. Leadership communicated a consistent vision throughout the project.
Not only did Company Y’s director communicate her vision for the platform throughout the project, but she also got her entire leadership team on board. Every person involved at this level — client services supervisors, the IT team and sales managers — reinforced the same message to their teams. Like every project, individual users occasionally questioned the purpose of implementing Salesforce or some of the decisions made during the project. At each turn, however, leadership reaffirmed their shared commitment to the success of the tool.
2. They built the platform for their users.
Even before the build started, Company Y brought us into their offices to sit down with future platform end users. This allowed us to understand their day-to-day work and design a platform that would work for these users, not just for management. What’s more, their leadership communicated to us multiple times that Salesforce was not to be used for employee performance evaluation.
Company Y’s commitment to their users extended far beyond optics. Almost every aspect of the build itself related to ease of use. In our design meetings we heard the same questions again and again: What’s the easiest way for team members to collaborate and share knowledge? How can we reduce the number of clicks? Can we improve the design of this page to make it clearer for users?
3. End users were heavily involved in every part of the project.
From design to build to test, Company Y made sure its users were involved in each step of the implementation process. Questions and objections were fielded during each Salesforce design and review meeting to make sure that the platform made sense to everyone.
After each round of building, management allowed end users to test the platform themselves and provide additional feedback. This process was even open to employees unaffected by the platform we were building!
Don’t get me wrong, it was much more difficult to build a solution for Company Y than for the first company, Company X, because we needed to find ways to incorporate feedback from multiple users that occasionally disagreed with one another. However, the solution ultimately produced a more inclusive vision of what the tool could be.
The result:
When we got around to training, the users flew through the extensive packet of exercises we gave them in half the time we scheduled. They were already so familiar with the platform after all their testing that this “training session” was more of a dry-run than a learning exercise. Users asked many questions that were on point, direct and about how to use the platform in their everyday work.
Once the training was over, I told them that they were one of the best training classes I had in my consulting experience. One of their users responded by asking about my worst training experience — if his was among the best.
And I told him the story of Company X.
