An Oracle White Paper

January 2013

Oracle Fusion Sales Territory Concepts

Oracle Fusion Sales Territory Concepts

Disclaimer
The following is intended to outline our general product direction. It is intended for information purposes
only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or
functionality, and should not be relied upon in making purchasing decisions. The development, release, and
timing of any features or functionality described for Oracles products remains at the sole discretion of
Oracle.

Oracle Fusion Sales Territory Concepts

Table of Contents
Sales Territories: Functional Overview .............................................. 2
Territory Modeling Using Dimensions ............................................ 3
Territories in Sales and Marketing ................................................. 4
Sales Territories: Architectural Overview ........................................... 4
Sales Territories: Implementation Planning ....................................... 5
Sales Territories: Special Considerations .......................................... 6
Sales Territories: Additional Resources ............................................. 7

Oracle Fusion Sales Territory Concepts

Sales Territories: Functional Overview

Sales territories form the fundamental infrastructure of sales management because territories
define the jurisdiction that salespeople have over sales accounts. Territories define who can
sell what to whom. The hierarchy of territories secures access to sales accounts, leads, and
opportunities.
The sales manager's objective is to create territories with the best return on sales investment.
This means optimizing dozens of trade-offs to arrive at the optimal territory configuration. Sales
organizations try to configure territories to create equal sales opportunities. Past software
solutions, such as the Oracle E-Business Suite, have applied rule sets to sales account
attributes and opportunities to determine appropriate territory assignments. These rules can be
difficult to maintain without assistance from outside the sales organization. It is also difficult to
determine if new or modified rules are correct, that is, if territories have gaps or overlaps.
Oracle Fusion Territory Management uses multidimensional modeling to define territories that
take into account all the necessary criteria without requiring the definition of rules. Instead,
territories are defined as sets with logical boundaries, but can also include individually selected
sales accounts. Most of the criteria are modeled as hierarchical dimensions that form
boundaries for the territories. These dimensions form a "hypercube." The dimensional
boundaries are composed of a set of cells in this hypercube. There is no need to define
complex rules and worry about their order of execution because territories are defined using
dimension data in the hypercube as well as selected sales accounts.
Figure 1 shows an example of the hypercube containing data for the Industry, Product, and
Geography dimensions. The boxes identified as A represent a territory defined with all
industries, the Northwest geography, and the products Software and Service. The B boxes
represent a territory defined for all geographies and industries, but only the product Hardware.

Oracle Fusion Sales Territory Concepts

Figure 1. Territory Dimensions Hypercube

Territory Modeling Using Dimensions

Territories provide the rules for automatically assigning salespeople and other resources to sales
objects. Sales objects include sales accounts, partners, leads, and opportunity line items. Rather than
writing complex rules to define the boundaries of your territory, you select one or more dimensions
and define your territory using specific members of each dimension. For example, you can select the
geography dimension and specify countries, cities, or postal codes.
The structural hierarchy of territories controls resource responsibilities and access to customer and
sales data. Boundaries determine the selection of sales accounts, leads, and opportunity line items
assigned to a territory.
You can define territory boundaries using up to nine existing sales account dimensions. For example,
you can define a territory that includes sales accounts within a specific city and that are classified in the
clothing industry. The following dimensions can be used to assign sales accounts:

Account (Select specific named accounts)

Account Type (Named or Not Named are the two types)

Customer Size

Geography

Industry

Oracle Fusion Sales Territory Concepts

Organization Type

Auxiliary Dimensions 1, 2, and 3

Auxiliary Dimensions 1, 2, and 3 are dimensions that you create based on your selected customer
classifications.
Two additional dimensions apply to assigning leads and opportunity line items: Product and Sales
Channel.
In addition to using dimension members to automatically assign sales accounts or partners, you can
manually select specific sales accounts or partners to be included in a territory definition. Product and
sales channel definitions apply to leads and opportunity line items for the manually included sales
accounts..You can also select specific sales accounts or partners to be excluded from the territory
whether or not they match the rest of the territory definition.
The combination of dimension member selections and manually included and excluded accounts is
called the territory coverage.

Territories in Sales and Marketing

You can create multiple what-if territory definitions using territory proposals. Territory proposals do
not disrupt ongoing sales activities that are tied to the existing active territories. Use the following
methods to analyze your proposals, compare them to active territories, and determine the optimum
way to realign your territories:
Use metrics and graphs to understand the results of the changes to the boundaries of each
territory.

