Before we dive into the specific use cases and how to solve for them, it is very important to document the solutions that you come up with 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.
Below are the various topics of policy that must be considered and documented to effectively handle account hierarchies and their life cycle.
Splits Policy – This is particularly important 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. You will have to clearly outline how these scenarios will be handled and how quota, credit and compensation will be impacted.
Duplicates – What defines a duplicate account in the system. You will want to take immediate action once it’s identified that an account is a duplicate of another and or it belongs to a different account hierarchy. 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 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. When these changes are done, it is important to have proper policy that manages any issues that may result from changes to the data. For example – if the account hierarchy or other details are changes because of a merger and acquisition – does this change the sales rep that is working on the account.
Treatment of non-sellable entities - like holding companies, private equities, etc. These entities must be tagged appropriately (either through third party data or through field intelligence) and then the appropriate hierarchy decisions made.
Coverage Policies - describes how various roles cover account families. It is very possible to have complex structures of coverage and it's even more important to document them in policy such that everyone in the sale motion is clear on the coverage model.
Treatment of sites, locations and departments - describe the handling of each individual branch or physical location of a business as it relates to your selling model. If you sell deep into large companies, describe in policy how to represent departments within these large organisations.
Coverage Planning for Account Families
Checkout how coverage planning of account families are accomplished in the fullcast.io Design App.
The above are some examples of policy definitions that will need to be put in place to support proper maintenance of the account hierarchy. This is a difficult 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 things are moved around.
Golden Rules for creating Sales Policies
At fullcast – we have a three Golden Rules that we like to suggest be followed in the creation of these policies:
RULE 1 – ALWAYS optimize for the customer experience and not the Rep experience. Keep your customer and their interaction with the company first and foremost in these scenarios. Moving sales people around in the middle of a sales cycle impacts customer satisfaction and experience.
RULE 2 – Encourage Team mentality among conflicting sales reps and teams. Always allow flexibility in the policy for the teams to work out the “fair” solution rather than dictating a solution for every possible scenario – because you will not be able to think of them all.
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.
Consult your GrowthOps business partner and they can share with you the fullcast.io templates for sales policies.
Updated about 2 years ago