Account Hierarchies

Account Hierarchies - Why It Matters

Maintaining the relationship between the various business entities within your customer’s corporate structure is useful in a number of sales scenarios. There are a number of use cases where this would be helpful to maintain this information within your CRM system including:

Understanding the decision-making structure for what and how you sell into a company. For example – are decisions for your product made at a branch level or are they made at the company’s headquarters?
Identifying the cross-sell and upsell opportunities that exist within a large corporation. For example, if a department or division of a company is an existing customer, it makes sense to target and sell into other divisions, departments, or subsidiaries of that customer.
Understanding the legal and corporate hierarchy of multinational enterprises for various taxation, legal and other regulatory reasons.
Tracking Mergers and Acquisitions that may impact existing sales engagements or open up new opportunities as companies come together or split apart.
Having a view of the entire corporate relationship hierarchy of your customers can expose a wider surface area for you to start nurturing your customer and to implement Account Based Marketing (ABM) & selling strategies.
Tracking the entities that may be covered by customers that negotiate corporate pricing and discounting that applies to the entire corporate structure of the customer.

The above use cases are some of the examples of how maintaining account hierarchies within your CRM are useful in the selling process. It is by no means an exhaustive list. Yet, the relationship between the company’s various entities is crucial to maintain an accurate 360-degree view of the customer. Within a CRM system it is therefore very important to be able to view roll-up reports and understand the various activities at any point within the account hierarchy. Properly configured reports should include visibility at a minimum into activities, opportunities, lead responses, campaigns, cases, subscriptions, and contracts.

Salesforce.com provides standard account hierarchy fields on the account object, however, there are a lot of things that Salesforce.com fails to enable in order to effectively utilize this capability in the selling process. The default configuration is a simple storage mechanism, and unfortunately, a very limited one at that.

What makes implementing Account Hierarchies so difficult?

Let's look at what are the limitations and how can they be addressed. To effectively maintain an account hierarchy in your CRM, the following issues need to be addressed:

Multi-National Accounts – If sales reps from different countries or regions sell into the same hierarchy, it’s important to ensure the sales team has a view of the whole hierarchy so that they can both sell effectively to their target but also recognize the various scenarios where selling into a branch or headquarters may have an impact on another rep’s ability to sell into a particular point in the hierarchy.
Mergers and Acquisitions – When relationships between companies change – such as outcomes from mergers, acquisitions, and divestitures– it is important to identify and understand the impact on existing sales processes and team and territory assignments.
Timing of Mergers and Acquisitions – Companies announce the intention to merge, yet the process of coming together operationally may take years. Depending on the nature of the merger, there may be an immediate change in the buying behavior and the decision making of one of the entities even before the 3rd party data sources are updated.
Discovered Subsidiaries – No data source is perfect and data sources are not always accurate nor do they immediately reflect the changes in the account hierarchies. Therefore, a delay between the time an event occurs and the time it takes for that event to be recorded in the CRM system needs to be taken into consideration. Refresh Cycles and how quickly 3rd party data sources are updated are all factors for this delay. A policy must be established to determine the impacts to the sales team how to handle them.
Inconsistent Matching – Proper enrichment relies on existing data in the newly created record to match against a larger 3rd party data source(s) to identify if a new account should be created or if it needs to be associated with another entity or within another existing account hierarchy. When accounts are created within the CRM inaccurately or with incomplete hierarchy data, the enrichment process and tools can become flakey and compound the problem.
Opportunity Conflicts -- it is very possible to have multiple individuals and multiple selling efforts to be in process during M&A and they must be reconciled to successfully advance the opportunities because M&A invariably impacts the sales reps and the members of the selling team and their earnings, careful consideration must be made, and a fair policy put in place to handle all potential scenarios.

Holding Companies, Private Equities, Franchises and Government Agencies

Holding Companies - Large conglomerates often have a very deep and complex entity hierarchy with holding companies that don’t make purchasing decisions for their constituent companies. Take for example a company like Berkshire-Hathaway which owns multiple multinational companies, each with individual purchasing authority. In these cases, it does not make sense to have the holding company at the top of the hierarchy but instead to break up the child corporations into their own independent hierarchies. Conversely, it may make sense to roll up Wells Fargo and Yumm Foods under the same parent hierarchy.

Private Equities -

Franchises, Agencies and other such models – Depending on purchasing model, companies may either distribute or centralize and the purchasing decisions. For instance – each KFC location may make purchasing decisions for HVAC systems, but software decisions may be determined by the Franchisor. It’s important to to structure these company hierarchies in a manner most appropriate to the products and services being purchased. Keep in mind that the legal ownership structure may not be how your products and services are purchased.

Government Agencies – tend not to be separate entities but comprised of many departments. The departmental hierarchies are typically not reflected in 3rd party data providers While cities and counties tend to show up as entities with unique identifiers the various sub-departments do not. Frequently, purchasing decisions tend to be driven by the department levels. The legal hierarchy influences procurement typically with a designated purchasing department that is responsible for RFPs and public notices. Therefore, government agencies may need to be customized based on who and how you sell your product. For more detail, please see the section below on departments.

