Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

How CRM data updates lead to data corruption

David Taber | April 24, 2012
In theory, it's best to clear all your database transactions as soon as you can, keeping the tables up to date so that you don't have to worry about data integrity or time-smear problems. It's not always that simple.

This is a fairly straightforward decision when the Account name is nearly identical. It's a bit more of a judgment call when the new Account is ESPN and the existing Account is ABC Networks or even Disney. They're all part of the same corporation, but do they need to be a single account, or an account hierarchy? It all depends on your business rules.

OK, but what about other CRM tables? It's not at all unusual to have noisy data updates coming in for both Leads and Contacts. The data are noisy in three key ways:

  • You're not sure whether Joe Bigshot is the same as Joe Biggs-Haute
  • You're not sure whether joe.bigshot@gmail.com is the same as joebigshot@company.com
  • You're not sure whether the data quality of the new record is better or worse than the old one (particularly when you are merging data from an external "industry standard" database).

Given these issues, simply updating your existing records can be an act of data corruption. The faulty update can case receipts and other official communication goes to the wrong place, or can interrupt the sales cycle. Neither of these symptoms will be particularly endearing to the CRM user community.

So the intentional creation of duplicate records is again not a bad strategy - as long as you have (and live up to) an SLA around the reconciliation of data updates.

The Urge to Merge

When merging records that have been intentionally created as dupes, you'll need to use some subtlety and guile. Conventional merges collapse records together using static rules (such as "most recently updated" or "best data quality"). Since the merges are typically done at the record level - rather than cell-by-cell - the losing record might have some values in it that get wiped out by the winning record.

With the intentionally created dupes, it may be appropriate for bits of the losing record to survive (such as a new phone number or additional email address). If you're going to be using standard merge logic, then, you'll need to copy these valuable parts of the losing record into "spare fields" to the merge. We typically do this with a long-text field, concatenating the extra bits of data using an "XML-lite" style (e.g., "OtherPhone:800-555-1212, AssistantEmail:joan@didion.com"). However, there are situations where a more explicit "extras" field works better.

The underlying issue: make sure that all updates are increasing the total information value of the CRM database, rather than blindly making sure it's "up to date with the latest values." Because sometimes, the latest ain't the greatest.

David Taber is the author of the new Prentice Hall book, "Salesforce.com Secrets of Success" and is the CEO of SalesLogistix, a certified Salesforce.com consultancy focused on business process improvement through use of CRM systems. SalesLogistix clients are in North America, Europe, Israel, and India, and David has over 25 years experience in high tech, including 10 years at the VP level or above.

 

 

Previous Page  1  2 

Sign up for CIO Asia eNewsletters.