Choosing the best CRM software – seventeen classic CRM technology selection mistakes – part two

Following on from last week’s post here are the next set of classic CRM technology selection mistakes:

Falling for the salesperson – As I mentioned in the last post a lot of purchase decisions are based on emotion rather than hard analysis. Salespeople are particularly influential – positively and negatively – in CRM purchase decisions.  While this is to an extent natural – we need to trust and feel comfortable with the people we are buying from – it’s worth bearing in mind that the salesperson’s involvement in the project rarely extends beyond spending the commission cheque. The people you will deal with on a day to day basis, like the project manager, who will to a large extent the success (or failure) of the project, often only appear once the deal is signed. By all means feel comfortable with the salesperson, but, as their contribution is a fleeting one, it’s more important to get comfortable with the people doing the real work.

Comparing apples with bananas – It’s often difficult to compare different options simply because vendors present their proposals in very different ways. What also makes this challenging is that there are arrays of less obvious CRM project costs that some vendors are more transparent about than others. These include issues around what software version/edition is being offered and what functionality it includes, the use of third party products, infrastructure and data storage costs, and support/maintenance contracts (for a more detailed discussion of the hidden costs of CRM software go to this post). As a result a lot of purchase decisions get made on significantly false perceptions of the strengths and weaknesses of the different offerings.  It’s important therefore when seeking pricing proposals to dictate how prospective suppliers should present their responses so that you’re in a position to compare like with like, and that you have full visibility of the real cost of implementing and running each option.

Believing the spin doctors – The role of the salesperson is to sell you their software. This generally doesn’t extend to outright lying – though this is far from unheard of – but there’s a strong tendency towards a certain economy of truth when answering questions within request for proposal (RFP) documents. As I noted in a post called Lies, Damn Lies and RFP responses, half truths like the following are common place:

RFP question ‘Does your software perform function xyz’, response from vendor ‘yes’, the truthful answer being ‘yes, though it involves using a third party module the price of which I haven’t quoted, it will also involves a considerable amount of customization, and it only works with the enterprise version of the software (and I’m quoting you the entry level version) and actually while the module does do what you want, it’s not the best designed piece of software and your users will soon abandon it because it is unfathomably complex to use.’

Getting misled like this can lead to bad technology selection decisions, and I’ve seen organizations as a result locked into packages that fundamentally don’t meet their needs. While there’s no easy defence against spin, it’s worth noting that the more detailed and specific the RFP questions, the closer you’re likely to get to the truth. It’s also worth being aware of which features and functions are vital to the success of your project and ensuring that these receive particular attention. Ultimately the key is not to rely too heavily on the RFP responses and seek confirmation of capabilities through other selection activities such as scripted demonstrations and structured software evaluation.

Asking for a solution that doesn’t exist (at the price you’re prepared to pay) – I recently talked to a would-be implementer of CRM technology who had gone out to tender for a system, but had failed to receive any responses. A review of the document revealed a very diverse set of requirements that couldn’t easily be met by the packages the prospective vendors were offering causing them to ‘no bid’. A closer inspection revealed that a lot of the requirements were ‘nice to haves’ rather than essential capabilities and had the requirements been better presented the vendor selection exercise would have been considerably more successful. The other variation to this is going to tender for a Rolls Royce solution with a Nano budget. The result is a lot of time and energy is wasted failing to secure an appropriate solution. The key is to ensure that RFP documentation is developed in context to what is available in the market at a price you are willing to pay.

To be continued…..