X

Audit9 Blog

Single Customer View

For many CRM implementations the production of a Single Customer View is a key success factor. The concept of consolidating all the information stored about a customer across the enterprise onto a single customer record is certainly compelling. This post provides a high-level coverage of the value proposition and challenges to be mitigated in delivering a Single Customer View project.

Definition

Firstly the term Single Customer View (or the 360º view variation) is ambiguous in nature and very much open to interpretation, it can mean essentially whatever you want it to. My own definition of Single Customer View (SCV) has two elements; firstly the single part meaning one only, no duplicates, the second element infers from the term view that a comprehensive and perhaps company-wide view of the customer is provided that is up-to-date. As such a SCV project has two main areas of focus; delivery of a clean, de-depulicated customer data-set and secondly to assemble as broad a picture of the customer from as many data sources as possible with the caveat that the each piece of data is in some way currently or potentially meaningful.

Component Parts

A SCV is typically, but not exclusively, comprised of three component parts;

Attributes – Individual data items (i.e. fields) such as Address, consolidated from one or more data sources.
Transactions – Transactional data such as Purchases, Complaints and Brochure Downloads, extracted from data sources and held in denormalised form.
Aggregates – Statistics calculated from both Attributes and Transactions to provide key summary information such as segmentation, customer rating, influence.

Utility

In consideration to the definition of a SCV and the tasks required in delivery it is imperative to understand the value proposition. In my view there are four primary areas of utility to be considered. The first of which being operational insight; in an increasingly connected world where customer interaction channels are emerging at an incredible rate, organisations that can apply an intelligent understanding of the customer at each touchpoint will benefit from good customer experiences and operational efficiencies, both in turn leading to competitive advantage. For example, consider a Service Agent armed with a current view of all purchases made, historic complaints and simple statistics (traffic lights, gold/silver/bronze images etc.) that perhaps indicate the year-on-year value of the customer to the company. It’s reasonable to imagine the improvement in the service experience delivered versus the agent only having the customer demographics to hand. The second area of utility is management information, if the SCV delivers customer-level aggregates then reports become possible across customers to identify trends and exceptions or to perform comparative analysis. This type of reporting is traditionally a data warehouse concern, however in most cases the data warehouse is implemented to deliver static reports and is disconnected from the organisation’s operational processes. A SCV implemented in the CRM layer should be focused on operational insight, with only essential information being incorporated. That said, the SCV is an incredibly valuable data asset and should be used to complement a data warehouse where possible, not necessarily to replace it. The third area of utility is the provision of a high quality customer data-set to the marketing department, or indeed any internal consumers of customer data. As with management information there is an overlap to consider, many organisation have a SCV established within their marketing automation platform, which again serves one purpose only. The fourth, and final, area of utility to consider is the ability to leverage the unique, multi-faceted insight delivered by the SCV to proactively drive business activity. In such scenarios, the SCV dataset is inspected by automated processes for conditions upon which action is required (Tasks and Opportunities for example). The list of actions is then prioritised in relation to business value and delivered to the end users to process. This often overlooked potential can be incredibly powerful in ensuring low-level activities align to strategic objectives.

The real utility of a Single Customer View established in the CRM layer is twofold; firstly competitive advantage through the combination of elevated customer service experiences and operational efficiency, secondly the SCV becomes a multi-purpose, open data asset to be consumed across the enterprise.

Challenges

The main challenges for any SCV project to consider are listed below. This is by no means an exhaustive list.

    • Master Data Management

In any context bringing together master data, such as customer records, from disparate systems is a complex challenge. Most organisations have yet to implement a comprehensive master data management strategy, and instead solve the issues that result from a lack of defined authoritative systems and associated processes on a per-case basis. This approach won’t scale well beyond limited integration scenarios.

    • Complex Integration Architecture

A SCV project will introduce a complex integration architecture requiring expertise, tools and processes lacking within the organisation. A complex integration architecture takes time to analyse and design; implementation can often be cost prohibitive.

    • Implementation Cost

An obvious challenge for any non-trivial project, however the timescales to implement a SCV project can be significantly greater than a pure CRM implementation, in many cases this is viewed as disproportionate. The additional time comes not only from extended scope and integration effort but also the time-expensive analysis required in collaboration with business users, and system owners, to understand the essential component parts of the SCV and the systems they can be sourced from.

    • Data Freshness

The credibility of any SCV implementation rests not only on the completeness of the picture but also the freshness of the data. Any unacceptable latency, perceived or otherwise, not only diminishes the overall utility but can also damage the success of adoption.

A good SCV implementation is not a one-off exercise, instead it becomes an ongoing pursuit of the perfect picture.

Delivery

The delivery of a SCV project should entail the following steps, common to most development methodologies.

    • Analysis

In my view the best approach is to start with a draft view of the final outcome, i.e. a low-fidelity sketch of how the SCV will appear. This sketch will then form the basis for conversation and requirements capture with the business stakeholders. It should be noted that the draft view may be discarded along the way, but for projects of this type communication can be greatly aided by a straw man proposal. A strong understanding of the systems landscape and enterprise data architecture should be established.

    • Design

The SCV design journey starts with a logical design encompassing the data sources plus the attributes and transactions to be drawn from each data source. An initial view on the aggregates should also be defined. The logical design should be complemented by a physical design which adds the implementation specifics. A comprehensive integration architecture encompassing both logical flow definitions and physical implementation detail must be documented.

    • Build

The SCV build should be incremental in approach, adding data sources and integration flows systematically to complete the picture. It is reasonable to assume that business users will identify additional requirements as they start to see the SCV picture emerge.

    • Test

Testing of the SCV implementation must be rigorous and comprehensive, with a view to early identification of both faults within the integration layer and also critically discrepancies in the data.

Once implemented a Single Customer View should be utilised wherever possible across the enterprise, to maximise the ROI, and be continually enhanced to maintain a high-level of business utility.

Tags:

About the Author

Mark Cane / Salesforce Certified Technical Architect