Monthly Archives: December 2010

When is a Salesforce / Dynamics / any other CRM Field no longer useful?

One of the many advantages of modern CRM systems is that it is very easy for business users to add additional fields. One of the main disadvantages of modern CRM systems is that it is very easy for business users to add fields without giving thought to the ‘bigger picture’. In this blog post I will discuss my approach for determining when to remove that field from the system.

If you don’t read any further than this the basic principal is that when a field is no longer trustworthy there is point keeping it in your production CRM system.

Can we trust this field?

What do I mean by that? Well a field is untrustworthy if you (and no one else) can’t find a consistent process for populating or maintaining that field despite reasonable efforts to do so. Let’s take an example of an ‘Account’ field that says “Number of Employees locally”:

  1. Who collects/populates it? Is it the Sales Rep? Is it the marketing department ? Is it from a 3rd party data provider?
    – Don’t know and can’t find out? – back it up and delete it!
  2. When is it collected? At time of record creation? When the Account becomes a customer? When there’s an opportunity?
    – Remove it
  3. When was it first ‘put into production’? This is vital if we are doing any kind of historical analysis.
    – If the field is only there for trend analysis, the data appears patchy then it’s useless.
  4. When was it last updated? What’s the worst case?
    – no historical value? lose it.
  5. Do we actually understand what the field means? Is it unambiguous?
    – it’s useless

Do we understand what the field means?

I will write a follow-up post on field naming conventions, however what we must do is look at the field name / label and determine if the question used to populate the field is at all ambiguous? Even if the IT/IS/Sales Ops department understand the meaning of the field do the people who are actually populating it? What about users who primarily speak different languages?

An example of an ambiguous field I saw recently was on an account and just said “MSP Customer” where MSP means Managed Service Provider. Due to my client’s channel sales model it was not clear if this field meant the account was a “Managed Service Provider” themselves or if this account was effectively an indirect customer since they purchased through a Managed Service Provider.

What is the purpose of having a field anyway?

I think that this is the most important point, we create a field for either (or both) of the following purposes.

  1. To mark a record as being at a certain stage in a process.
  2. To record data for later analysis (reporting).

If a given field is not adding any value to a current business process and it has no historical value for the reasons listed above, back it up and delete it before someone makes a business decision based on its content!