“We don’t necessarily discriminate. We simply exclude certain types of people.”
– Colonel Gerald Wellman, ROTC Instructor
No hilarity or bon vivant, off-the-cuff humor this week, guys. No, sir. We’re going to dig into the topic of banks and CRM, because it’s on everybody’s mind these days. So take a deep breath and bear with me.
A couple of years back, the whole conversation about CRM started with banks not really being able to define exactly what CRM was, but saying that they had to have it. Many vendors responded by saying that they already supported the yet-to-be-defined system needs with current functionality. Frankly, in the early days this combination caused more confusion than progress.
Recently, though, we have seen real movement. Banks, for their part, have come to understand that CRM is probably 10%-20% a technology concern, with myriad issues including products, culture, incentives, organization, training, and planning comprising the largest and most important pieces of an overall CRM strategy. Vendors, in the meantime, have begun taking some serious steps toward offering integrated CRM systems. Here are some recent cases in point:
This list is hardly comprehensive. Every vendor has had a build, buy, or partner strategy for CRM. And these efforts again exposed an issue banks and vendors are going to have to settle as part of the evolution of CRM systems: data management.
First, some background. Full-scale CRM involves a lot of data from a lot of different sources. At the risk of oversimplifying, I will break it down into five general categories:
1. Customer data
This is the personal and demographic information on a customer. It includes the traditional CIF-level information (name, address) and other demographic data drawn from internal and external sources – e.g., buying habits. It covers both individual and corporate customers, and includes both personal and household information. Generally, this also includes information on which bank employee is assigned to which customers – e.g., personal banker. For loan customers, it also includes a great deal of financial data such as corporate income statements, collateral, and other credit data.
2. Transaction data
This is the information on transactions customers conduct with the institution. It reveals when and where they access products and services.
3. Contact data
As opposed to transaction history, this information encompasses non-transactional contacts, such as calls made by sales representatives, mailings, customer requests for information, and any number of other marketing or service-related contacts. Generally, this is where information on prospects is housed.
4. Employee sales history data
This information discloses how much an employee has sold, to whom, against what goal, and resulting in what type of bonus or commission.
5. Profitability information
This can encompass information on customer, household, and product profitability. A fair amount of information needed to allocate income and costs can be required here.
Now, at this point, many of you are thinking that this breakout of information is illogical because customer, contact, transaction, sales, and profitability information are not separate components, but part of a single design. And, if we were all designing and buying systems from scratch, I would agree. But the fact of the matter is that every bank has already invested in and relies heavily on multiple, disparate systems that each house one piece of the CRM information puzzle. Let’s go through our five categories and see where this data resides today:
1. Customer data
Customer data is stored partly in core CIF systems, but also in loan origination systems (and financial statements don’t ever get sent to the core system). Information for trust or brokerage customers can conceivably be part of the bank’s core CIF system, but usually isn’t.
2. Transaction data
Transaction data is usually stored on the core system – whew! There’s one problem solved, anyway.
3. Contact data
Contact data can be in several places – branch sales systems, call center systems, loan origination systems, Outlook, and sales systems such as Act!
4. Employee sales history data
Employee sales data is usually in the loan or branch system used to originate the account. Oftentimes, sales goal attainment and sales incentive information is in Excel or only on paper.
5. Profitability information
Rudimentary profitability information might be calculated and stored in a branch or loan sales system, but can also be in MCIF or stand-alone profitability systems like Profitstar or Sendero.
In other words, we are not designing CRM from scratch. We are, in fact, interfacing and retrofitting many existing fulfillment and analysis systems into new CRM strategies. And this retrofitting and integration will be a fact of life for the foreseeable future. The truth is, there is no single “holy grail” system that will be, as Dan Akroyd once said, “a dessert topping AND a floor wax” (i.e., that will solve all data and fulfillment issues) — and there won’t be one for a long time.
So how do we manage CRM data in an environment of multiple processing systems and multiple points of data? At this point, vendors have followed different directions. Some have made their data warehouse product the gathering and distribution point for all customer data, and some have begun using the warehouse as the place that combines customer information from banking systems and non-bank systems like trust or insurance. Many now require purchase of their data warehouse solution with core systems. This is a more comprehensive, more flexible, and more expensive design.
Others vendors are keeping their core CIF systems as the customer data repository and interfacing with the databases used in the sales and fulfillment systems when additional data is required. This has the advantage of being less costly, but it can also be less flexible and harder to change.
Which approach is right for your bank? Both strategies can work, based on your needs. Start by asking yourselves these questions:
1. How much data needs sharing?
Some banks have strategies and cultures that require branches, lenders, call centers, and non-bank subsidiaries to share detailed customer data. In other banks, particularly ones with focused niches, less integration may be needed. Recognize, though, that the more integrated information is required, the more a single, integrated data warehouse solution is required. And the key to determining the level of required integration is first knowing what business need will be served by the integration. Integrating data, then deciding what to do with it, is too expensive and time-consuming.
2. How often does data need to be refreshed?
In theory, everybody wants up-to-the-minute data. In reality, this can be very costly and provide no benefit. Is there something specific the bank can do with today’s credit card or brokerage balance, as opposed to the end of last month’s, or two weeks ago? If there is, define what it is. Again, the more often data needs refreshing, the more some kind of overall data warehouse strategy will be required.
3. How many “best of breed” fulfillment systems does your bank need?
A hard truth: A “best of breed” system strategy (loan origination, branch, call center, contact management) and an integrated CRM data strategy conflict, since every unique system and vendor is another set of interfaces to manage and update.
Another hard truth: There is no single fulfillment system that meets everybody’s needs. Banks and vendors need to negotiate resolution of these conflicting issues. Banks need to recognize that best of breed environments will increase the cost and complexity of CRM data management. Vendors need to be both willing and able to integrate third party systems into their CRM offerings when banks require it.
These are three examples of issues banks and vendors need to address as part of a dialogue that balances real business needs with the reality of system costs, technology limitations, and time to market. And it still starts with the bank’s strategy and business needs. The right dialogue about these things will create the right design.
So start dialoging and designing.
-tr