Data quality was the key to Prudential's radical overhaul of its customer information systems. The results have been lower costs, greater efficiency and improved customer service
The Prudential built its reputation and turnover by providing financial advice and products to customers through an army of door-knocking salespeople. But since 2002 "the man from the Pru" has been replaced by automated channels and the IT department has had to find a way of maintaining a customer focus.
The result, the Single Customer View architecture, is being rolled out across the organisation and is an example of using data quality to yield business benefit. Single View is a mechanism for bringing together disparate product and account data relating to any customer and storing it in one place. This provides staff with an overview of all customers and their value to the company. It also provides a single point of contact for customers, a faster response to enquiries and quicker resolution of problems.
Since the £100m investment in Single View, there has been a 15% reduction in the number of customers not serviced by a single point of call.
The architecture has also enabled Prudential to consolidate its call centres, resulting in 20% savings, and it will play a key role in the company's "1,000-day plan" outlined by chief executive Mark Worth. This is intended to improve customer experience and to deliver cost savings of 40%.
Single View was adopted first by the customer services department to facilitate the more pivotal role IT has taken since since Prudential switched its focus from direct sales to intermediaries. Maintaining data quality and gaining a clear view of customer activity was the key to this department playing its part in the company-wide endeavour.
"We had to improve our first contact resolution rates to improve the experience of our customers and also the effectiveness of our call centres," says Jacqueline Lindsay, head of voice at Prudential.
Now many more customers have their problems sorted out with a single call by the first person who deals with them.
Increasing the efficiency of the call centres through economies of scale was the easy part. Over the years the Prudential had amassed 23 product-based call centres. "It was incredibly inefficient, but not untypical of a company that has grown through acquisition along product-centric lines," says Ally Thomson, lead application architect at PruTech, the Prudential's IT division.
Getting a grip on data quality in order to provide a service that was consistent and easy to use for customers and intermediaries proved the harder part. Call centres had unique processes for dealing with customers and storing data. Callers with multiple product queries had to deal with multiple support staff. Worse, from the business perspective, it was impossible to audit callers' journeys through different call centres in order to work out patterns of consumption.
While the customer service department was working out how to support customers and intermediaries better, marketing was dreaming up new ways to reach customers. Its wish-list included sophisticated campaign management and detailed information about all customers, including product information, e-mail and postal addresses.
Up-to-the minute customer profiles were becoming more important for all parts of the business. "A single view of the customer was required," says Thomson.
A board meeting decided that customer services would pay for the first tranche of the Single View project, although its benefits could eventually extend to the entire business. Four of the 26 legacy systems, or "contract engines", hosting product information were deemed strategic to the push towards intermediary business. They accounted for more than five million of the company's eight million customers and 80% of total business volume and became the subject of a massive data integration exercise.
"We took an architected, enterprise-wide view of the initiative. It was not easy to convince everyone, because architecture costs money upfront," says Thomson. The alternative was a well-known CRM package that was popular among the sales contingent because of its richer functionality. "There was a significant push from IT and the business to implement it," says Thomson.
However, tailoring the package would have been a nightmare, says Thomson, not only in terms of time and money invested for roll-out, but reapplying tweaks at every new version release. Crucially, the licence-per-seat option was significantly more expensive when the company looked at total cost of ownership.
Money aside, the in-house, bespoke option won because it offered a longer-term proposition that could support the entire company. This was a major decision because it contradicted the Prudential's principle of buying rather than building software.
The bespoke Single View comprised an Oracle database in which customer information relating to all products would be stored. The IT team also built a front-end application, called 4Front, in Java. This pulled Single View data into a number of customer service transactions within a single portal. Trillium Software and Informatica were selected as suppliers to respectively clean and migrate the data from the four contract engines.
Data cleaning was performed in parallel to the design of the system. The Prudential was clued up about the importance of data cleaning because of lessons learned from a previous data integration project. In 2001, two of its acquisitions, M&G and Scottish Amicable, integrated their mainframe systems and the problem of dirty data caught everyone by surprise. "It was one of the bigger issues," says Thomson.
IT was also a lot more geared up this time around. "There were enough people around from that time who understood we had to clean up the data before we integrated. In the M&G project it had been a laborious and mainly manual process. We knew we had to tool up to do it," says Thomson.
Two teams were set up to oversee the design and implementation phases of the Single View project. Customer services was in charge of the requirements analysis and agreeing the future standard in which customer data would be stored in Single View. This called for significant compromises by the participating business units and diplomacy on the part of customer services.
"Sometimes we felt like we were taking several steps back in order to get us all to the same place," says Lindsay. But they were able to steer the project because they were footing the bill. "Marketing had a similar set of requirements but was interested in different customer segments." Customer services' needs took priority on this occasion.
Single View called for compromise on the part of IT too. Thomson and his team had to depart from purist principles to deliver a product that provided optimum business benefit for the least cost.
"From the purist point of view, there should be a single, master copy of data that updates all other versions," says Thomson. This was impractical for the Prudential because of the massive cost of re-engineering legacy records hosted on the contract engines.
Instead, call centre staff input directly into Single View, which propagates these updates to the contract engines that feed it in real time. In tandem, a second feed of customer updates are received by the back office, chiefly in the form of paper correspondence and these are input into the contract engines. Once a day this data is matched against the Oracle database to update Single View.
Inherent in the peer-to-peer, rather than master-slave, relationship is the danger that data can get out of synch. "This can lead to all sorts of problems," says Thomson. The PruTech team wrote business rules to establish which source is the "master" where updates are in conflict. The relatively small number of updates executed by customer services staff and the fact that updates tend to come from only one source also minimises the risk of this occurring.
Aside from this weakness, the beauty of this system, says Thomson, is that it is scalable. Legacy contract engines can be added beneath Single View and other applications integrated with 4Front providing direct access to Single View.
As well as the cost savings gained from rationalising call centres, significant advantages accrue from making data quality a priority. "Clean, accurate customer data enables improved customer experience at the call centre," says Lindsay, and this is extended to paper correspondence too. A single view of the customers' relationships with the company means correspondence will be customer-focused rather than product-focused. "These aspects will all reduce mailing costs," says Lindsay.
Crucially, data quality is not regarded as a one-off clean-up operation but an ongoing exercise. Fresh data inputs are cleaned every day and duplications in the data on the contract engines and Single View are removed every week. The Prudential has a target of 98% accuracy for data in its systems. This is measured through a series of internal audits and is a key performance indicator.
Meanwhile, the advantages of investing in a long-term, scalable architecture are kicking in, with online customers earmarked to be the next beneficiaries of the Single View architecture. Data quality looks set to be the mainstay of the company's replacement for the man from the Pru.
How the Prudential ensures its data quality
Prudential did not embark on its automated project without first scrutinising the quality of its data. Good data was necessary to feed the Single View architecture and to comply with regulatory requirements.
Lessons learned from an earlier major integration exercise meant that Prudential decided to buy in specialist tools, rather than take a manual approach to record matching and data cleaning. Trillium Software was selected for the job.
Factoring data quality issues into the beginning of a project avoids stalling at a later stage when it would become necessary to decide who will deal with dirty data, and how.
"I have seen projects drift or, even worse, die on the vine because people have migrated data without understanding first how good or bad it is," says Ed Wrazen, vice-president of marketing, international, at Trillium Software.
Trillium automated the process of identifying exceptions and inconsistent data. Seeking out patterns of anomalies is important because it tracks errors back to poor processes or even individuals. Correcting this at source can interrupt a cycle of ongoing poor data input and reduce the need for data cleansing.
Once data was cleaned, the data quality system standardised the diverse data formats. It also corrected and enriched the information based on built-in country specific business rules by referring to Royal Mail Postcode Address File (PAF).
About 15.5 million policy records and 13 million customer records from the four key source systems were cleaned and compiled into 8.8 million unique customer records for loading into the Single View database.
The system then matched records based on Prudential's own criteria, which included forename, surname, postcode, national insurance number, date of birth and gender.