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.
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.
posted by Richard Boardman at 1:46 pm
<< Home