The eight step survival guide to buying/implementing CRM software

When companies get the buying and implementation of CRM right and they make it work for them, it can add a huge amount of value to their business. And because most companies don’t do it right it really can be a hidden source of competitive advantage. Furthermore, it is not that difficult to do, as long as you’re prepared to approach it in a sensible way. The problem historically has been that there has been very little information about the sensible way of doing it, because the information out there has either been in the form of communications encouraging people to buy CRM technology or it has been written by marketing people who don’t fully understand the implementation process – which is not terribly helpful.

The biggest mistake firms make is not having a clear idea of why they are implementing CRM and what the business objective is. There is often a fuzzy notion that CRM technology is just going to miraculously generate some business value simply by purchasing it, so the focus just tends to be on the technology the whole time, meaning there isn’t actually that much focus on what the company is trying to do with it from a business perspective.

Are you trying to retain more customers? Are you trying to improve customer service? Are you trying to manage your leads more efficiently? Are you trying to cross sell products and services to your customers better and increase sales? That precision about objectives is often missing. Bear in mind that CRM can be used by companies from the same industries in entirely different ways so it is not as if CRM does just one thing. There are lots and lots of different ways in which you can use it to beneficial effect. But one thing is for sure – you won’t achieve anything unless you’re clear on what that objective is.

The second biggest mistake at the planning stage is that firms really don’t understand what resources they are going to require and how long it is going to take. You may have got information about the investment in the technology and the services from the vendor, but there is then all the work that needs to be done internally – project team time, getting people to use it, and maintaining it over the long-term. Businesses don’t always embark on this with a very good understanding of how much it is going to cost and what is going to be involved in terms of making it a productive systems. And you end up with something that half the company doesn’t use, those that do use it in different ways, and it becomes more of a basic personal productivity tool rather than something that adds real organisational value.

The requirements is done poorly by most organisations. What you tend to see is two or three pages of bullet points and it is just a list of functionality. i.e. "I need email marketing campaign management, I need..."

Firstly, firms should think about it in terms of process. Hopefully the planning has been done well and we understand what the objectives are, and we now have to say what are going to be the processes to achieve those objectives and how those processes will be accommodated in the system. It is only when you start to detail out those processes that the complexities start to appear.

Businesses need to think from a process viewpoint – and when you do you realise there is a lot to think about in terms of how the processes operate and how those processes are going to operate within a system, and what fields should be captured in order to support those processes and what functionality would support it as well.

The second problem is that because businesses don’t do the requirements in any great detail vendors don’t have a clue how long it will really take, so they price it at what the buyer will buy rather than what is necessarily appropriate for the project. Firms end up purchasing from prospective vendors with no real concept of what the end price is going to be because the vendors can’t quote accurately due to the lack of sufficient detail. What tends to happen is that they sign up to a vendor and after it does its detailed requirements specification it provides a vastly higher quote. And if you’ve committed to a vendor at that stage it is a difficult thing to get out of.

Get very detailed specifications done up front and that means you can get firm prices from the vendors in a very competitive environment, and it means you buy your technology a lot cheaper with no surprises downstream.

Businesses tend to rush into this whole thing and they don’t do a great job on the planning front and are a bit hazy on the objectives, which is usually just a bulletpoint list of requirements. Then they are getting vendors in to demonstrate software. CRM software companies are very good at demonstrating software and very good at showing the best parts and avoiding the bad parts. So if you’re not careful you end up making a decision primarily based on how the software looks on the screen and how you got on with the sales person. And that is a problem with a lot of these purchase decisions, they are not based on real functional comparison, they are based on how they felt about the salesperson on the day of the pitch. And that can get people into a lot of trouble. 

Vendors come up with design specifications that are often very detailed documents that the client is meant to sign off. But they are actually written for the developers more than anyone else – it is for the vendor’s internal development team. Therefore, it is a big ask for a prospective client to spend the time to read a 100 page detailed design specification, any few words which you could be agreeing something that isn’t what you want. Often it is totally impenetrable.