What about Departments

Some hierarchical structures, such as departments within a company, are not typically part of the account’s legal hierarchy. While It is tempting to create each department as a child account to the parent, the following challenges need to be addressed:

Third party data sources do not support matching and enriching department levels details. To structure departments accurately, some form of manual process is required to properly match and enrich accounts. Avoid changing the name of the account to the department name. For example– Microsoft Corp. to Microsoft Exchange Server Division as this is likely to throw off any data matching logic and the account will not get enriched with the appropriate account details from automated enrichment workflows. Even if you enrich this account it will still contain details at the company level and not the requisite detail at the department level.
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. Reorgs have to be updated manually. Using Account hierarchies to record department moves/adds/changes introduces an enormous manual data cleaning burden for the operations team and is likely to lead to inaccurate data as the ops team will likely be unable to keep up with hundreds of companies undergoing reorgs in the same timeframe. 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, and cases into the appropriate department. This is not a trivial data management problem and can and should be avoided.

Using account hierarchies to track departments is a really bad idea. The best practice is to implement custom fields within the transactional objects to capture department names. Managing reorganizations becomes a straightforward management task.

Data Accuracy vs Coverage

Data Accuracy vs Disruption

The Necessity of Policy around Data

Hierarchy Data impacts the selling process. Therefore, changes to hierarchy data impacts the selling process. It is very important to document the process and the associated policy with regards to how the hierarchy data - and more specifically how the changes to the hierarchy data - may impact the selling process. Topics of policy that must be considered and documented to effectively handle account hierarchies and their lifecycle include:

Opportunity Splits Policy – A split impacts quota, credit, and compensation. Splits are particularly challenging when you have multiple sales reps that may be selling into an account hierarchy due to a change in the relationship between entities that each rep is responsible for but occur during a compensation cycle. It is best to clearly outline and document how these different scenarios will be handled and how quota, credit and compensation will be impacted.
Duplicates – Duplicates introduce ambiguity which in turn increases the risk of inaccurate reporting and metrics. Clearly defining a duplicate account in the system is essential to identify a duplicate in order to take immediate action.It is important that this policy provides the ability for the operations team to act immediately and eliminate duplicates. The policy should be clear about how various scenarios such as duplicate accounts or conflicting hierarchical data are resolved in a fair manner.
Fixing Incorrect or Bad Data – It is important for the operations team to be able to fix bad data in the system and improve data hygiene in a timely fashion. When changes are made, it is important to have proper policy that anticipates any issues that may result from changes to the data. For example – if the account hierarchy changes because of a merger and acquisition – does the policy change the sales rep that is working on the account and if yes, what is the timing for the change and the corresponding Split policy for deals in the pipeline?.

Policy definitions need to be put in place to support proper maintenance of the account hierarchy. This is a difficult operational problem because of the volatility of the data, lead time between reality and its reflection in the CRM system and the emotional and financial impact to the sales teams when ownership changes. fullcast.io recommends the following rules in the creation of these policies:

RULE 1 – ALWAYS optimize for the customer experience and not the sales rep experience. Keep your customer and their interaction with the company first and foremost in these scenarios. Recognize that moving sales people around in the middle of a sales cycle impacts customer satisfaction and experience.

RULE 2 – Encourage a team mentality among conflicting sales reps and teams. Always allow for flexibility in the policy for the teams to work out the “fair” solution rather than dictating a solution for every possible scenario – partly because you will not be able to think of them all, and mostly because it facilitates buy in to the solution by those affected..

RULE 3 – Keeping Territories, Quota and compensation plans stable is important for the success of the sales team. Disruptions here will result in loss of productivity and will affect morale. When moving accounts in and out of a rep’s territory – think about the impact to Quota and Comp. Encourage “Stay in Your Lane” as much as possible by re-aligning territories around your periodic planning cycle .

Do Physical Addresses Or Unique Sites Matter?

Understanding the buying behavior and the decision-making structure of a customer should influence the structure of the hierarchy data. 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 involved in the procurement of your product located at branch locations or are they located regionally or centrally? Do you ship your product or services to specific branch locations or do you deliver your product or services to a regional or central location? The key is to have a good understanding of the importance of physical locations to the sales and support processes.

Once the importance of physical locations, as it relates to the sales and support processes, is understood, the account hierarchy can be properly designed and process and policy can be introduced to maintain the account hierarchies and prevent duplicates in the system. Monitoring for duplicates in the system should be continuous as they will pollute the account hierarchy, become stragglers (or “lost” subsidiaries) and contribute to an increase in maintenance and hygiene issues.

To illustrate the importance of site, a company that sells software to the central IT department of its customers would have no reason to maintain branch site details in Salesforce.com. In this example, the company would just need one account/customer record that reflects to whom and where the license was sold..

But let’s say that an HVAC company sells and installs air handling equipment. Since each location or building makes the purchasing decision independently, all the locations for each target company should be captured in Salesforce.com such that each location can be marketed to and sold directly. Distributed decision making account hierarchies tend to have a larger number of account records in the hierarchy than centralized account hierarchies..

