CRM Records: Now Who’s the Dummy?

By their very nature, CRM systems tend to have a higher proportion of manually-entered data than any other enterprise software. And much of the data that comes into the system from integrations and imports are dirty. So data hygiene is a tough job in almost any CRM system.

It’s ironic, then, that CRM systems actually have legitimate reasons to use dummy values in records. If you’ll allow me to use some Jeff Foxworthy shtick here, I’ll walk through some examples:

If You’re Trying to Work Around Private Contacts, You Might Need a Dummy

Some CRM systems have the notion of a private contact — a contact that is not linked to an account — that can be created through imports or user actions. While private contacts are stored in the system, only the person who created them can actually see or modify them. Because they’re supposed to be private, they don’t show up in most searches or reports — making them more than a little annoying to fix.

If your organization needs private contacts, fine. But most don’t, and a way to avoid their creation is to attach contacts to a dummy account if the account name is blank. This can be easily achieved with a database trigger, typically built inside the CRM system’s database but in some cases supplemented by code in integration servers.

We typically recommend that the dummy values be visibly flagged so they can’t be confused with real accounts, and they’re easiest to deal with if they show up at the very bottom of alphabetized lists in your local language. In most cases, a dummy name like “{{{dummy}}}” satisfies these criteria. In most situations, you want to be able to easily separate different types of dummies so that their sources are more obvious, such as:

• {{{web_dummy}}}

• {{{ecommerce_dummy}}}

• {{{tradeshow_dummy}}}

If One Side of an Integration has Mandatory Fields and the Other Doesn’t, You Might Need a Dummy

Some systems have required fields for address, phone, e-mail, or other customer profile information, while others don’t. When integrating the two, you’ll have to put something in the fields of the more restrictive system. In some cases (such as “preferred language”) it’s safe to insert a default value if the information isn’t available from the “other side.” But with numerical data, you want to put in some data that could not possibly be confused with a legitimate entry. Addresses are relatively easy because they allow punctuation marks (like “{“) and you can use Dummy strategies discussed above. But phone numbers are a bit of a problem because (1) more and more “impossible” phone numbers are now legitimate, and (2) what would be “obviously bogus” in one country would not be recognizably silly in another. +1 800 555 1212 is about as good as it gets, at least for the U.S.

If You Need to Stop Absurd Mail Merges, You Might Need a Dummy

Many CRM systems get data from Web forms, some of which aren’t under your company’s control. Consequently, a good percentage of your lead and even contact records will have ridiculous values for name or address fields. Just because some of the values are junk doesn’t mean you want to throw the whole record away — it may still be a valid e-mail that you want on your subscriber list. Let’s say one of those good e-mail addresses claims to be for someone named “asdf asdf”…you don’t want to have a mail merge that starts off with “Dear Mr. Asdf…”

You can detect these silly values with a junk dictionary or a data cleansing service, but you don’t want to replace them with blanks even if the system would let you. Instead, use dummies like {{{empty}}} or {{{junk value}}}, and add logic to your mail merge routines so that the dummies cause the “Dear…” line to be “Dear valued customer” or just dropped entirely.

If You’re Trying to Avoid Using Person Accounts, You Might Need a Dummy

Some CRM systems have created Person Accounts as a way to represent consumer and other special contacts that will never be associated with a company. Person Accounts are helpful because they avoid the creation of bogus Account records with a singleton Contact (such as “John Doe” of “John Doe” company). However, Person Accounts have some nasty side effects, particularly when writing reports.

A simple alternative is to create a few dummy Accounts, such as:

• {{{individual}}}

• {{{SOHO}}}

• {{{student}}}

• {{{web_trial}}}

• {{{coupon}}}

These dummies allow for easy aggregation and rollup of individual transactions which aren’t worth tracking on their own, but total up to an interesting amount of business. This approach makes a lot of sense even if your system doesn’t have person accounts — it’s a natural way of emulating the feature in almost any CRM.

By using dummy values and filters in clever ways, you can mix groups with standard individuals and accounts in the CRM system without corrupting the outputs of reports, searches, or rollups. Of course, using this trick requires some careful documentation and controls. But sometimes, dummies are the smart approach.

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.

Follow everything from CIO.com on Twitter @CIOonline, and the CIO.com Facebook page