Best Practice - Territory Management

Best PracticeTerritory Management – is it a fit for your requirements?

Author: Jeanine Thorpe

Created Date: 2006

Version: 1.0

Updated by Version Date Comments

Best Practice – Territory Management – is it a fit for your requirements?Page 1 of 5

Is Territory Management a Fit for your Requirements?

Territory Management ™ is a very powerful feature and it is the RIGHT solution for many customers. However, it is important to balance the effort of deploying and maintaining it against the likely benefits. There is significant overhead to administering TM and customers need to recognize that. Plus, once it is enabled, there is no going back.

Before reviewing a few typical customer scenarios, I want to stress that testing TM in Sandbox is still strongly recommended. Customers without a Sandbox can have the feature enabled in their production environment, yet I would caution any but the most sophisticated customers against this approach. If you decide to deploy TM, we suggest working with salesforce.com Professional Services or a certified consulting partner who has done other TM implementations. It is worth the investment to get the setup done right.

What follows is a series of common customer requirements along with a TM fit assessment and a possible work around. This document is meant to help you decide whether TM is right for you company. If you decide that it is, log a case with Technical Support and get the process started.

We frequently realign territories.

This is common as companies grow or change to meet new market opportunities. In most cases it is much easier to use the Mass Transfer utility than to deploy TM. If accounts are realigned because reps leave the company, mass transfer is definitely the way to go. Generally, simple transfers from rep A to rep B, or from rep A to reps B and C, are best handled with mass transfers.

As the number of records and the number of reps increases, TM becomes a more viable option. If you decide to use TM reassigning accounts and opportunities will, in most cases, require making changes to the territory assignment rules and the list of users assigned to the territory. These can be complex changes with implications across the territory hierarchy.

We need to share opportunities.

In a private or read only model proper TM setup can allow reps to edit opportunities owned by other reps. But this can also be accomplished through sharing rules and/or the use of opportunity selling teams. Explore these simpler approaches first before considering TM.

If the sharing requirements are based on particular types of accounts (e.g. Industry verticals, global accounts), TM might be the way to go. One example would be members of a global account team that need to see all opportunities at Hewlett Packard subsidiaries, regardless of who owns the account or the opportunity. TM is a great way to manage this.


We want to assign Leads based on territories.

This is an easy one. Currently, TM does not apply to leads. It can be used to assign accounts and opportunities, but not leads. If you want to assign leads based on territory use Salesforce’s standard lead assignment rules. In the more complex scenarios, try using a formula that sets a value in a custom “territory” field which is then used in assignment rule entries.

TM could be used to properly assign new accounts and opportunities resulting from lead conversion. In a low transaction volume environment, administering TM is probably more work than manually assigning records. However, in high volume environments TM could result in time savings and better accuracy.

We need to manage deal splits.

Customers often hope that TM will help them manage opportunity splits where reps from different territories should be compensated on the same deal or where a deal needs to roll to more than one forecast. This is not the case. With TM there is still a one to one relationship between an opportunity and a forecast. The only way to manage opportunity splits with native functionality is to create multiple opportunities for each deal. A consistent naming standard that identifies all reps and their percentage of the overall opportunity can help to manage this.

We have reps who need to roll a forecast to more than one manager.

This is a situation where TM is a perfect fit and is one of the core issues the feature was designed to address. It definitely takes planning to get this working correctly, but with TM individuals can belong to multiple territories and roll a forecast up to more than one end point. If a user belongs to 10 territories, they can submit 10 different forecasts to ten different managers.

We have inside sales reps who support field reps in more than one region.

Depending on the size of the company it is not unusual for a small pool of insides sales reps to support a larger group of field reps covering the globe or a whole country. One inside sales rep may work deals for field reps who roll up to different managers. This sounds like a good fit for TM since this is tough to do with a regular role hierarchy, but consider your options. Do the inside sales reps really need to own and forecast opportunities? In many cases it makes more sense for the field rep to own all opportunities, but have the inside sales person as a default member of the selling team. This gives the inside person access to the opportunity, but keeps the forecast much simpler.

We have complex overlays in the way we sell.


This is probably a combination of two requirements addressed above: the need to share based on certain account parameters and/or the need for individuals to submit more than one forecast. Again, consider your options. Can you manage overlays using team selling or sharing rules? Which members of the overlay team will need to submit a forecast? If there is a one to one relationship between the forecast user on the overlay team and the forecast manager, TM is not necessary. However, if various members of the overlay team are submitting forecasts to various managers, TM is probably the best approach.

A few final caveats

Flipping the switch to enable TM does cause a number of immediate changes to your setup, so make sure you understand the implications before moving forward. On at least one occasion, a customer enabled TM without performing the due diligence to determine if the feature was a fit. The initial impact did not look significant and they did not do any configuration of territories. In subsequent weeks they realized that new opportunities were not rolling into the forecast – opportunities were not being associated with territories because there were no territory definitions to drive the association. If you use customizable forecasting make sure you understand this.

Here is a list of what changes immediately:

The name of the organization is set as the top of the territory hierarchy. For each role in the forecast hierarchy, a corresponding territory is created in the new

territory hierarchy. Active Salesforce users are added to territories based on their roles. Opportunities are assigned to the opportunity owner's territory. Accounts are not assigned anywhere in the territory hierarchy. Until you add or edit territories, your forecasts will work the same as they did before

you enabled territory management.

None of this is meant to scare you away from deploying TM if it is the best way to meet your requirements. It is simply meant to arm you with the information you need to be confident in your decision.

Good luck!



Documents

Best Practice - Territory Management