How to Create a CRM Data Quality Policy


  • Poor data quality is a frequently cited user complaint and top contributing factor to low user adoption and failed CRM software implementations.
  • If users don't trust the data, they will not use the CRM system.
  • A CRM data quality policy reduces duplicate records and other data irregularities so that users get accurate information when searching lists, creating queries, viewing dashboards or running reports.
Johnny Grow Revenue Growth Consulting

The CRM Data Problem

Customer data is a perishable asset. Companies get acquired, employees change jobs, staff get new titles, telephone numbers and email addresses. An interesting B2B data quality test found that customer data decays at a rate of 5 percent per month.

While I think that finding is credible, my own experience is that CRM customer data depreciates about 2 percent per month when measured to a point where it causes marketing and sales problems. Regardless of whether its 2 or 5 percent, or something in between, it's a big problem if left unmitigated.

Unfortunately, poor CRM data quality is often ignored until it's too late. Once users no longer trust the data, user adoption plummets and regaining trust is a tough exercise. A CRM data quality policy is one of those proactive measures where an ounce of prevention is worth a pound of cure.

The CRM Data Quality Solution

A data quality policy is a key component of a CRM data quality program. Because it's also the most overlooked and underutilized we created this post.

CRM Data Quality Policy

A CRM data policy creates data rules and safeguards which result in data trust.

A CRM data quality policy shows how to standardize customer-related data so that the data is easily accessible and consistently applied in customer facing business processes and information reporting.

The danger is that inconsistent data delivers inconsistent results. When customer, sales or service data are formatted differently the data may show up in some queries or reports but not others. It's worse than dirty data because the user or business process is not aware they are not getting all the data they should.

The three primary areas for a data quality policy include data sourcing, security permissions and data standardization.

Importing customer data from a legacy system to a new CRM application is often the first source of data. But data imports continue as companies acquire other companies, integrate with other customer data platforms, purchase lists or upload data from website landing pages.

The key here is that the data should be cleansed and properly formatted before uploaded to the CRM system. The cleansing and review process can be done in a third-party application or in a CRM DEV sandbox instance.

The alternate process of importing first and then resolving data differences in the CRM system creates data attribute orphans and irregularities which stay in the data model. It's a mistake to try to clean data or adjust data formatting after the data is imported.

Assigning security permissions must balance the benefits of sharing data with all who can use it and data quality efficiency. Data quality is more easily achieved when security privileges permit fewer users to access, create, update or delete data. Security permissions such as making select data read-only can bring a compromise to many security use cases. Some companies grant security permissions subject to adherence of the the data policy.

Data standardization is the most challenging but most effective approach to CRM data quality. There are several standardization procedures to achieve the goal of data uniformity.

First, assign data values to key data elements to determine which data fields should be standardized. Internal controls on too many fields will make the CRM software onerous. Too few will render data quality ineffective.

Based on our experience, we have found it most effective to create data policy rules in the three categories of data standardization, naming conventions and data styles.

CRM data standardization is the first line of offense for data quality. Below are some examples of data standardization rules.

  • Numbers, fractions, monetary values, year, telephone number and other nominal values should be automatically converted to a consistent format.
  • Certain alpha fields such as cities, states, provinces and countries should also be consistently standardized.
  • Contact roles, but not titles, should be standardized. Some CRM consultants suggest standardizing job titles. I don't care for that as titles are used by the people that own them and those people often like to be referred to by their actual titles. I advise to instead use an additional field to standardize roles. For example, is the role Director of Business Development, VP of Sales, SVP of Sales, Chief Revenue Officer or Chief Sales Officer? Standardizing on a common role for the sales leader aids marketing in performing segmented campaigns or account-based marketing (ABM) programs. It also provides a way for salespeople to identify all the sales leaders in their territory or named accounts.
  • A CRM data quality best practice is to minimize the number of free text fields. When you can replace text fields with dropdown lists or multiselect fields you accelerate data entry for the user and increase data standardization.

Naming conventions are needed to avoid duplicating the same record multiple times with slightly different names. Below are some naming convention examples.

  • Create a guideline for leads and customers known by multiple names. For instance, determine whether your policy is to enter the account's legal name or most recognized name. As an example, determine whether your policy is to enter "Sears, Robuck & Company" or simply enter "Sears". If you sell automobile parts in the Motor City, define whether your account is "Fiat Chrysler Automobiles" or just "Chrysler." Is Salesforce entered as "Salesforce" or ""
  • Determine under what conditions to use or not use acronyms. For example, is the company entered as "America Online" or "AOL"? Is IBM saved as IBM, IBM Corp or International Business Machines?
  • Definite articles or company prefixes such as A, An or The can cause a lot of data lookup problems. Determine whether it is your policy to maintain or remove a prefix, noun, pronoun or similar descriptor preceding a company's name. Alternatively, just decide whether to include or remove the indefinite or definite article when it precedes a company's name. For example, do you keep or remove the word "The" when entering the organizational name of "The County of Palm Beach" or "The New York Symphony?" I normally recommend either eliminate definite articles or move them to the end of the data value. For example, instead of The Wall Street Journal, enter Wall Street Journal or Wall Street Journal The.
  • Also consider legal entity types. A customer record entered as Microsoft, Microsoft Corp or Microsoft Corporation will reside in the CRM system as three different company records.
  • Business to consumer (B2C) companies have an increased need for clear naming conventions for contact names. For example, do you record the legal name or alias? If I buy something from your company, does the contact record show Chuck Schaeffer or Charles Schaeffer? I can't tell you the number of B2C companies that have me incorrectly in their systems with two customer records.
  • Regional contact names can get complex for global companies. For example, Sasha is a unisex given name which originated in Eastern and Southern European countries as the shortened version of Alexander and Alexandra. Alexander in Russian Cyrillic matches to Sasha in English. Recognizing these nuances will reduce duplicate data.

Data styles work like style books used by authors or stylesheets used by website designers to ensure data consistency and readability.

  • For numbers and addresses, a common data policy is to spell out the numbers (i.e. Second Street instead of 2nd Street).
  • Determine whether you prefer to use punctuation or abbreviations with company names and locations as any inconsistency will create differences in fields commonly used in queries and filters. For instance, is the organization entered "US Steel", "U.S. Steel" or "United States Steel"?Is the city in Florida Saint Augustine or St. Augustine? Searching for companies in St. Augustine may not bring up the same list as those in Saint Augustine. If you elect to use abbreviations, determine whether they should be entered with or without periods. It's often simplest just to avoid punctuation.
  • Apostrophes also create duplicate records. Is the contact name Connor ODonnell or Connor O'Donnell? Many companies choose to avoid apostrophes.
  • I generally eliminate case sensitivity unless needed for specific data elements.
  • Decide if you will permit what are often referred to as illegal characters in company names and elsewhere. These characters include: \ / : * ? < > | # ", $, &, [ ]. Most CRM systems will support them in the company name. However, they are known to deliver inconsistent lookup and query results. I've also seen these characters pose problems in the CRM system audit trails. Unless part of a trademarked name, I generally advise to avoid them.

Inconsistent data creates duplicate records and downstream problems with certain functions in the CRM system, such as performing wildcard or masked searches, forming queries, running reports or exporting data to other systems such as the ERP application.

Only when data is consistent do users to get the data they are looking for when viewing lists, running queries and using dashboards.

Defining your CRM data standardization rules gives users the knowledge to enter data consistently. It also enables system administrators to create automated rules or CRM data management dashboards to detect data policy variances in real-time or after the fact in periodic assessments.

For additional data safeguards, consider the CRM data quality best practices.