There are many articles out there on why CRM fails – it’s a common topic for consultants and service providers, and we’ve published several articles about it here at The HUB. If you Google it, you’ll get a lot of good articles. They generally talk about four main reasons:
- CRM is more than technology
- Needs are not clearly defined
- Management is not committed enough
- Measure of success is not determined up front
As an aside, the last one is interesting, isn’t it? How can a company say that their CRM project has failed when they haven’t defined the terms under which success can be achieved?
Back to the topic. I want to talk about more than just CRM. This failure could be any enterprise application that is put in front of the sales team with the idea of improving overall sales performance and productivity. And these aren’t the only reasons software doesn’t work out for the sales organization. Here are three more:
Software Is Too Complex (or Too Simple)
This is a common one, believe it or not. Well-meaning, large companies end up implementing cumbersome apps that end users hate. Small companies implement apps that don’t quite solve enough. In both cases, the users run side systems on their own – you’ll recognize them as Excel spreadsheets or MS Access apps (sometimes with Sharepoint!).
Many sales professionals view themselves as managers of their own territory (or customers, or industry) in addition to being salespeople. If they are targeted for providing data input, make sure they are part of receiving the output.
My suggestion? Design the 3-5 dream reports you want right up front. Then work backwards – manage the interface and requirements to deliver those reports….and share the results with the team. And don’t forget – run those reports starting from Launch Day!
No Value to End User
This is a big one. A good CRM implementation ties the software to business process – but if the users aren’t getting value, they will soon create a mutiny. As mentioned, users should be part of the output, too. But that alone is not enough. The interface itself should be driving new and better behaviour in day-to-day, hour-by-hour business life. If the process works and is in front of them constantly, they will adapt and adopt.
Training is Software-Use Focused
There are people who argue that training shouldn’t be needed anymore – but they’re wrong. Well, partially wrong. Most of the time, training is showing the users how to use the software.
Instead, training should be a combination of software use, but blended with understanding the business process and workflow that each use case supports. If it’s a quoting process – then there should be a diagram showing how the process functions, what is expected at each step, and then a software overview of how it actually works.