CRM application developers are from Venus. CRM end users are from Mars.

One of our projects provided a good example this week of the gap between the worlds of application development and application usage. We’ve been helping a client re-implement an existing CRM system in a way that better supports their business. One of the key requirements was to improve their lead and enquiry tracking processes, in order to provide marketing with better feedback about which campaigns were working best, and sales management with better visibility of sales lead to conversion rates.

At first sight, a newly released version of the CRM application seemed to provide many of the elements we needed right out of the box. In principle great news, as it would significantly reduce the cost of development work. However, what we hadn’t allowed for, was the way the developer saw this process working turned out to be at considerable odds with what the poor souls down here on planet earth actually needed to perform their jobs.

One of several examples – first step in our enquiry logging process was to check whether the caller was already on the database. We wanted to do this by searching on combinations of fields – names, post-code, company name etc. What we wanted to do, was allow the user to put in the first x letters of say the post-code, and then potentially reduce the number of records in the search by also including the first x letters of the name. What the application actually did was expand the search by adding all the people whose name began with ‘Smi’ regardless that they lived anywhere in the country, to all the people in SW1.

Which all seemed, to me at least, a curious approach – though someone might just have convinced me of the logic, if it hadn’t also been for the fact that the developer had sprinkled in a huge number of seemingly unnecessary key strokes – presumably on the basis that sales team so loved logging enquiries they figured they would maximise the pleasure by making the whole process significantly longer than it actually needed to be.

The wrap up was that the reseller we were working with did a sterling job in quickly customising the standard features to get something that worked for our client – who happens to live down here in the real world. While the day was saved, a few thoughts occur to me:

One, nothing kills CRM usage quicker than unnecessarily long-winded, convoluted processes.

Two, echoing Monday’s post, what you see in a demonstration might look good but fail to translate to real life.

Three, situations like this provide the seeds of potential conflict with the system implementer where (though not in this case) the conversation can end up going something like this:

Mr Customer – we need an enquiry logging process.
Mr Implementer – but that’s what you’ve got.
Mr Customer – no I mean one that works… here in the real world. One that my sales team are actually going to use – one that means I’m not completely wasting my money on this CRM system.
Mr Implementer – we can certainly give you an estimate on the development work, I’ll have Sally in sales call you.

Four, don’t assume the people who write software have any idea how people actually use it.

The role of the software demonstration...

When it comes to buying software - CRM or otherwise - the software demonstration has generally played a weighty role in the technology/vendor selection process. I rack my brains, but I can't recall an occasion when a CRM project in which I was involved, progressed without at least one demonstration before a purchase was made. Eleven years on, and having been exposed to several hundred selection decisions - both as a vendor and buyer - I'm increasingly cynical as to the value of the exercise.

From my time as a CRM vendor, I'm all too aware how easy it is to script a demonstration in a way that showcased the offering’s strengths and skated over the weaknesses. As a CRM purchaser, faced with assessing a dozen seemingly similar CRM offerings, I’m acutely aware how difficult analyzing the differences can be - even with the benefits of years of experience, and a reasonably tutored eye.

Software demonstrations, rather like job interviews, are a somewhat flawed process. A candidate’s performance in a one and a half hour interview is no guarantee of long term performance. The demonstration produces its own distortions - I've seen excellent products from highly capable vendors culled from candidate lists for seemingly trivial reasons, and products I knew couldn't do the job, from vendors who I wouldn’t trust to mow the lawn, end up winning the day.

While beauty is of course in the eyes of the beholder, software purchasers might do well to re-evaluate the role of the demonstration. It is, to my mind, a deeply subjective process – too easily swayed by performance on the day – too focused on form as opposed to function.

By contrast, good decision making flows from an excellent understanding of the intended result. The clearer the business and associated functional requirements for a project, the more objectively you can assess the technology options. And perhaps this is the heart of the problem, the software demonstration is an important (though often overemphasized) selection tool, but a tool invariably used imperfectly because of the lack of clarity over the destination; as Lewis Carroll noted – ‘if you don’t know where you are going, any road will take you there’. Translated – ‘if you aren’t crystal clear on what you want the technology to do, then any CRM package will get you there.’

Welcome

Welcome to The CRM Consultant.

To the extent I'm fully clear on where this blog may lead, it's my intention to provide commentary on technology developments in the CRM market space particulary in the context of how they relate to the fortunes of the Small and Medium Enterprises (SME's) that I work with. Perhaps more importantly, it's my aim to share some insight into the challenges that SME's face as they try to maximise the value of CRM to their businesses.