.

Let’s say your boss has asked you to explore buying a Customer Relationship Management (CRM) software package for your bank. How can you manage the process so you find an appropriate system without taking too much time from your other duties?

Your first step will be to establish the goals for the project. Why are you buying it? What are the specific problems it is expected to solve or opportunities it will help exploit? CRM software, by its very nature as a system that combines marketing, sales and service functions, can do many different things. If you don’t establish concrete objectives for the system, you won’t be able to sort through the options and establish which solutions make sense for your situation.

When you first ask about goals, you may get a general answer such as “we want to know our customers better” or “we want to be more responsive to customer needs”. Don’t stop there. Projects like this nearly always have a very specific source—a particular business issue such as an inability to track sales leads or generate mailing lists or pull together a unified view of all accounts associated with an individual customer. Often there was a single incident that crystallized the problem and led senior management to recognize the need for a broader solution. Whatever else the system you select does, it had better solve that original problem.

One way to come up with specific objectives is to work with the system’s future users to develop scenarios. These describe particular business processes, such as setting up a new marketing campaign, that the system is expected to perform. Asking users about scenarios leads them naturally to describe the processes they care about most—although you often need to let them list several before they realize what’s really important to them. But the real benefit of a scenario is that, once you’ve defined it in general terms, you can drill down into the details of which data elements are necessary, which systems it will come from, who will execute different parts of the process, how the tasks will be coordinated, what outputs are required, and so on. Exploring these issues forces you to address the practical details that might otherwise not be uncovered until the software is purchased and you try to start implementation: only to discover major gaps in your existing capabilities, new system, or both. Identifying the issues early enables you to be certain you develop a complete solution to your targeted problems, including changes to existing systems or acquisition of software in addition to the CRM system itself.

On a less lofty but still important level, scenarios provide something specific to look at during product demonstrations, forcing vendors to show a complete process rather than just the portions of their system that they prefer to highlight. Since scenarios typically relate to tasks users are already performing today, it is much easier for users to judge how hard or easy it will be to do those tasks with the new system.

But to worry about demonstrations is getting ahead of ourselves. Let’s go back to the original topic of goals. Although there’s no substitute for defining the goals of your particular project, it’s worth knowing the general sorts of functions that CRM systems might perform. These fall into several categories:

- data integration. A central marketing database, combining information from all source systems to create the clichéd “360 degree view of the customer”, is really a means to an end, rather than a goal in itself. But it’s important to so many other things that it’s worth defining as an independent objective. Some CRM software includes sophisticated integration functions, while other CRM packages require the database to be built separately. If your company lacks an integrated customer database then you need to make certain your CRM solution includes the capability to build it for you.

- outbound campaigns. These are traditional marketing efforts such as direct mail and, more recently, email, as well as general advertising such as broadcast, print and outdoor advertising. The purpose is to create broad awareness of the bank and to generate individual leads for particular products and services. A CRM system provides campaign management functions including list generation, response tracking, and administration (budgeting, scheduling, task management, content management, etc.). Specific goals related to these functions might be more effective segmentation, better understanding of results, quicker execution, or greater staff productivity.

- lead management. This is the process of taking leads generated by marketing campaigns and transforming into sales. It includes lead allocation, distribution, and result tracking, as well as the contact management features used by individual salespeople. The growing importance of email has added a new set of “drip marketing” functions where the CRM system generates a personalized set of messages, tailored to the anticipated needs of customers or prospects who are not yet ripe for personal contact by individual salespeople. At many banks, lead management is the most important reason for adding a CRM system. Goals related to lead management include more efficient lead distribution, targeting sales efforts to the most important leads, improved sales force productivity, easier access to complete information about each lead (back to that central marketing database!), and better tracking of sales results.

- sales reporting. This encompasses the functions of traditional sales management software, which are often included in a CRM solution. It includes reports on account status, customer portfolio performance for each sales person, and sales pipeline reports used for forecasting. It may also extend to management of sales incentive programs and bonuses. Goals in these areas generally involve making the information easier to assemble, and administer and analyze.

- customer service. In a banking context, customer service includes all points of interaction: not just teller workstations, but also call centers, ATM machines and Internet banking interfaces. The CRM system typically does not replace these systems, but enhances them by adding customer- and marketing-specific information such as targeted cross-sell offers, customer value indicators, and alerts related to recent problems, unusual transactions, or information requests. Typical customer service goals for CRM systems include broader distribution of relevant offers, customer recognition, and consistent treatment across touchpoints.

In the initial stages of the selection process, goals can be defined in general terms. But before actual deployment, they must be translated into specific metrics so progress can be measured. It’s best to keep this in mind from the beginning, so you can be sure your goals are in fact something that can later be quantified and that your system requirements include whatever measurement capabilities will be needed.

Of course, identifying your goals is just the first step in the selection process. The next is defining other criteria for vendors. These largely relate to finding an appropriate fit for your organization. One important consideration is technology: any new system should run on whatever kinds of servers, workstations and databases you currently have in place. This might be Microsoft Windows, Unix, Linux, IBM i Series, mainframes, or something else. It might be possible to justify a truly unique solution that was incompatible with your current infrastructure, but the maturity of today’s CRM offerings on all platforms make it unlikely that you’ll need to. Depending on your goals, it might also be possible to deploy a hosted solution, run by an external vendor and integrated lightly or not at all with your existing systems. In this case, compatibility with the existing infrastructure is much less important.

