Data Quality - Account Hierarchies

Account Families cannot be thought of in isolation of other considerations around data and data quality. Here are some such topics to think through.

Definition of a non-sellable entity

The topics below are meant to tease out the idea of a "sellable vs a "non-sellable" entity. What this means is that for each account that is in your CRM database, it is important to understand if you can actually sell to that entity independently or not. A "sellable" entity is something where:

  1. The purchasing decision can be made by someone who has jurisdiction over the entity in question.
  2. The specific "location" makes a purchasing decision for YOUR product. This could play a big part in your coverage model and how to assign reps to cover such a location.
  3. Sellable entities can be part of an account family and may be related to each other but they make purchasing decisions on their own.
  4. They may have specific legal, political or geo-physical considerations that requires them to be sold separately, even if the decision to buy is made elsewhere. For example - data privacy laws may dictate that a special "Selling and support" process is required for an entity in Europe vs an entity in the US. Government departments may have special support, security and product requirements that may require a unique sales or support cycle.

Ideally each sellable entity is reflected in your CRM. For entities who you know cannot be sold to - a policy decision has to be made on the value of keeping that data in the CRM and assigning them to a rep.

Field Intelligence

In our practical experience, your field sales team knows a lot more than any automated data source can. It's therefore important to have a process to capture this knowledge, validate it and then use it in your planning and execution process.

Tagging of a non-sellable vs a sellable entity is one of these key field intelligence that needs to be captured and used in your planning and execution process. This needs to be codified into policy as far as the treatment of these non-sellable entities. For example:

  1. Have fields that the sale rep can use to indicate when an account is identified as a non-sellable entity. When a rep tags an account as such, have a process for the sales ops team to validate this.
  2. Once validated, move the account out of the sales reps territory so that the rep does not waste time selling into these entities. Understand if this could change in the future - for example centralization or decentralization of purchasing power within an organization, can change over time.
  3. Revisit this tagging every year to make sure they still hold true.
  4. Determine how you would use non-sellable entities within the planning process and how coverage will be assigned.

Site Matters?

There is an important decision that you will need to make and is based on the buying behavior and the decision-making structure of your customers. The crux of the decision is answering this question: Do individual “sites or location” make their own purchasing decisions or are the decisions made at a central location? Are the people you sell to located at branch locations or are they located centrally? Do you ship your product products to specific branch locations or do you deliver your product/service to a central location?

Essentially – How important are physical locations to your sales and support processes?

Once you establish the answer to your question, then you can decide how to create your account hierarchy and maintain the account hierarchies and how to prevent duplicates in the system. Duplicates in the system will pollute the account hierarchy, be stragglers (or “lost” subsidiaries) and contribute to more maintenance and hygiene issues than necessary. It's better not to have accounts that you don't sell to in the CRM, than to have them and incur the maintenance cost.

Let’s say you sell software to the central IT department, there is really no reason to maintain branch details in your CRM system. You just need one account/customer record that reflects the level you sell at - i.e. - the "sellable" entity.

But let’s say that you sell HVAC gear and each location or building makes the purchasing decision independently, then you will need to maintain a list of all the locations for a company such that you can sell to each location independently. In this case, there will be a larger number of records in the hierarchy than the previous situation.

There is also a hybrid situation between these two ends of the spectrum and is very common in larger multi-national companies where regional headquarters could play a role in the purchasing decisions. They may also be setup as separate companies.

Lost Subsidiaries

When accounts are created in the system, there are a number of things that could impact the quality of account family data. We call this problem the "Lost Subsidiary" - where accounts are created in the CRM and due to insufficient data, they are not associated with the families they belong to.

This happens for 3 reasons:

  1. When a new account is created, there is not enough data for a 3rd party automated enrichment, leading to this account not being matched and enriched by the data service. These accounts then wander your CRM as "lost subsidiaries."
  2. When mergers and acquisitions occur during the normal course of business, they don't get reflected in your CRM through the various enrichment solutions.
  3. Parent Accounts don't exist in your CRM for you to be able to link siblings together, leaving siblings wandering lost not recognizing they belong to a common family.

Best Practices for Creating Accounts in the System

When creating accounts in the CRM, there are a few things to consider:

  1. How do you create accounts in the system? There are two acceptable ways this is done:
  • You buy a list of accounts from a prospecting or targeted outreach list and you add them to the CRM system.
  • A lead is converted into an account and contacts in the CRM system.

