Simple Strategy Tips for Implementing Salesforce.

November 21, 2011
By Lisa Rau

When it comes to CRMs (Customer Relationship Management systems or Constituent Relationship Management, if you're in the nonprofit world), it's hard to beat Salesforce.com. They are the industry leader and pretty much setting the standards these days. Because of its ease of use and simple configuration tools, Salesforce can reduce normal CRM implementation time significantly. This has resulted in more and more organizations choosing the tool. Unfortunately, this quicker implementation mentality can lend itself to organizations skipping key steps or making common mistakes. The following are just a few strategic tips for implementing Salesforce and avoiding common pitfalls.

Don't build the plane while trying to fly it.

One of the great things about Salesforce is its ease of use and out of the box configuration. As soon as you log in, you can start using it. But even a small organization should resist this temptation and first map out how it will be used. For any project, mapping out the business requirements (what information should be in the system, how it should be organized, who should have access to it, etc.) is the most time and labor intensive. It is also the most important. Although it requires time upfront and can extend your implementation timeline, it has the greatest potential to save time and money in the long run.

If you hired a contractor to build a house, you wouldn't want him to start working without a blue print. He could be done with the first floor, beginning the second, before you say, "Excuse me, I wanted a basement." He would have to potentially destroy much of the work already done in order to "add that extra requirement." The same is true with your Salesforce instance. Once users are in the system and data has been added, it is harder to reorganize that data and retrain your users. The more thorough the business requirements, the smaller the chance for unexpected changes.

Business requirements could include (but are not limited to)... the different types of individuals and organizations you are tracking, the different ways that individuals may be related to various organizations, business processes, key data elements that must be captured, automations and data validations you would like to take place, etc. Basically your requirements document outlines and describes 1) everything needed, 2) everything wanted, and 3) and how it all fits together.

Let "Purpose" Drive Your Data

Another common mistake organizations make is to have data in the system because they "might need it for something, someday." If you don't know how you plan on using the data, it doesn't need to be in there. By minimizing the data elements down to those with purpose, data entry becomes more manageable, consistent, and reliable. Two typical types of data "purpose" are 1) reporting and 2) relationship management.

One would think this is rather simple...if you want to report on something, the necessary data needs to be in the system and organized in such a way that it can be reported on. It is simple. But it is often not thought of until after the system has been built. Reporting should be included in your business requirements (mentioned above). This helps drive both the CRM architecture and the end user training.

Another type of "purpose" would be for relationship building. It provides guidance on what data elements might be necessary to build, maintain, and grow a relationship with a customer or constituent, but might never need to be reported on. Again, there should be a strategy of how the information will be used, not just the "maybe someday" mentality.

Design with the End User In-Mind

Another common mistake organizations make is designing an application and then "telling" end users what they want them to do. If end users are the actual users, they should have a say in how it is designed. Of course there are things that must be tracked and reported on, but most users don't really care about that. They want to know what's in it for them. No one wants to be told they have to begin using a new tool in order to provider leadership with numbers. First of all, it breeds resentment. Second, they use it in limited capacity, only to provide the numbers. This gives a false illusion of adoption and limits the potential of the platform.

When creating your business requirements (already mentioned...still a good idea), identify the needs of the end user by answering the simple question, "How can the system make their job easier?" The answers will provide you with a powerful strategy for user adoption. And when you link those answers to the other needs (reporting & purpose), the implementation becomes a win-win for everyone.