User Adoption of CRM – The Key Issue

John Eccles, 30 July 2013

How’s this for an IT strategy:

• Management decides “we need a CRM system.”
• Careful selection to find the best fit CRM software.
• Find a consultant or partner to implement it.
• Run a training course.
• Less than 20% of users actually use the system after 3 months.
• The system is abandoned because “it doesn’t work for us.”

 

Picture from: http://drchrisstephens.com/hope-is-awesome-not-a-strategy/

I agree – I’ve seen better!  In fact no-one in their right mind would have a strategy like this. Yet what I described does happen. 

I have heard too many stories of CRM systems that were abandoned because they just weren’t used. 

According to a study by SandHill Group and Neochange (2008) http://www.sandhill.com/assets/pdf/AchievingEnterpriseSoftwareSuccessFinalReport.pdf by far the most important factor for realizing value from software is effective user adoption.   

 

Interestingly, software functionality rated very low in terms of realizing value. Yet that is usually where the focus and the time and resources go. The main emphasis is on getting the system to do the tasks we need – not so much on preparing the users and designing for ease of use. 

Perhaps that is why the same study reported that 66% of Enterprise software buyers had effective usage rates below 50%. 

Improving CRM User Adoption

I submit some suggestions, some of which I will elaborate in future blogs: 

1. Get users involved early. Get them involved from the very beginning of the CRM project.  Involve users from every department affected. Present the reasons for CRM. Show what’s in it for them. Listen to their feedback. Start the education process early. Be motivational. By doing this, you will help ensure that users’ needs are met and you will develop champions for the project.

2. Roll out in phases.  Unless you have a small team and a narrow range of CRM functionality then find a way to phase the project. Start with a small, pilot group and get the system working so well for that group that they will become advocates to the rest of the organisation.

3. Design in Ease of Use.  It’s not enough to specify, “The software shall be easy to use.” What do you mean easy to use? You need to stress the importance of Ease of Use up front. You should get some meaningful user experience (UX) requirements in the requirements document. You should insist on being shown how those requirements are translated into the design. And you should focus on checking those requirements before you accept the system.

4. Train well.  It’s better to over-train than under-train. Do not expect everyone to come back from a training course and be able to use the system. It doesn’t work like that. So make sure that you have at least one person in your team trained as a “super-user” who can confidently help other users. I also recommend that training is followed up with a review or refresher session at which users can ask questions and drill deeper into the issues that have arisen.

5. Start well.  Ensure you have support available for users at “go-live”. Issues will inevitably arise and it is important to address those issues quickly. Frequently there will be suggestions for improving the system. (It seems that users are far more intelligent at the go-live stage than at business analysis workshops.) Make sure the users know that their ideas for improvement will be evaluated and actioned if practicable.