For both of these questions, it is important to understand how much data is available at the time the account is created. In the above situations, a minimum data requirement should be enforced to make sure that all the key fields necessary for matching data is captured – such as website, addresses, name, phone number, etc.

  1. It is usually not a good idea to create accounts from marketing and “contact us” forms from your website. There will be an enormous amount of junk data, incomplete and inaccurate data that can end up as accounts in the CRM system. It’s a better idea to send these into the lead process and have it qualified before being created as an account in the system.

  2. Automating the creation of accounts from trial signup forms. While this is not inherently a bad thing, there are a few scenarios that contribute to bad data:

  • There is a natural tension between the number of details you ask for a person to fill and the conversion rates. If you ask for too many details, people are discouraged from signing up. Therefore, it’s tempting to just create “trial” accounts with just an email address and nothing else. These types of accounts are very hard to match and enrich and therefore almost impossible to associate with a hierarchy.
  • Not validating personal email addresses for business services. If your goal is to go from a contact in a lead to selling to the company – it’s important to be able to capture at least what company they belong to.
  • It is very important in this scenario to de-duplicate the accounts before you create an account in the system. It is also very important not to reference back end resources provisioned to an account directly in a 1:1 basis. For example – if you a storage company and you have provisioned a 15GB of storage for user – be careful to link that 1:1 to an account of that user’s company. This results in duplicate account records and that adds to the pollution of the CRM system and therefore makes the hierarchy and exacerbates the problems mentioned in the previous sections.

The reason why creating accounts needs to be carefully looked at as it relates to account hierarchy is because of a problem that we call Lost Subsidiaries

The above are common scenarios that we have seen that contribute to bad account data in the CRM system. Establish strict policies around the creation of accounts and be BRUTAL in preventing duplicates from being created.


Some structures such as departments within a company are not typically part of the account’s legal hierarchy. It is tempting to create them as child accounts. Here are some challenges with this approach:

1.) 3rd party data sources do not support matching and enriching department levels details. This means that you will have to manually match and enrich accounts. If you change the name of the account from say – Microsoft Corp. to Microsoft Exchange Server Division – this is likely to throw off the matching logic and therefore this account will not get enriched with the appropriate account details. Even if you enrich this account – it will still contain details at the company level and not at the department level. There are other better solutions for dealing with departments than using account hierarchy.

2.) Re-organizations are a fact of life in corporations. When these happen – there will not be an automated way (like 3rd party enrichment) to be able to readjust the hierarchy to reflect the new departmental structure. This will have to be done manually. Using Account hierarchies to record departments adds an enormous manual data cleaning burden for the operations team and is likely to lead to inaccurate data with the ops team unable to keep up with reorgs in 100s of companies at the same time. During these changes – not only will the ops team need to fix the account hierarchies, but they would need to move all transaction objects such as opportunities, activities, leads, contacts, cases, etc. This is not trivial.

So all in all – using account hierarchies to record departments is a really bad idea. So how do we handle this? Add custom fields to your transaction objects to capture departments. This way you will be able to adjust things much more easily. If you’ve assigned different sales reps to different departments – use a solution like the Motion routing queues to get them to the right reps at the opportunity level.

Using 3rd Party Sources to Enrich Data

The use of 3rd party data sources and enrichment solutions can help keep your CRM data up to date. It’s important to understand that all 3rd party solutions provide data that is “out of date” from current reality. The mere task of collecting, curating and validating data takes time. This means –data elements such as employee counts, revenue numbers, account hierarchies, etc.– provided by pretty much any data source is at least a few months old.

Your sales reps are going to have the most accurate data and your SDR teams are likely to get the latest and greatest information from the customer as part of the selling process. Therefore don’t automatically overwrite the data collected by your SDR and sales team with 3rd party data.

The above being said – 3rd party data sources are a great way to eliminate manual data enrichment, data cleansing and automation around key customer events like mergers and acquisitions. Based on your decision around whether sites matter or not (see above), you need to carefully pick the right data source that can provide you those details.

Dunn and Bradstreet (D&B) and their properties are the largest data provider in the world as it relates to firmographic (i.e. company details) data. Their DUNS number based organization is a great tool to automate the creation of account hierarchies. However, there are a new breed of data providers catering to non-site based needs that use the internet domain as the key to creating unique identifier (akin to the DUNS number used by D&B).

There are a number of data providers in various countries internationally that provide company data that tend to be more accurate than sources like D&B and more frequently updated. Therefore, it is important to research the right solution that works for your scenario, selling model and approach.

The Account Hierarchy component relies on 3rd party data sources like D&B to provide the details on hierarchy to automatically maintain account hierarchies.