Choosing Your CRM Tool the Right Way
This chapter is from the book
This chapter is from the book
This chapter is from the book
Ever wander around the floor of a CRM trade show? You go from booth to booth, chatting with attractive vendor reps and viewing demo after demo. You fill your plastic bag with foam puzzles, rubber stress balls, and more marketing collateral than you'll ever read. At the end of the day all the products seem to run together, and the pitches are identical. It seems as if everyone has the same message. But are intuitive user interfaces and rapid customization features really enough to solve your CRM problem?
That contrived sales pitches and slick product packaging can persuade people to buy a software product isn't a recent phenomenon. Having adopted the ERP systems, data warehouses, and Y2K solutions of yesterday, many companies have already fallen prey to clever marketing, pervasive press releases, and the fluid buzz about market ownership. There are many ways to make a bad CRM technology decision, but only a few ways to make a good one.
Of course, technology is only a small part of CRM. Most companies who undertake CRM technology selection aren't yet ready to do so: They haven't figured out how CRM aligns to their corporate objectives, will impact their business processes, or will mandate organizational changes that will irk many a CRM stakeholder. Change is part of the CRM territory, and technology change is probably the easiest CRM change to accept—which is why many CRM business sponsors begin there.
Indeed, the scenario below, a true story, happens more than anyone would like to admit.
You're an executive at a large, multinational technology company. You've recently begun reading more about the use of customer relationship management to instill customer loyalty and discourage customers from doing business with your competitors. And you've been hearing more about CRM than ever—your V.P. of Marketing mentions it in practically every executive staff briefing.
One day she strides into your office and takes a seat. "I've just reviewed a CRM tool, and we need to get it," she says preemptively as Cheryl, your assistant, hovers at your doorway in a vain attempt to foil yet another unscheduled appointment.
"What was the product?" you ask.
The Marketing V.P. states the name of a familiar-sounding company that you suspect is owned by one of your mutual funds, and begins rattling off buzzwords like she's just learned a new language. You don't know what a screen pop is, nor do you understand what she means by a "customer knowledgebase," but you let her finish. When she does, you ask what any self-respecting executive beholden to a bunch of impatient stockholders would ask:
"How much?"
"Three million," she says. As if it would explain everything, she adds, "A million for the base CRM platform, and another two to redo our campaign processes and customize the code."
You're still wondering why an innocent-sounding screen pop can cost three million dollars. There must be cheaper screen pops to be had. "Shouldn't we look into some alternatives?" you ask. "Maybe there's a lower-cost package that does the same thing..."
"WE CAN'T WAIT THAT LONG!" the V.P. wails. "Our customers are only a click away from one of our competitors! We have to start integrating our channels now! It costs six times as much to get a new customer as it does..."
You've seen it hundreds of times in your long career as a manager, and few things are as dangerous and as fearsome to behold: A businessperson who's just returned from a trade show.
"Have Cheryl schedule a meeting with IT," you respond feebly, unsure of what else to suggest. The V.P. breaks into a wide grin, as if you've just handed her three million bucks to play with.
And in a way, you have.
Falling prey to the vendor hype isn't the only way to screw up CRM technology selection. Below is a list of some of the responses I've heard to the question, "How did you go about choosing your CRM product?"
"The salesman gave it away for free for the first year."
"The V.P. of Product Planning plays golf with the software company's CFO."
"Our main competitor uses it."
"Our end users liked the user-interface...and they're footing the bill."
"They asked us to be on their advisory committee—we're helping them plan how to integrate campaign response modeling into their product."
"The guy who is now in charge of CRM here worked with the tool at his last company. He really likes it."
"They pretty much convinced us they were 'best-of-breed...'"
"They told us the whole thing could be done in three months."
"We already had their database product, so we thought, 'What the heck?'"
These reasons range from acceptable to dangerous. After all, who could argue with impressed users willing to fund development (even though the tool's functionality may not meet these users' needs)? And it's certain that, once they've approved the CRM business plan, executives will want to know when you'll be finished and three-month delivery could make you a hero. And as for competitive pressures, it's a worthy excuse, but are you sure you know what your competitor means by CRM?
Allowing technology to drive CRM is known as the "bottom-up" approach. Usually this involves one organization, or even an individual manager, who decides to go it alone, allowing a CRM software tool or a specific functional goal to define the CRM deliverable. The justification cited for bottom-up CRM is usually the time more rigorous, requirements-driven planning would take.
The risks endemic to bottom-up development, however, are far more serious than the rewards. They include:
Limited consensus about CRM goals risks money being spent on low-priority capabilities.
Subjective interpretation of the importance of the given functionality invites rework and wasted resources.
Lack of integration with other technologies or CRM projects results in either throwaway work or cumbersome after-the-fact integration.
Dependence on specific product features, which may or may not meet additional business or growth needs, jeopardizes broader CRM adoption and growth.
While it might be tempting to espouse the well-worn aphorism "If you build it, they will come," the truth is that if you build it, they probably won't even notice. After all, how much of your company's software products have ended up as shelfware? Bottom-up CRM development means CRM in a vacuum, a project not requested by or socialized to the business.
Requirements-driven CRM on the other hand establishes a level of cross-functional consensus in which people participate from the beginning of the CRM program, and thus feel as if they have a say. The fact is, when choosing your CRM technology, there's simply no substitute for allowing structured requirements to dictate your technology decision. Yes, it takes longer than the knee-jerk development with the tool-du-jour. But the alternative is much riskier, and examples abound of CRM systems that never delivered the goods.
While requirements-driven technology selection is definitely a CRM best practice, the way to go about it differs depending on the type of CRM you're planning to do. While the purists would argue that CRM should always be aligned to corporate strategic objectives, rigorously planning a straightforward CRM point solution around corporate strategy may nevertheless be overkill. After all, simply deploying sales force automation to your national salespeople need not map back to your CEO's latest state-of-the-company address.
Having a vision for the breadth of your eventual CRM functionality is an important step in moving forward. Have a CRM strategy, and you'll know the answer to key development questions, such as: Will this CRM system be cross functional—touching more than one organization—or will it be a point-solution for a single department's focused needs? As with the business case, the answer to your question will help you in understanding the right technology choice, as well as what your company will need to do in order to implement it.
While critical, simply having a list of business requirements is nevertheless not enough information to begin evaluating CRM technologies. Business requirements should drive a series of functional requirements. The difference between the two is that while a business requirement describes the customer-focused "need, pain, or problem" that CRM must solve, a functional requirement describes how to solve it. And it is the definition of these functional requirements that will make your technology choices much clearer. Figure 1 shows the progression:
A customer-focused business strategy drives a series of CRM requirements (e.g., "The ability to track success of target marketing campaigns"). These requirements in turn elicit specific functional capabilities (e.g., "campaign response modeling"). And, as we'll see, once the functionality is clear and documented, you can map a list of your candidate CRM products to each specific function, making CRM tool selection a breeze.