What makes a CRM solution a success - or a failure?

The simple answer is creating a solution which solves real business issues for the organisation.

However, that is probably not what you expected as an answer.

So, to drill into that, to achieve CRM success we should: 

Understand the issues that we are trying to solve.

These issues will be areas within the business where processes and / or data in the legacy systems cause the users, or customers / clients to work inefficiently, perhaps repeatedly entering the same data, lots of hunting for information or performing tasks manually that could readily be automated.

Understand the technology in enough detail to see how much of the issues can be resolved out of the box and then design a solution that really takes advantage of the existing functionality.

Once we have a solution designed, we should invest in education - and education is far, far more than end-user training.

Under the umbrella of education we should ensure that our technical team have a broad understanding of the technology so we can avoid adding hundreds of unnecessary fields, for example, as that is all a particular person knows. We should also ensure that we have some power users who have a far broader understanding of the technology than most end users. 

Education of key stakeholders, of members of the technical team and of course our end-users is the single most effective way of achieving a successful CRM solution. This is what I call the 'Move to the Middle' model where you empower your stakeholders to understand the why of the technology and you move your business processes towards how your selected technology works natively.

A few years ago, I was helping a client, who has invested several hundred thousand dollars into a CRM (D365) project which was structurally unsound. Because it is structurally unsound, they were unable to build marketing lists and they had huge numbers of duplicate records. 

This came about for two reasons:

1. firstly, the key people did not see the benefit of education, so the communication between them and their implementators was flawed;
2. secondly, they had engaged a partner who had never implemented D365 previously, (but did have ‘the gift of the gab’ especially around “agile”). This meant that they were incapable of taking the client requirements and creating a solution that delivered the requirements while using the power of the technology.

Needless to say, the partner did not advocate for education, as it ran the risk of both reducing their billable hours and showing up their lack of experience.  If your selected implementation partner is not including significant eduction throughout project, perhaps you should ask why they are not so doing!

This is subject about which I am passionate, and I have written and spoken about various aspects of it at length. You can see my writings elsewhere on this blog, and see me speak about it on http://gillwalkerspeaks.com .

• Implement technology for technology’s sake - rather than to fix real business challenges;
• Fail to accurately scope your requirements, perhaps preferring to go on a long, ‘agile’ walk;
• Don't ensure understanding of the project and the technology throughout all relevant people.