freshidea - Fotolia

Manage Learn to apply best practices and optimize your operations.

CRM pitfalls: The premature go-live date

Companies are often eager to get CRM systems up and running as fast as they can. But beware the premature go-live date.

As a senior manager of sales operations, I have seen several mistakes with CRM implementation that can cost companies thousands, waste time and even be career killers if decisions are handled poorly.

While I've seen several causes of CRM failure, one of the most prominent is something we might call the "premature go-live date."

Once a company chooses a customer relationship management technology, it's often clamoring to take off the training wheels and test-drive the production version. The eagerness to get up and running with a new CRM system is understandable, but companies need to show restraint and test, test and test again before they put a new CRM system into production.

Without discussing and thrashing out these issues, you risk spiraling data integrity and decreasing user adoption that will require even more manpower to fix the mistakes, recover and get your CRM system into production.

I have seen legacy systems that have not been implemented until six months after launch and the results were disastrous.

I've outlined some concerns to be aware of and some tips to ensure that you don't launch your CRM prematurely.

1. Naming conventions. How can you ensure that system redundancies aren't created and that users can easily find correct information? Consider how many ways a company's name can be represented in a database (e.g., Coke, Coca-Cola, Coca-Cola Company, Coca-Cola Co.). How will you deal with the existence of child companies and regional affiliates? These issues may seem small if you have limited data today, but think long-term about how even the smallest company can change in five years and how much incorrect data could proliferate in its system. Create a separate Billing Name field to capture how the company name will be represented in bills, but use the Account Name for data integrity, removing special characters as needed and preventing words from being shortened (e.g., "Inc." should be "Incorporated").

2. Clean data before mapping. Sometimes the person cleaning data is not the true owner of the information and may not understand what is needed. Make sure this data is cleaned by the person who knows how it should look. It might need a team -- depending on the complexity and size of your data -- and it will need to adhere to your new naming conventions before being imported. A record owner should be assigned pre-load. It is not fun to have to remove the data from the system or assign it manually to every sales representative.

3. Security roles, org chart integration. Discuss how each group of users will and should use the system from the outset. Who should see which data? Can managers just reassign leads and opportunities for their team? Will only system administrators be allowed to export data? Who gets approval from whom to close an opportunity? All these issues are pivotal to making sure the right people can use the system from the beginning in the way the organization envisioned when the project started.

4. Legacy software implementation. If legacy systems need to report to the CRM or vice versa, integrating them with the CRM system should be one of your first objectives. I have seen legacy systems that have not been implemented until six months after launch and the results were disastrous. You open the door for redundancies, confusing mapping and the inability to use both systems appropriately. Of course, there is always a way to get this done after the fact, but if you know from the beginning that all your information needs to come from an in-house database, sync them first.

5. Sales test group. Once the first four concerns have been addressed, you are ready to see what users think. No matter how much prep work you do and how many experts have been included, some things will need to be tweaked. To minimize confusion and re-training, employ a user test group that is willing to be an early adopter and give its insight. It will identify certain errors or question areas that your team may not have considered. The idea is that this phase will be minimal and will be a short time period before the total launch.

6. In-house CRM specialist. Many companies do this from the beginning of the process. Others wait until the CRM is mostly complete and ready to launch. If your organization does not have a dedicated CRM specialist yet, get one. This person doesn't have to write code, but he or she should be able to run reports, ensure data integrity and make changes as needed. They believe in the system and will help others "see the light."

This list is not meant to be exhaustive, but it covers the areas that are often neglected by organizations during the initial implementation process. CRM is one of the most useful tools for sales and other teams when done correctly, so it's worth the resources in the beginning to ensure success.

Next Steps

Right company culture needed for social CRM rollout

FAQ: Software testing in the cloud

Choosing CRM features: What users think

Dig Deeper on CRM strategy and implementation

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Of course, depending on how big your CRM is, as well as how big your organization is, this process might be more involved. This would mean that screwing it up is even riskier than normal. These are great steps to take in order to assure that you've got everything in place before making the official switch. A few things I'd add here are to make sure you have your process spelled out and tested in order to input it directly into the workflow of the CRM. Also, be sure you pick a CRM that won't have a high learning curve so that you're not in statis mode for centuries trying to figure the thing out and train on it over and over. Also, be sure everyone on your team knows who to talk to if something goes wrong. Have a support channel open at every level. Brad Hodson (JobNimbus,