Customer Incognita
Jim Harris in Associations, Blogs, Books, Data Quality, Methodology tagged Data Matching, Data Quality Pro, Jill Dyché Tuesday, November 3, 2009 at 9:13PM Many enterprise information initiatives are launched in order to unravel that riddle, wrapped in a mystery, inside an enigma, that great unknown, also known as...Customer.
Centuries ago, cartographers used the Latin phrase terra incognita (meaning “unknown land”) to mark regions on a map not yet fully explored. In this century, companies simply can not afford to use the phrase customer incognita to indicate what information about their existing (and prospective) customers they don't currently have or don't properly understand.
What is a Customer?
First things first, what exactly is a customer? Those happy people who give you money? Those angry people who yell at you on the phone or say really mean things about your company on Twitter and Facebook? Why do they have to be so mean?
Mean people suck. However, companies who don't understand their customers also suck. And surely you don't want to be one of those companies, do you? I didn't think so.
Getting back to the question, here are some insights from the Data Quality Pro discussion forum topic What is a customer?:
- Someone who purchases products or services from you. The word “someone” is key because it’s not the role of a “customer” that forms the real problem, but the precision of the term “someone” that causes challenges when we try to link other and more specific roles to that “someone.” These other roles could be contract partner, payer, receiver, user, owner, etc.
- Customer is a role assigned to a legal entity in a complete and precise picture of the real world. The role is established when the first purchase is accepted from this real-world entity. Of course, the main challenge is whether or not the company can establish and maintain a complete and precise picture of the real world.
These working definitions were provided by fellow blogger and data quality expert Henrik Liliendahl Sørensen, who recently posted 360° Business Partner View, which further examines the many different ways a real-world entity can be represented, including when, instead of a customer, the real-world entity represents a citizen, patient, member, etc.
A critical first step for your company is to develop your definition of a customer. Don't underestimate either the importance or the difficulty of this process. And don't assume it is simply a matter of semantics.
Some of my consulting clients have indignantly told me: “We don't need to define it, everyone in our company knows exactly what a customer is.” I usually respond: “I have no doubt that everyone in your company uses the word customer, however I will work for free if everyone defines the word customer in exactly the same way.” So far, I haven't had to work for free.
How Many Customers Do You Have?
You have done the due diligence and developed your definition of a customer. Excellent! Nice work. Your next challenge is determining how many customers you have. Hopefully, you are not going to try using any of these techniques:
- SELECT COUNT(*) AS "We have this many customers" FROM Customers
- SELECT COUNT(DISTINCT Name) AS "No wait, we really have this many customers" FROM Customers
- Middle-Square or Blum Blum Shub methods (i.e. random number generation)
- Magic 8-Ball says: “Ask again later”
One of the most common and challenging data quality problems is the identification of duplicate records, especially redundant representations of the same customer information within and across systems throughout the enterprise. The need for a solution to this specific problem is one of the primary reasons that companies invest in data quality software and services.
Earlier this year on Data Quality Pro, I published a five part series of articles on identifying duplicate customers, which focused on the methodology for defining your business rules and illustrated some of the common data matching challenges.
Topics covered in the series:
- Why a symbiosis of technology and methodology is necessary when approaching this challenge
- How performing a preliminary analysis on a representative sample of real data prepares effective examples for discussion
- Why using a detailed, interrogative analysis of those examples is imperative for defining your business rules
- How both false negatives and false positives illustrate the highly subjective nature of this problem
- How to document your business rules for identifying duplicate customers
- How to set realistic expectations about application development
- How to foster a collaboration of the business and technical teams throughout the entire project
- How to consolidate identified duplicates by creating a “best of breed” representative record
To read the series, please follow these links:
- Identifying Duplicate Customers (Part 1): Introduction
- Identifying Duplicate Customers (Part 2): False Negatives
- Identifying Duplicate Customers (Part 3): False Positives
- Identifying Duplicate Customers (Part 4): Best Practices
- Identifying Duplicate Customers (Part 5): Duplicate Consolidation
To download the associated presentation (no registration required), please follow this link: OCDQ Downloads
Conclusion
“Knowing the characteristics of your customers,” stated Jill Dyché and Evan Levy in the opening chapter of their excellent book, Customer Data Integration: Reaching a Single Version of the Truth, “who they are, where they are, how they interact with your company, and how to support them, can shape every aspect of your company's strategy and operations. In the information age, there are fewer excuses for ignorance.”
For companies of every size and within every industry, customer incognita is a crippling condition that must be replaced with customer cognizance in order for the company to continue to remain competitive in a rapidly changing marketplace.
Do you know your customers? If not, then they likely aren't your customers anymore.
View Printer Friendly Version
Email Article to Friend
Reader Comments (8)
Good post, Jim. It takes a special guy to throw SQL, a bit of Latin, and the following quote into the same post:
Some of my consulting clients have indignantly told me: “We don't need to define it, everyone in our company knows exactly what a customer is.” I usually respond: “I have no doubt that everyone in your company uses the word customer, however I will work for free if everyone defines the word customer in exactly the same way.” So far, I haven't had to work for free.
Thanks Phil,
My mother always told me that I was "special" - but she didn't always mean it as a compliment ;-)
Best Regards...
Jim
Since you've declared today national comment day...
I agree that if you drill further into the business definition of a customer without even getting technical, it usually starts to get blurry.
Would it be someone who has purchased something from you? If so, what are the time limits? Is a customer someone who bought something from you ten years ago? Is it someone who bought a $.10 part and nothing else? Is it someone who bought something from a company you just acquired? What about someone who bought something and never paid?
Henrik's point about complex names often comes to light like this. Is "Mary and John Smith" one customer or two? Bankers may wonder how many customers are in the name "Steven and Vanessa Smith MUTMA John Smith" It's not easy.
To really define this, you need to understand to some degree both the history of the data and its future use. This will put the data into context and make it more powerful.
Steve,
First of all, thanks for celebrating National Comment Day!
Excellent points about the difficulties of equating a customer with a purchasing event.
In his book Viral Data in SOA: An Enterprise Pandemic, Neal Fishman discussed the challenges of "indirect customers" where (using an automobile industry example), a manufacturer sells the vehicle to a distributor and the distributor in turn resells the vechicle to the recipient. The manufacturer is normally interested in both the direct customer (the distributor) and the indirect customer (the recipient).
An additional example would be if I buy a Samsung television from BestBuy, am I a customer of both Samsung (indirect) and BestBuy (direct)? Perhaps, BestBuy shares my demographic details (name, address, etc.) with Samsung. But if they do not and I do not fill out and send in my manufacturer's warranty card, would Samsung even know about me?
Perhaps Retail is a bad example, since it is point-of-sale (POS) oriented, meaning that being a Samsung customer (direct or indirect) is not the same as being a State Farm insurance customer. State Farm receives monthly payments from me for home and automobile insurance. Therefore, I am a "recurring" customer for them in a much different way than a "repeat" customer for BestBuy if I buy techo-gadgets there on a weekly basis.
Best Regards...
Jim
Nice post Jim.
At the risk of boring you with a personal anecdote...
Several years ago I consulted with a utilities firm. They wanted to get a view of their top 20 customers. Bizarrely enough, they had gone merrily along for many years not knowing who their most profitable customers were, such is the impact of poor data quality.
When we aggregated their customers we found that in one instance there were 35 customer accounts relating to one organisation that they did a lot of business with.
An interesting dilemma was posed. Each customer account in this group could conceivably be called a separate customer. Each account related to a different division of a big organisation, there were different account contacts, addresses, order needs, service level requirements - each account was in fact quite distinct.
What developed was a real in-fight as to what constituted a customer. Different business units wanted these accounts to be grouped or left alone, it became quite a messy struggle in the end.
We found loads of other issues but what emerged was, as you point out above, organisations seldom have a unified view of what a customer means across the organisation. This is nothing really to do with single customer view or MDM, it's just a lack of data governance.
Also, sometimes it's actually perfectly valid for different parts of the organisation to have a different perception of what a customer is.
It's a continuous debate in my organisation. When you sell products or policies in my case to customers as an 'agent' for a 3rd party e.g. a bank, it gets quite messy.
Is the customer yours, or is it the bank's or both, are prospects customers, because they are a already a customer of the bank??? Until we started down the MDM route I am not sure we had a concept of customer, and if you speak to the commercial side of the business, you will probably still get different definitions.
Perhaps this is an example of the 'single version of the truth' vs 'shared version of the truth'.
Damn, I've shown my cards there ...
Listening to inter-company definitions of "customer", always provides a deeper insight into business process and typical fractures in an organization.
One recent project where this came to light, was in the travel/hospitality sector. Imagine this...
"Acme Travel Agency" purchases a reservation at "Hotel Superior" on behalf of "Sally Smith." "Sally Smith" is traveling on company business and her company exclusively uses "Acme" to book their business travel. Sally is attending a quarterly meeting of her company's ("Megla Corp") sales organization at this very same hotel. Her company rotates the cities of these quarterly meetings, but usually uses the conference facilities of "Hotel Superior" and most of the attendees stay at the hotel for a night or two. One more complication, "Hotel Superior" is one of about 2,000 property franchises of "Inter Galactic Hospitality."
There is 10+ customer relationships above.
Who the heck is "Inter Galactics's" customer? Is it Sally since she is a guest? Or maybe Sally's company because they utilize conference facilities? How about the travel agency, surely they are a customer who needs to be cultivated.
Try to satisfy the above in a vanilla CRM system!
Jim
Great post which has triggered a deluge of thought provoking comments.
Back when I was with the phone company I was (by default) the guardian of the definition of a "Customer". Basically I think they asked for volunteers to step forward and I was busy tying my shoelace when the other 11,000 people in the company as one entity took a large step backwards.
I found that the best way to get a definition of a customer was to lock the relevant stakeholders in a room and keep asking "What" and "Why". My "data modelling" methodology was simple. Find out what the things were that were important to the business operation, define each thing in English without a reference to itself, and then we played the "Yes/No Game Show" to figure out how that entity linked to other things and what the attributes of that thing were.
Much to IT's confusion, I insisted that the definition needed to be a living thing, not carved in two stone tablets we'd lug down from on top of the mountain. However, because of the approach that had been taken we found that when new requirements were raised (27 from one stakeholder), the model accommodated all of them either through an expansion of a description or the addition of a piece of reference data to part of the model.
Fast-forward a few months from the modeling exercise. I was asked by IT to demo the model to a newly acquired subsidiary. It was a significantly different business. I played the "Yes/No Game Show" with them for a day. The model fitted their needs with just a minor tweak. The IT team from the subsidiary wanted to know how had I gone about normalising the data to come up with the model.
Which is kind of like cutting up a perfectly good apple pie to find out how what an apple is and how to make pastry.
What I found about the "Yes/No Game Show" approach was that it made people open up their thinking a bit, but it took some discipline and perseverance on my part to keep asking what and why. Luckily, having spent most of the previous few years trying to get these people to think seriously about data quality they already thought I was a moron so they were accommodating to me.
A key learning for me out of the whole thing is that, even if you are doing a data management exercise for a part of a larger business, you need to approach it in a way that can be evolved and continuously improved to ensure quality across the entire organisation. Also, it highlighted the fallacy of assuming that a company can only have one kind of customer.