I’ve often talked about the importance of having a Data Plan for a healthy CRM. A data plan is simply a set of standards for CRM data. For example, review the following ways to write:
Director of Human Resources
Director, Human Resources
Director of HR
DIRECTOR OF HUMAN RESOURCES
Human Resources Director
Lack of standards is a problem. Why does it happen? The examples above are from a live CRM. What were the sources of data? There is user entered data, web form connected to CRM, D&B, trade show directory, and any data from vendors.
This is a CRM nightmare
The solution is to provide a system that enforces data standards. Some companies get by with an agreed-upon set of standards, but that is not enough. Enforce is the key word. Having an agreed-upon data standard is a great idea, but in reality you can’t control how your vendors deliver data. You can’t force your sales reps to enter data correctly. You can’t force users filling in web forms to change what they type. You can’t prevent marketing from importing that latest trade show directory.
So, again, the only answer is *enforced* Data standards. How do you do this?
The only way to accomplish true standards is via technology enforcement. One example of this is CRM Shield, which simply allows you to pick a set of standards. Once a standard is built, then all data passing through the CRM is standardized.
So what is the debate?
Recently, one of my partners pointed out that his customers “Don’t want to change the titles.” He believed to save the titles in the way that they were provided. A “Vice President of Sales” did not want to be listed as “VP Sales”. Thus the debate began about Normalization/Standardization of titles.
Now if the customer is always right, we want to accomplish this, but what is the true, best solution?
First, there are two types of Normalization, destructive and non-destructive. Destructive means that when the data is changed, something is lost and the change cannot be reverted. An example would be truncating a title from “Director of Systems Automation” to “Director of Systems”. Once the “automation” piece is gone, it cannot be recovered. A non-destructive example would be changing “Vice President of Sales” to “VP Sales”. The litmus test for non-destructive normalization is whether the change can be reverted. Starting from the shortest form, “VP Sales”, normalization rules would allow any variation of the title to be modified and re-modified without any loss.
“If someone lists themselves as ‘Chief Executive Officer’ on their business card or email signature, they don’t want to be listed as ‘CEO’.” This is the counter-argument; to maintain the original state of the data. This is a valid point. Yes, we can change ‘CEO’ to ‘Chief Executive Officer’ and back again, but once it is changed, how do we recall the original title? The answer is you don’t know.
Personally, I don’t believe in the counter-argument, but my job is not to judge what my customers want, but to deliver results that help them run their businesses more efficiently. Non-standard data is a culprit in creating duplicates in your CRM. Duplicates are ugly. Duplicates costs companies millions of dollars each year in lost efficiency, data cleanup, skewed KPIs and failed analytical reports. You can’t report on non-standard data.
Normalize your data. However, if you must retain the original source of titles, you are THAT fickle CRM admin, here is what you should do.
Have 2 title fields in your CRM.
Field 1: The normalized title. Use this for search, KPIs, reporting and deduping. Having a single standard by which to measure. This will keep your CRM tuned and your sales and marketing teams will love you.
Field 2: The Original title. Use this for display, mailing and customer/suspect/customer outreach. If you mail, use this field.
Even the original title should be normalized to a certain degree. Example: “Vice — President of Sales”. This example has extra spaces, dashes, and a period at the end. A simple clean up would yield “Vice President of Sales”.
Regarding normalization, I am right, and the detractors are wrong (especially Gregg Thaler), and eventually, they will come around to my way of thinking. Until then, I’ve done my job and outlined best practices that can make everyone happy.