TLDR: If you want to retain and grow your customers, you’ll need to understand them first.  And “understanding” them will quickly lead you to your customer data.

What’s the one thing you must do to unlock the power of that data?

Customer data doesn’t live in one place

Despite claims to the contrary, there is no single system where your customer data lives.  Rather, it’s spread across many systems.  Some examples:

• Billing data in your billing system, e-commerce system or general ledger
• Support ticket data in your Support CRM like Salesforce, Zendesk, Genesys
• Social media platforms and tools like Facebook, Twitter, Hootsuite, Sprinklr
• Product usage data in Mixpanel, AWS Redshift, Segment or a data warehouse
• Sales CRM data in Salesforce, Oracle, Netsuite, etc.
• Survey data in SurveyMonkey, Satmetrix, Qualtrics, etc.

Looking at any one of these sources in isolation paints an incomplete picture of your customer.  Which is not to say that you shouldn’t analyze the data in each system.  

However, the best understanding of a customer’s loyalty, success and intent comes from weaving all of this data into a “Customer 360”.  And to build a Customer 360, you need to be able to join data across systems.

Joining customer data is a challenge… and ESSENTIAL

To build a customer profile, the most important thing you can do is the programmatic matching of customer data across sources.  

This requires use of shared “foreign keys” in each system.  What’s a “foreign key” you ask?  It’s a unique identifier that two or more systems use in common to describe a specific customer.  

For example, an account record in Salesforce has an i.d. that looks like this: 001d000001sDN5ZAAW.  If you use Zendesk for support tickets, then you would have to instantiate Zendesk tickets with the customer’s Salesforce i.d in order to match up an account record in Salesforce with the corresponding support cases in Zendesk.

How to implement foreign key management

Key management requires some technical work.

In an ideal world, you have one identifier that all systems will share. In that case, there are two choices:

• Globally Unique Identifier (“GUID”). A GUID is a user id.  This type of key is useful for B2C applications where the individual does not have a relationship with a parent entity such as a household or a business.  The GUID in this case could be the person’s email address, or a system-generated unique value. I think email address is easiest.
• Customer I.D. is useful when there is an entity to whom one or more persons belong, such as a business account.  The Customer I.D. typically is generated by one system and used in others.  For example, a Salesforce Customer I.D.  Start with the Customer I.D. from a “system of truth” where every customer lives, such as the billing system.

Most of us don’t live in the ideal world.  Not every system can share a common key.  However, if you can get System A to match System B, and System B to match System C, then all of your systems can work as one.  

This is where lookup tables come in.  It’s an approach where you store two or more keys in each system.  Have a look:

Key	System A	System B	System C	System D
“GUID”	x	x
“Customer I.D.”		x	x
“CUST_ID”			x	x

Management support

All of this work is hard because it can take weeks or months of effort to implement shared keys across your systems.  And, with each new system you deploy, you’ll need to incorporate keys into that system or it will become another “island” of customer data.

Management support is essential.  They must be convinced of the long-term benefits of this data in order to sustain the prioritized effort is required.

Is it worth it in the end?  I’m a big believer in the transformational power of customer data.  Maybe you are too.  

But don’t forget to sell the priority of this work, and keep selling until the job is done.