You’ll also want to look at compatibility with your existing operational systems. Many platform vendors themselves offer CRM modules. These may not be quite as comprehensive as the best stand-alone CRM software, but could still meet your needs. If so, the savings in deployment time and effort can be considerable compared with integrating some other system. But don’t just assume that these savings are real: sometimes a platform vendor’s CRM “module” was developed independently and thus still takes considerable integration effort. Implementation can also be difficult if the platform system itself has been highly customized in your installation. Also bear in mind that many CRM projects are intended to share data across multiple operational systems, so a CRM module that is tied closely to one system may actually be harder to deploy than one that is designed to work with a variety of other products. When you do look a third party systems, be sure to find out how many times they have been integrated with your operational systems—and, later in the process, be sure to talk to reference accounts where that has happened to see what was really involved.

A final aspect of compatibility involves organizational fit. Some banks have extensive, sophisticated information technology departments that can handle almost anything and, indeed, look forward to the challenge. Others have very limited IT resources and rely on outside vendors for almost everything. Make sure the vendor offers the level of support that your organization requires, and try to find out whether you would be at outside the norm compared with the vendor’s other clients. Also consider other aspects of organizational fit: the degree of formality or informality you and the vendor are comfortable with; the sizes of your respective organizations and of the vendor’s other clients; the scope of services (such as marketing, strategy or sales consulting) that the vendor offers and you might need.

Of course, you’ll also want to understand the vendor’s financial situation. Privately-held firms may be reluctant to share specific information early in the sales cycle, but should definitely provide details before expecting you to sign a contract. Even early in the cycle, you can expect to get a general view of number of installations, growth rates, head counts and development plans. If you find a product you like but have some concerns about the company’s stability, be careful to build protections into your contract such as escrows of source code and escape clauses if the company changes hands.

Armed with your list of functional requirements (derived from goals) and compatibility considerations, you are now ready to begin the vendor search in earnest. In today’s world, developing a list of candidate vendors is easy enough. Trade shows, industry directories, magazines line Bank Marketing, online searches and recommendations from industry peers should quickly identify many alternatives. Narrowing the list is harder: it often takes a consultant familiar with the vendors and banking applications to know which features are needed to meet your goals and, of those, which are hard to find. (Important features that are shared by everyone don’t provide a basis for differentiation.) If hiring a consultant is not an option, then spend some time reviewing a few of the major products, using your scenarios to ensure you drill down deeply enough to see how they differ in the details. Once you get a clearer picture of what’s common to all the products and what’s not, you can distill a small list of pointed questions to ask a larger set of candidates, and use this to quickly identify those who best fit your needs. You’ll then want to explore this small group in full detail, having them walk through your scenarios and the associated issues in depth.

Although every stage of the selection process should be methodical, it’s particularly important that the detailed vendor evaluations be conducted in a highly structured fashion. This ensures you gather the same information from everyone and are not distracted by ultimately irrelevant factors such as the quality of the salesperson on your account. Develop a list of important factors and then build a questionnaire with the specific information about features, technology, support, pricing and company background that you need to assess those factors. Some answers can be gathered verbally or through a written Request for Proposal. Others will come from your scenarios: write these up, provide them to the vendors in advance, and have the vendor show you exactly how their product would be used to meet the scenario requirements. Have your own technical experts meet with the vendor’s technical staff to discuss integration, platform, implementation and other issues that cannot be part of a demonstration. Prepare an evaluation form related to the scenarios and have your team members fill it out immediately after each vendor conference.

Request a users manual and review it in depth. Make good use of reference calls, which are often underexploited. How long has the reference been a customer, what are they doing with the software, how long did it take to deploy, what technical resources did they bring to bear, were there any surprises positive or negative, which other vendors did they consider and why did they choose this one? Have the vendor find references that are as similar to your situation as possible, and be very concerned if they can’t find anyone who is a near match.

Once you’ve gathered all this information on your short list of vendors, meet with your selection team. This meeting is an important part of the selection process because it both educates team members and builds consensus around the final choice. The meeting is structured around your list of important factors. The first task is to assign weights to the items on the list: the weighting discussion can be frustrating at first but helps the team to clarify the issues and priorities. Then convert the list to a matrix and assign scores to each vendor for each item. This also tends to go slowly at first, but moves faster once the team gets the hang of it. It can help to have everyone assign their own scores in advance and then to work through the matrix, stopping only at the points where there is significant disagreement. But the actual scores are less important than the discussion, so you don’t want to move too quickly. By the end of the process, there is often an obvious winner. Even when there is no single clear choice, the matrix usually shows that there are just a couple of key differences between the major competitors. This allows the team to focus on those areas in depth, either by reassessing their relative importance or analyzing more closely how the vendors truly differ. In some cases it may be necessary to go back and get further information to clarify matters.

A mechanical, but still significant, benefit of the matrix is it gives a nice piece of documentation to present to senior management to explain the reasoning behind the team’s decision.

Of course, the selection process is not really over until you have a signed contract with the chosen vendor. You may choose to negotiate with several vendors simultaneously to get the best prices before making a final decision. Bear in mind that CRM today is a fairly mature technology, so there are likely to be several vendors who meet your needs. The real goal of the selection process is to find one of them and move on to gaining the business benefits of deployment, not to make the selection process an end in itself.

* * *

David M. Raab is a Principal at Raab Associates Inc., a consultancy specializing in marketing technology and analytics. He can be reached at draab@raabassociates.com.