Bridging the Channels

By Lauri Giesen

New technical solutions might finally bridge the internal gaps in customer information, giving CRM a boost.

The Holy Grail of retail banking over the past decade has been to deploy in-depth and updated customer information at every point where customers contact the bank. In the ideal world of customer relationship management, or CRM, representatives dealing with a customer at the call center would know, for example, not to pitch mutual funds to a customer when that customer had rejected the same offer at a branch the day before.

The reason banks rarely enjoy this level of comprehension in the real world is quite basic: the computer systems that hold the data for banks' various delivery channels often don't talk to each other. That means information captured by a branch employee might not be available to someone in the call center, and vice versa.

The problem is simple to describe, but fixing it is has been anything but simple. Most large banks have only recently figured out how to provide consistent account balance information to their customers, whether those customers request that information at an online banking site, an ATM or a call center. Many institutions still can't distribute an address change throughout their entire system.

And if a bank can't handle these simple data exchanges, it's unlikely it will be able to accomplish something as sophisticated as a CRM program deployed through all its delivery channels.

This has strategic implications. All of the interactions a customer has with a bank must be consistent if the bank wants to serve customers well and sell them additional products. "It's all about getting the right information to the right people at the right time. It's making sure your support staff has the information they need to communicate with customers in a meaningful way," says Leah Rubenstein, senior vice president and chief information officer for distribution at branches and call centers for Pittsburgh-based PNC Financial Services Group Inc.

Banks have tried to solve this problem with conventional "middleware" applications, in which one server consolidates data from the various legacy systems — credit card accounts, deposit accounts, investment products, loan products, etc. That information can then be analyzed as part of the CRM program, with conclusions pushed through the various delivery channels.

While middleware has been useful up to a point, it often falls short of complete integration. The information is typically stale by the time it has been gathered and integrated. Also, information tends to flow in one direction only — from the various product departments into a central file and then to the delivery channels. For the data to be meaningful, a reciprocal flow is needed, with constant updates relayed back to the central file, both from the product departments and customer contact personnel.

For that reason, some large banks are starting to look at the next generation of enterprise solutions and Web-based services, which provide more robust and timely two-way communication between the delivery channels and the computer system holding the customer information files. While much of this technology is still in test mode, the new offerings seem to have promise. Interest is also being shown in new "front-end" systems that do a better job of facilitating voice and data flows throughout the company.

Whatever technical solution is chosen, experts say, achieving robust data integration should be at the top of retail bankers' to-do lists. Without computer systems that can talk to each other and actually share data in real time, every CRM effort will fall short.

Data Silos

Under an ideal scenario, CRM should work the following way: A marketing department blends customer demographic information with information about that customer's accounts and transaction history to determine what products the customer is likely to want.

This information is then shared with all the institution's various channels, so that, for example, a customer waiting for cash at an ATM might be asked if he or she is interested in a car loan. Or, the next time the customer called the call center to inquire about an account, the call center rep would know which products to pitch while the customer is still on the line and in the mood to talk about financial issues. The goal is to make the same information available at the same time across the institution.

In practice, "most banks' CRM efforts have been silo-oriented," says consultant Charles Bruney, senior vice president at Atlanta-based Speer & Associates. Information about a customer's accounts and interactions with the bank sit in separate, distinct information "silos" that are not connected. "You may have a CRM initiative that results in a marketing effort by the call center, but the marketers are not sharing that information with the other channels," Bruney says.

The silo problem has been most troublesome for large banks that operate multiple, unconnected legacy systems, typically patched together after acquisitions. Community banks and credit unions, by contrast, typically either stored much of their customer data in the same system from the beginning or had it integrated for them by outside processors, according to Kathleen Khirallah, senior research analyst for TowerGroup, Needham, Mass.

Recognizing the need for integrated databases, large banks began moving as early as the 1980s to set up customized customer information files where all the accounts and interaction customers had with the bank could be pulled together into one file. Unfortunately, "the systems were pretty rigid," says Steve Bacastow, co-founder and partner of Collective Dynamics, an Atlanta-based consulting firm. "At best, you got a snapshot of a customer. The technology was not robust enough to compile and dispense live and up-to-date information."

The problem with these middleware applications, Bacastow explains, is they usually lack reciprocity. Information flows from the server to the delivery channel, but not the other way. If, for example, a customer inquired about an existing account or discussed opening a new account at a branch, information about the customer was sent from the middleware to the branch personnel, but the branch could not update the data for transmission back to the middleware server.

During the last decade, banks contemplated taking their data integration efforts further. But in many ways, the situation actually got worse, according to Bacastow. "As banks merged and consolidated in the '90s, there were even more systems patched in. It was nearly impossible to get a single view of a customer." As banks struggled to integrate the databases of multiple financial institutions, they were also adding new delivery channels, such as the Internet, and new product lines, such as insurance and investment products. This caused segregated databases to multiply.

Efforts to integrate customer information got pushed to the back burner in the late '90s as banks focused on Y2K, the millennium date changeover. Shortly after the new decade began, a weakening economy brought cost control to the fore and integrating data systems fell from the top of information technology budgets.

Web Services

Expectations of an improving economy down the road now allow banks "to turn their attention back to increasing revenues and cross-selling products," says Speer's Bruney. Having an integrated CRM system across all delivery channels should help banks accomplish those goals by facilitating more targeted marketing campaigns that result in higher response rates. But getting there will require improvements to the old middleware applications.

