In this, the first of this series of articles covering the various aspects of the Single Customer View I would like to very briefly look at the origins of the beast and also introduce some of the components of a Single Customer View solution that must be considered in order to ensure a solution that is fit for purpose.
The notion of a Single Customer View or Single View of the Customer as it is often referred to is not new. For as long as we have been engaging digital methods to communicate with customers and prospects there has always been a requirement to identify where we have multiple instances of the same individual.
One of the original primary motivations was to ensure that we didn’t send multiple communications to the same person. Back in the days of Direct Mail (or dare I say Junk Mail) the receipt of duplicate mailings coming through your letter box was one of the biggest complaints aimed at the industry, along with the non-targeted nature of the offer but more on that later.
Along side the marketing requirements to identify duplicates within a collection of customer / prospect data was the requirement to check the creditworthiness of prospective customers. Hence the origins of the credit reference agencies. Here the basic requirement was to take a credit application from an individual and to check by electronic means to see if that person existed on a list of people provided by lenders and if so to make a decision as to whether they were a good or bad risk.
The underlying capability required by both of the above was and is the ability to identify matches between or duplicates within data sets. In other words the availability of a Matching Engine. This can be simple or extremely complex depending on the definition of the customer, the underlying data and the risks involved, but more on that in subsequent articles. For now its worth stating just what a duplicate is:-
- Duplicates are where we have multiple digital representations of the same real world entity.
The ability to identify duplicates in order to delete them or make a credit decision soon led to other ideas. If we can identify matches we can pull together data from multiple sources and combine it to create a “Golden Record”. Obviously the more complete picture we have of an individual customer the better we can manage our relationship with that customer. When did we first hear the term CRM? And the explosion in data volumes over the years has led to the rise of data science again with the fundamental requirement that we can identify where data belongs to the same entity.
The requirement to identify duplicates by means of software applications led to the emergence of numerous providers who recognised the value in such a capability and have invested heavily in the development of such solutions. So it would be nice to think that, were you to require a Single Customer View all you need to do is choose a vendor and off you go. But as we well see in future posts, success is may not be so easy to achieve.
The reason why Single Customer View projects are so difficult is simply because they can become very complex.
At the lowest level (in the Matching Engine), deciding whether two digital records do in fact belong to the same individual can be an extremely complex thing for a computer to do and we will talk about this in subsequent blogs. Suffice to say I have yet to see any solution that cannot make a mistake. Because it is so complex many vendors will try and hide this complexity from their customers, often by claiming to provide “a simple interface that puts you in control”. Be wary.
Given that match engines will make mistakes, getting a business to accept that there is a risk-reward trade off in building a Single Customer View is tricky to say the least.
In larger organisations different departments will have different views as to what constitutes a customer. Getting agreement can be difficult.
There is an old saying – “you can’t make a silk purse out of a sows ear”. This is very true when it comes to data. Poor quality data (inaccurate / incomplete) can make aspirations for an accurate Single Customer View very difficult. And tackling data quality is known to be a mammoth task in its own right.
And it is important to think ahead. Its tempting to think that if we can agree on how to match and identify our duplicates then job done. But what about changes in the data? What happens when somebody moves house or changes telephone number or gets a new email address? And what happens when we discover that that solution we just bought has made a mistake – what are the consequences and how do we correct it?
More often than not the solution involves integrating third party software (the match engine) into existing operational IT systems – again something fraught with difficulties and resistance. Building a Single Customer View is one thing. Making at accessible and usable is another.
I hope to cover these issues and more in subsequent posts. Some of these may get a little “technical” but I will always use plain English.
In my next post I will outline the advantages to be gained by implementing a Single Customer View within a business.