CRM, Fulfillment, and the Coming Design Debate

CRM, in some form or fashion, is on the project list at almost every bank in 2004. This is true despite the fact that most banks don’t yet have a fully developed big picture of what CRM systems and delivery will look like. What they do know is that there has to be better access to customer information, front line employees need better sales and fulfillment tools, compensation needs to be tied more closely to sales and service, and systems need to be better integrated to accomplish this.

The vendor market has not been unaware of this nor has it been idle. As we have discussed previously, most every core vendor has invested in some CRM solution. Several have purchased stand-alone CRM systems that they are now integrating into their delivery systems (Metavante/Onyx and Jack Henry/Synapsys are two examples). Some have focused more on internal design and development, but even here it has usually been with a separate toolset, database, and design team than is used on branch, call center and lending delivery systems (e.g., Fiserv/CSCS, OSI/cView).

Now, there were valid reasons CRM and delivery systems were designed differently. At the risk of oversimplifying, CRM systems were designed with marketing campaigns, sales tracking, and customer analysis in mind. Fulfillment systems (loan origination, call center, branch new accounts) were designed with decisioning, closing, and documents in mind. They were designed by and for different parts of the bank, by different vendor teams, and at different times.

But here’s the rub. It’s now 2004, and before banks can really be successful at CRM, all of these these systems have to mesh and work together. To a large degree, they don’t – yet. And banks and vendors haven’t really negotiated the tough details of how they will.

Now, some readers, particularly vendors, will immediately claim that I’m on one of my 1969-era Berkeley flashbacks (they don’t happen that often any more.really). But let me tell you, based on our involvement in dozens of system selections last year and me planting my rear end in the seats at demos with bank users, what the buyers see:

• CRM and fulfillment systems are often proposed by separate companies or business groups.
• They are almost always priced separately, with the CRM component priced optionally.
• They are demonstrated by different people, nearly every time from different business groups, in different sessions during the day.
• The person demonstrating the loan and branch fulfillment systems never talks about campaign or sales management.
• The person demonstrating CRM doesn’t know how an account gets opened, a loan gets funded, or a document gets printed.
• They both say that workflow management occurs in their system. For example, I recently saw a CRM demo to a fairly large bank in which the presenter told lenders that the CRM system could be used to manage the loan application, decisioning and origination process. Seriously, there’s a better chance that my 15-year-old will ask me to chaperone her on her first date than of that happening (by the way, she terms that possibility “sub-zero”).
• They both talk about contact management.
• They both talk about sales tracking.
• They both talk about to-do lists.
• The systems almost always look/feel different and require separate user profiles and sign-ons.
• Nobody talks with any specificity about how the incentive tracking and payment system gets automated.

In summary, the proposed solutions still look too disjointed for banks to base their long-term relationship strategy on them.

The net result, most of the time, is that people like some of the features of both systems, but they don’t really feel that either is yet designed with a viewpoint of what they really do all day.

To be fair, this may be the point at which we should expect to be, given that large-scale design of CRM sales and delivery systems is still in the early stages. Regardless, we have hit the point where sales management workflow and fulfillment workflow need to be seriously and specifically negotiated as one big discussion. For example, let’s take the issues already mentioned. I suggest that any future design of integrated CRM systems address these questions:

• Will all bank employees use a single contact management system? If so, where will it be? Right now, it’s probably in Outlook or Act.
• Where will employees keep their follow-up or to-do lists? This means anything from a sales opportunity two months out, to getting an updated UCC, to a dentist appointment.
• Where’s the one place employees will track and report sales?
• Where’s the place all customer demographic and personal information will be kept or assembled?
• Will the answer be the same across the bank – i.e. will a single solution be the answer for branches, mortgage lending, and mutual funds sales groups? More importantly, for what groups should a common solution be mandated?
  The underlying theme here is that the next round of CRM system design and integration has to take into account the practical aspects of how people spend their days, how they move from sales to service to administrative tasks, and how they take the easiest route to do it.

No system design would be complete without some Gonzoesque spin and flavor, n’est pas? Oui. So, here are three practical design principles I suggest be factored into the next phase of CRM:

1. People spend at least 80% of their time in one system, and that’s not going to change. Whether it’s a new account system, mortgage origination, commercial servicing, or accounts payable, almost every bank employee relies heavily on one key system. They are not going to embrace any design that requires regular use of two or three. Where they prospect, they have to fulfill. Where they fulfill, they have to track next steps and report sales results. That’s how people work. To draw an analogy, here’s a question for administrative employees and executives – how many of you would use one program to send an e-mail, a second system to track that you did, and a third to remind yourself to check tomorrow and see if it was received? Right. Me neither. So why do we think front-line contact employees will?
   
   
2. Systems need to be designed by customer contact staff as much as they are designed for them, and they therefore need to be designed front (branch, call center deployment) to back (admin). I swear every CRM description or demo I see starts with a premise like this: “Let’s say you want to identify customers with a certain profile and want to create a marketing campaign to them.” Instead, I suggest the premise be this: “Let’s say customer sales or service reps sign on and needs to organize their entire day, and they need a system to help them do it more easily.” I guarantee design will be different, because the No. 1 thing sales and service people will design for is speed and simplicity. Disagree? Then bring in your five best sales and service people and ask them what they need to do their jobs.
   
   
3. There are different levels of need to “share” information that banks must negotiate. I know that in theory any employee should be able to refer any customer to any other part of the bank, and any employee should see every contact that a customer has with the institution. But, in truth, there are certain groups that will share customers and fulfillment processes regularly and have a “home run” opportunity with a common CRM/fulfillment system. There are others that, in reality, share customers so little that shared systems make no sense, at least not in the next phase of CRM deployment. Here are some examples of what I mean:
   • Branches, call center, direct consumer lending – non-negotiable need to share customers and CRM systems
   • Branches and wealth management – very possibly, depending on strategy and markets
   • Commercial lending and branches – maybe, depending on strategy and markets
   • Indirect lending and wealth management – probably not

My point is that there may be a classic 80/20 rule here – getting the right 20% of groups on a single design may provide 80% of the integrated sales and service benefit. Let’s aim the next round of design at that.

The theme is clear – if the right blend of relationship management tools, fulfillment capabilities, and practical workflow exists in next-round design, everybody wins.
-tr