PNC, for example, utilizes a system that Rubenstein describes as "two-thirds" of the way to providing an integrated CRM strategy. Currently, PNC uses an IBM RS/6000 server to store and move data from a CRM system developed by Siebel Systems Inc. That technology is then assisted by IBM's MQSeries messaging software, which brings in customer and transaction information supplied by PNC's internal software systems.

The technology gives call centers and branch employees access to the same data. Furthermore, each party knows of the interactions the other has had with a customer. PNC can then take advantage of the integrated databases for cross-selling. A next step for PNC will be to apply this integrated data approach to its loan applications. Then, when customers apply for loans online, they would be able to phone a call center or visit a branch to discuss the status of their application.

Is this kind of middleware solution sufficient to handle the challenges of CRM? Some outside experts claim these systems are limited by the lack of real-time, two-way communication necessary to keep data fresh and meaningful. "Most are not integrated with all the customer touch points. You still have stand-alone marketing campaigns based on these files where the other channels are left in the dark as to what is going on," Bacastow says.

PNC executives disagree, pointing out that the Siebel messaging system they're using in conjunction with the IBM platform does provide the necessary two-way communication. The Siebel system is XML-enabled, meaning it can accept messages written in extensible markup language, which is commonly used on the Internet. "It's not rocket science," insists Cathy Preuhs, PNC's vice president of management information systems. "Some banks prefer batch file exchanges, which won't be in real time. But information can be processed in real time with the right commitment."

But commitment must be backed with technological expertise, as PNC executives also point out that much of the technology utilized was not purchased off the shelf. And much of the integration could not have been achieved without customization and internal development of many of the core components.

Banks not up to performing considerable customization, however, may consider some newer technologies on the market. One is Web services technology, a different type of middleware application that creates Web-based communications standards so that disparate computing systems can effectively talk to each other. Using XML, this technology allows banks to identify and translate the content of electronic documents from legacy systems that previously could not communicate.

But given that Web services technology is less than two years old, many financial service executives believe it needs more time to develop. One problem is a multiplicity of communications standards, reflecting the tendency of technology vendors to develop applications that are incompatible with those of competitors. While some of the primary vendors are trying to agree on such standards, that will take time. "Until common standards arrive, institutions will continue to rely on tried-and-true development and integration approaches," says TowerGroup analyst James Eckenrode.

Although Web services technology is still largely experimental in the U.S., Eckenrode notes that Swedish banks, using a Sun Microsystems product, do appear to be having some success. And while the big U.S. rollouts are still about two to three years away, he is projecting U.S. retail banks will spend about $1.8 billion on these systems by 2005, up from $242 million last year.

"Zero Latency"

Several large banks also are starting to look at the next generation of enterprise solutions, such as the Zero Latency Enterprise services offered by Hewlett-Packard Co. and others, according to Jay Desai, senior principal at Knightsbridge Solutions LLC, a Chicago-based consulting firm.

Whereas traditional middleware applications take information from legacy systems and move the data around, typically in a one-way stream, these enterprise systems allow for real-time, two-way communication, Desai says. Data not only can be called up by employees at the various delivery channels, but those employees can then update and change the data as new transactions and interactions take place. ZLE, as it's called, was initially used by large retailers to facilitate communication between corporate headquarters and the store network. Telecommunications companies also use it to handle customer service. Recognizing the potential for financial services, Hewlett Packard began marketing it to that sector in late 2000, according to Jim Olivero, H-P marketing manager in Cupertino, Calif.

"ZLE functions as a center hub. It doesn't replace anything, but it allows real-time integration of multiple data bases," Olivero says. The information is gathered so quickly, in fact, that some institutions have considered it for fraud detection as well as CRM integration. "The system could tell you that a particular customer could not possibly be using an ATM in Hong Kong because that same customer is at home at this moment paying his bills."

Olivero says H-P has done several installations of ZLE technology within financial services, but given the newness of these implementations, none of the users are willing to be identified.

Even as Web services technology and ZLE systems attempt to solve data integration problems at the "back end," or in the back office, there is some discussion in the industry about the need to look at "front-end" systems, or those that interface with the customer. "Many branches are so antiquated that they can not effectively communicate with any middleware application," says Jin-Chul Kim, an analyst with Meridien Research Inc., Newton, Mass. "Most are using frame-relay systems for running analog dialogue."

This requires separate lines for voice and data communications, resulting in a communications infrastructure that is costly to operate, support and maintain, Kim says. Frame-relay also relies on bandwidths that limit the ability to send large amounts of information to and from the branch computers.

Kim recommends that banks replace their old branch communications channels with an Internet Protocol or IP-based infrastructure and Web browser-based integration. "IP is the backbone that supports multiple applications. Leveraging a common set of connection standards will allow the branch to interoperate easily with all aspects of the new architecture."

In the end, most banks will need to carefully identify what information they need shared and how valuable it is to the institution to have each channel receive that information. Then they might want to examine some of the new technologies coming down the pike to improve data integration. Finally, they should give another look at the technology inside their branches and call centers to make sure it can support any changes in the back-end.

Ms. Giesen is a freelance writer based in Libertyville, Ill.

Copyright © 2003 by Banking Strategies, published by BAI.

back to top