Use gap and overlap reports to find potential errors in your territory definitions.

Use the assignment preview to double check that each territory is getting the right accounts.

After thorough analysis, you then activate the best territory proposals.

Sales Territories: Architectural Overview

Territories form hierarchies, with a single parent for one or more children, and each child in turn can
have one or more children, and so on. The hierarchy is often similar to the sales resource reporting
structure, because resources can access information for all territories below their territory in the
hierarchy. Sales managers and sales administrators define and change territory definitions to support
sales goals.
Figure 2 shows the components of a sales territory. Resources, such as salespeople and consultants, are
manually assigned to a territory by the territory owner, a sales manager, or sales administrator. Metrics
information, such as closed revenue, is stored in the Oracle Essbase Cube for speedy retrieval of
analytical data for active and proposed territories. Defined boundaries of a territory drive the automatic

Oracle Fusion Sales Territory Concepts

assignment of sales accounts (or partners), leads, and opportunity line items to the territory, and
therefore to the resources (salespeople) for the territory.

Figure 2. Sales Territory Components

Sales Territories: Implementation Planning

The key to implementing sales territories is to determine what attributes you intend to use to define the
boundaries of your territories. Do your salespeople cover different geographic areas? Do sales teams
specialize in selling to customers in certain industries? Do you use a special sales team for launching a
new product? Your implementation makes sure the dimensions and supporting data are available to
enable defining territories that support your company's sales goals.
Following is the high-level sequence for implementing sales territories:
1.

Set up source data.

Set up the data that populates the dimensions you plan to use. For example, for the Geography
dimension you need geography data with validation enabled, and a territory geography zone

Oracle Fusion Sales Territory Concepts

hierarchy. Set up the product catalog if you want to use the Product dimension. Lookup codes and
customer classification categories support other dimensions.
2.

Enable the dimensions that you plan to use.

3.

Adjust the visibility of dimension data, called dimension members.

4.

Enable the metrics to be used for analyzing territories.

5.

Synchronize data from the various sources to your territory dimension data.

6.

Populate the Oracle Essbase cube with metrics data. This is done during the synchronization.

7.

Enter your salespeople as resources.

8.

Create territories

Use Oracle Fusion Functional Setup Manager to manage and perform your implementation tasks.
Navigate to Setup and Maintenance to use Functional Setup Manager. Following is the list of tasks in
Setup and Maintenance for implementing territories:
1.

Define Territory Management Lookups

You can modify the list of values for certain fields, such as Territory Type, by modifying the lookup
codes.

2.

Define Territory Management Profile Options

For example, select the sources for data to populate certain dimensions, such as the Industry
dimension and auxiliary dimensions.

3.

Define Territory Management Dimensions

Tasks include enabling the dimensions that you plan to use and identifying the dimensions members
that will be visible for selection when defining territories.

4.

Manage Territory Management Synchronization

The synchronization populates dimension member data and metrics data from source data.

5.

Manage Territory Management Schedulable Processes

Schedule the process that activates new territory definitions to run periodically.

Sales Territories: Special Considerations

The following are special considerations for implementing sales territories:

Without sales territories implemented, you manually assign resources to sales accounts, leads, and
opportunity line items. You cannot perform sales forecasting or quota management without
territories.

Accounting calendars are set up in the Oracle Fusion Financials Common Module. One calendar
is specified with a profile option to be used for all of CRM and should not be changed.

Data warehouse for populating dimension data is only available for on premise implementations.

Oracle Fusion Sales Territory Concepts

Sales Territories: Additional Resources

This topic provides references to additional information about implementing and using sales territories.
RESOURCE

DESCRIPTION

Oracle Fusion

Compilation of implementation help topics organized by the list of implementation

Applications Sales

tasks for the Sales offering.

Implementation Guide

Contains explanations of concepts and processes used when implementing

territories.

Oracle Fusion

Compilation of functional help topics organized by sales application.

Applications Sales

Contains conceptual information explaining the components of territories, and

Guide

provides examples for defining territories.

Oracle Fusion Sales Territory Concepts

Copyright 2013, Oracle and/or its affiliates. All rights reserved.

January 2013
Oracle Corporation

This document is provided for information purposes only, and the contents hereof are subject to change without notice. This

World Headquarters

document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in

500 Oracle Parkway

law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any

Redwood Shores, CA 94065

liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document. This

U.S.A.

document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our

Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com

prior written permission.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and
are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are
trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 0113