The problem is that what you sign off is what they will develop and if it isn’t what you wanted then they are going to say that it is a change request – and you’ll have to pay more money to redo it. If you are going to do it properly, prepared for it to be time consuming. You can go through many iterations of it before you get it right. It is the bit that catches people out. It is quite time consuming and resource intensive and frustrating, but if you rush it then you can have an expensive bill at the end of it. You need to put the effort in and sweat through each detail and don’t be afraid to question it with the vendor By all means ask the vendor to communicate it in layman’s terms so you can review it and ideally try and do it with mock up screenshots and things like that so you can envisage it much easier.

At this stage I’m assuming that people will be dealing with an implantation partner of some description, and that the implementation partner will be doing the development work. So from the end user viewpoint this is the period where they have very little involvement. They have signed off the specification and probably over at the vendor’s offices there are developers working away to realise that design. So this is quite a quiet period often for the buyer of the system. If you have a very poor specification, there might be some benefit of having some periodic reviews with the developers so that they can show you where they have got to, but I think that is a very inefficient way of developing in my view.

The last thing you want when you start up your brand new system is some ropey old data that everybody looks at and knows it is out of date and incomplete and duplicated. Therefore, you need to get your data sorted. Data preparation is something you get on with as soon as you can and businesses should be thinking of it almost before they sanction the CRM project. It really should be something that starts early in the project.

The problem is that organisations don’t necessarily understand all the complexities associated with it. They think that if they have 20 Excel spreadsheets on the PC, they can just dump it into the system and don’t think about the fact that the same person probably appears on six of them, with slightly different details on all six. There is some inappropriate expectation on a lot of people’s part on how much data they are going to be able to get into the system. Therefore, you need to get them to focus on what is the core useful data, and not try and bring everything in, because that will create a potentially ridiculous amount of work. It is a case of treating the data as a key stage in the project and not a minor sideline to it all.

This is a bit dangerous because normally once you are into user acceptance testing then things like live data are often being published already and so if you do start to uncover lots of issues then all of a sudden the pressure ramps up. Businesses don’t tend to appreciate how many issues you will typically get. If you allow the vendor to manage your expectations of project timelines you would assume that that sort of thing could be knocked out in a week – a week of testing, a few quick fixes and you’re live. The reality is that you’re probably looking at a couple of months to test, identify all those bugs, then they go off and fix them, you go off and retest them and find that some haven’t been fixed and some have broken other things. You have all of these iterations and it can take quite a long time to get all of that sorted out.

Meanwhile, you have got all of the pressure of the looming live data and expectations set, with senior management probably baying for the system to go live – and what often happens is that the team get pressured into allowing the system to go live with a lot of bugs still in it. Then the users go in, find the bug., say this isn’t ready, stop using it, and in many cases never resume. User confidence in systems is fragile and if you break it straight away it can’t be repaired.

Therefore, first of all get your testers – you need people on the project team to be involved and going through and checking it all back against the documentation. You also potentially want users themselves feeding back their thoughts on it. But make sure you set aside a fair amount of resource.

Over the years, the CRM industry has realised that the problem with CRM systems is getting people to use them. Vendors are more than aware of that so they come out with new iterations of software that are ‘easy to use’ and ‘fantastically intuitive’ as if that is going to resolve the user adoption issue. But just because they are easy to use doesn’t mean people will use them.

If we’re looking to run our business processes through a CRM system we need everyone to use it and use it the same way, otherwise we’re not going to get the outputs from the system. If you really want to add value then you need the team to use it consistently in a structured way. And that doesn’t come easy. Traditionally the entirety of a user adoption programme is a half day training course – and that’s it. But just because they’ve been on training courses doesn’t mean they’ll use it. So you need a lot of structure and infrastructure around that to look at usage and see where there are issues and take action to address them and be proactive about it.

Getting the usage bit is really hard work and really resource intensive – but if you’re not prepared to devote the resources, then don’t do it.

For more on this topic, Richard Boardman has put together a comprehensive e-book entitled ‘An industry insider’s survival guide to buying and implementing CRM software’. It brings together some of Richard's blog posts combined with new material to provide an unconventional inside view on the challenge of buying and implementing CRM software. There’s a free, no sign up, download page here.