There may be hybrid situations between the two ends of the spectrum which is very common in larger multi-national companies where regional headquarters could play a role in the purchasing decisions. Depending on the legal structure and purchasing location, it may make sense to set up each regional headquarter as separate companies rather than under a single parent company.

Creating Account Records in Salesforce.com (SFDC)

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

1. How do you create Accounts in SFDC? There are two acceptable ways:

You acquire a list of accounts from a prospecting or targeted outreach list and you import them into SFDC.
A Lead record is converted into an Account record and Contact record in SFDC.

It is important to understand how much data is available at the time the account is created. A minimum data requirement should be enforced to make sure that all the key fields necessary for matching data is captured. Fields typically required for an Account include website, address, name, phone number, industry, number of employees, etc.

2. Do not automatically create an Account in SFDC from marketing and “contact us” forms from your website. Organizations that have taken this approach find A an enormous amount of junk, incomplete, and inaccurate data that can end up as accounts in SFDC. It’s a much better idea to send contact us forms through the lead process and have it qualified before creating an Account record in the system.

3. Automating the creation of Account records from trial signup forms. While this is not inherently a bad thing, there are a few scenarios that contribute to introducing bad data into SFDC including:

There is a natural tension between the number of details you ask for a person to complete for the trial to begin and the conversion rates. If you ask for too many details, people are discouraged from signing up for the trial. Therefore, it’s tempting to just create “trial” accounts with just an email address and nothing else. Frequently, free email are addresses are submitted making it 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 trial to selling to the company the contact is employed by – it’s important to be able to capture the name of the company the contact is affiliated.

4. Creating an account for every trial or signup from the web - It is very important when creating an Account for every trial or signup to de-duplicate the Account records before you create a new Account record 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 a storage company provisions 15GB of storage for a user, it should not link back 1:1 to the Account record of that user’s company. Implementing 1:1 linking results in duplicate Account records that adds to the pollution of the data hygiene in SFDC and exacerbates the hierarchy data problems mentioned in the previous sections.

These Account creation scenarios contribute to bad account data in SFDC. Establish strict policies around the creation of accounts and be BRUTAL in preventing duplicates from being created. Show No Mercy!

Using 3rd party data sources to enrich data

The use of 3rd party data sources and enrichment solutions can help keep 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 site locations matter or not (see above), you need to carefully pick the right data source for your target segments that can provide you those details.

Dunn and Bradstreet (D&B) and their properties are the largest data provider in the world of firmographic data. Their DUNS number puts a unique number for each organization and is a great tool to automate the creation of account hierarchies. Please see appendix below on how DUNS numbers are used for account hierarchies. Salesforce’s data.com platform uses D&B data.

There are a number of next generation data providers catering to non-site-based needs that use an organization’s internet domain(s) as the key to creating unique identifiers for each organization (akin to the DUNS number used by D&B).

There are a number of data providers in various countries internationally that provide company firmographic 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 fullcast.io Solution

There are three truths that guide fullcast.io creating a solution to automate the maintenance of the account hierarchies and general account cleanliness:

TRUTH 1 – There is no such thing as a bullet-proof, fully automated solution that always has the most accurate representation of reality. All solutions will require manual intervention.

TRUTH 2 – Always read TRUTH 1. If you skipped over it – please go back and read it.

TRUTH 3 – After reading TRUTH 1 again – your reps are likely to have more accurate data about the current reality than any automated 3rd party solution. Put a manual process in place to respond to this knowledge if it can have a positive effect on your selling effectiveness.

The fullcast.io solution depends on the creation of keys to group accounts together. The fullcast.io solution assumes that you have a solution for matching and enriching your account data – like a data.com or D&B Optimizer. You can use other solutions for this purpose and construct the keys using the principles identified below.

Using DUNS Numbers from data.com (D&B)

Please see the appendix for details on how the various DUNS numbers are used for the creation and the maintenance of the account hierarchy.

Here’s an excerpt of what each of the DUNS numbers mean from D&B ( http://www.dnb.com/content/dam/english/private/hp/Guide_to_Working_with_Family_Trees.pdf)

Each family member carries up to four D-U-N-S Numbers to link its corporate relationships.

D-U-N-S Number: The DUNS number that represents that specific entity / location.
Parent or Headquarter D-U-N-S: The DUNS number that represents the immediate entity above the site DUNS.
Domestic Ultimate D-U-N-S: The DUNS number that represents the highest member of the tree within the same country as the site DUNS as you walk up that arm of the tree.
Global Ultimate D-U-N-S: The DUNS number that represents the highest member of the entire family tree.

A branch record carries its own D-U-N-S Number (site), that of its headquarters, that of its domestic ultimate, and that of its global ultimate. A subsidiary carries its own D-U-N-S number (site), that of its parent, that of its domestic ultimate, and that of its global ultimate. The domestic ultimate is the highest member of the hierarchy in a specific country. The global ultimate record is at the very top of the global corporate hierarchy.