How do you ensure user acceptance of CRM systems?
In a heated debate at a recent meeting of senior managers at a computer firm, the vice president of marketing favored a "mandate-change" solution, in which the sales force would be required to enter in volumes of data on their customers and prospects. But the senior vice president of sales dismissed the notion that anyone was going to force his reps to do anything and would instead have to motivate them to provide the necessary information. The discussion ended in an impasse.
After years of sitting through similar discussions with dozens of other firms, I have to side with the sales executive on this one. Having surveyed more than 2,000 projects over the past nine years, I have yet to see the mandate-change approach work.
Not All Equal
According to software visionary Bob Epstein, the key error many IT project teams make in their thinking is that they view all users as being equal. Bob had realized through his experience that there were actually three main classes of end users, each with its own set of motivations for using new computer systems.
The first class are what Epstein referred to as "indentured users," people who have to lean and use the systems their company provides them, however confusing and convoluted they are, or they don't have a job. This would include employees like claims adjusters, bank tellers, and accountants.
Epstein's second category was "power users," who see computer systems as an opportunity to learn something new and take on the challenge with gusto. Power users can be manufacturing managers, engineers, even sales reps, but they are all "closet programmers" to a certain degree. Too often, we turn to one of these power users for user feedback on systems. But they are the wrong people to ask for advice, because they do not really represent typical users.
Epstein's third user type, the "volunteer users," already do their current jobs without the help of major software applications. These sales, marketing and customer support people may rely on outdated reports, post-it notes and snail-mail, but they still get things done--they launch products, they close deals and they service customers. Bob pointed out that if you want to get these users to adopt CRM systems, you need them to volunteer to do their jobs a different way.
When implementing CRM projects, we must be able to articulate how these systems will make these users' jobs easier. If we cannot find a way to motivate them to change how they work, they will simply go back to doing things the way they have always done them.
So how do you motivate change in "volunteer users"? I have seen a number of techniques successfully applied. My first suggestion is to involve representatives from the various user departments as early as you can in the project. For example, Great West Life's CRM team formed a user advisory board to represent the voice of the field at the very start of the project. The committee participated in all the major project steps: process analysis, requirements definition, vendor evaluation, functional specification, system testing and final system rollout.
The team members provided invaluable feedback, making sure that the project solved real user problems, and were instrumental in selling the final system to their field counterparts because they understood the system's benefits.
If you cannot commit user resources for the life of the project, then you may want to consider bringing them in at key times. Allied Signal, for example, let users be part of major decisions. When selecting their hardware, they set up a vendor fair and let the field reps come in and see the three available systems. The reps checked out the weight, asked questions on battery life, and played with the keyboards. This simple step went a long way toward getting the users to view themselves as part of the project.
If you are going to ask users to enter in information about their customers, be prepared to justify why you need the data. Michael Lodato worked on the CRM initiative at Sybase, where various departments inundated the CRM team with requests that data elements be made required fields for the sales reps to enter.
Michael and his team asked each person making the request specifically what she was going to use the information for. They dramatically reduced the number of required items, and they had a good justification to share with the sales force on why their help was needed for certain items.
Another technique for ensuring user acceptance is reconsidering the purpose of a pilot, which too many companies view as a substitute for QA for ensuring that the software works. Chubb Insurance and Pitney Bowes used the pilot to document hard business benefits generated from using the system.
Both companies gathered metrics of how they were doing business pre-CRM implementation and then tracked how processes improved because of system usage. Then, during the full system rollout, they showed the rest of the user community specific examples of how their jobs would be better if they adopted the new CRM applications, a key to converting their users.
By always considering the "volunteer" user concept, you will find that the issue of mandate versus motivate disappears. If the system can answer the question "What's in it for me?" through the functionality it delivers, users will sell themselves on integrating it into their jobs.