Managing “legitimate” duplicate records

Not all duplicate records are created equal and not all duplicate records should be removed. There are many business situations where duplicate records should be kept. We like to call these “legitimate dupes”—which you should keep in your data deduplication process. Here are some of the more popular cases of legitimate data dupes we see:

Brokers and Channel Partners

Many businesses sell through partners. In the Consumer Packaged Goods (CPG) business there are brokers and distributors. In the semiconductor business there are design partners. These channel partners have multiple relationships with retailers. In the Salesforce.com world, these partners are Contact records that must be associated with multiple Accounts. Until recently, SFDC only allowed each Contact to be associated with a single Account, so one common way businesses use to sidestep this limitation was to create multiple Contact records for the same partner. In this type of situation where you want to preserve the partner-to-customer relationships within the Contact-to-Account construct, make sure you only de-duplicate Contact records within each Account and not across Accounts.

This is a very broad category covering many types relationships across different industries.

If you decide to keep these partners as legitimate dupes, you should consider “syncing” (vs. merging) these legitimate Contact dupes, so all the duplicate database records for the same partner have the same data all the time.

Preserving Historical Context

When a Contact leaves Account A for Account B, should you:

1. Create a new Contact for Account B, or
2. Change the Account assignment for Contact from Account A to Account B?

There is no universal right answer for this, but we do see a clear split in preferences between marketing and sales teams.

Marketing often prefers to reassign the Contact from Account A to Account B. This preserves the engagement history with the person so marketing so that they can properly attribute their campaigns to the revenue that is ultimately produced. Also, this reduces the number of dupes, and marketers hate dupes!

Sales, in general, prefers to create a new Contact for Account B. This is because Sales sees each Opportunity and Account in its own separate context. Any previous conversation with Contact at Account A doesn’t have much relevance to a new conversation with a Contact at Account B. Keeping the old Contact record with Account A also preserves the proper context for Account and Opportunity history.

As more marketing and sales technologies become available that can help Marketing and Sales analyze ideal customer profiles, preserving the historical context about how a deal went down, and who were involved at the time can be a powerful justification for keeping historical data that represent dupes of the same person.

If you take this historical preservation need a step further, some might even argue that every time a Contact changes job, gets promoted, or relocates, you should also create a new duplicate Contact. This way you can see that at the time an opportunity was closed years ago the Contact was a manager in marketing, although he is currently an executive in business development.

In SFDC, things get even more complicated if the Contact that left Account A is now just a Lead record at a company that isn’t even an Account yet. Of course, you can’t un-convert a Contact in SFDC. In this case, you have a dupe across Contacts and Leads.

Business Units and Divisions

For Account records, every sales organization has a different take on what a duplicate database Account is. There is absolutely no universal right answer here. It all depends on how your sales organization is organized. Here are some common example of tricky situations:

• Business units by location: Toyota Motors USA, Toyota Motors Canada, Toyota Motors Mexico
• Conglomerate business units sharing the same name: GE Healthcare, GE Transportation, GE Appliances
• Conglomerate business units not sharing the same name: Alphabet, Google, Waymo, Verily
• Keiretsu: Mitsubishi Steel, Bank of Tokyo, Meiji Mutual Life, NYK Line

One common example that is related to this is ship-to vs. sold-to addresses being modeled as different Accounts.

Do you have a unique legitimate data duplication database scenario you would like to share? Send us your story to ed(dot)king(at)openprisetech(dot)com.