Salesforceテリトリー管理をマスターする：セールスパフォーマンスを向上させるためのコンサルタントガイド

日付:

背景と応用シナリオ

Salesforce コンサルタントとして、私は数多くの企業の営業組織改革プロジェクトに携わってきました。その中で頻繁に直面する課題の一つが、「誰がどのアカウントを担当するのか」という所有権の曖昧さです。特に、地理、業種、企業規模など、複数の要素で顧客をセグメント化している複雑な営業組織では、この問題は深刻化しがちです。担当者間の重複アプローチ、機会損失、不公平な目標設定、そして正確な業績評価の困難さ。これらはすべて、非効率な担当領域管理に起因する典型的な問題です。

ここで強力なソリューションとなるのが、Salesforce の Territory Management (テリトリー管理) 機能です。これは、単なるレコード所有者の割り当てを超えた、より戦略的で柔軟なアカウント共有モデルを提供します。Territory Management は、アカウント（取引先）を「テリトリー」と呼ばれる論理的なグループに分類し、そのテリトリーに属する Salesforce ユーザーにアクセス権を付与する仕組みです。

具体的な応用シナリオとしては、以下のようなケースが挙げられます。

地理ベースのテリトリー

最も一般的なシナリオです。国、都道府県、市区町村、郵便番号といった地理的情報に基づいてテリトリーを構築します。「関東支社」の下に「東京都」「神奈川県」といった子テリトリーを作成し、それぞれに担当チームを割り当てることができます。

業種・業界ベースのテリトリー

「金融業界担当チーム」「製造業担当チーム」「IT業界担当チーム」のように、特定の専門知識を持つ営業担当者を、該当する業界の顧客に割り当てます。これにより、顧客への提案の質が向上します。

Named Account (特定顧客) ベースのテリトリー

戦略的に重要な大口顧客（Named Account）に対して、専任のチームを割り当てるモデルです。キーアカウントマネージャー、技術営業、カスタマーサクセスといった複数の役割を持つメンバーが、一つのテリトリーを通じて同じ顧客情報を共有し、連携を深めることができます。

複合的なマトリクス組織

地理と業種を組み合わせた、より複雑な組織構造にも対応可能です。例えば、「関東支社 - 金融業界担当」といったマトリクス型のテリトリーを設計し、適切な担当者を配置することができます。これにより、一人のユーザーが複数のテリトリーに所属することも可能になります。

コンサルタントの視点から言えば、Territory Management の導入は、単なる機能設定ではなく、企業の営業戦略そのものをシステムに反映させる重要なプロセスです。適切なテリトリー設計は、営業効率の最大化、市場カバレッジの最適化、そして最終的には売上の向上に直結します。

原理説明

Salesforce の Territory Management は、現在 Enterprise Territory Management (エンタープライズテリトリー管理) と呼ばれるバージョンが主流です。これは従来のテリトリー管理（Original Territory Management）を大幅に機能強化したものです。ここでは Enterprise Territory Management の仕組みを解説します。

この機能は、いくつかの重要なオブジェクトモデルによって構成されています。

Territory2Model (テリトリーモデル)

テリトリー階層全体のコンテナです。企業は複数のテリトリーモデルを持つことができます。例えば、「2024年度 営業体制モデル」と「2025年度 新体制計画モデル」のように、異なる営業戦略を並行して設計・テストすることが可能です。モデルには「Planning (計画中)」「Active (有効)」「Archived (アーカイブ済み)」の3つの状態があり、一度に有効化できるモデルは一つだけです。このモデルの存在により、現行の営業体制に影響を与えることなく、次期体制のシミュレーションを行える点が大きな利点です。

Territory2 (テリトリー)

実際の営業担当領域を定義するオブジェクトです。テリトリーは階層構造を持つことができ、例えば「日本」テリトリーの下に「東日本」「西日本」があり、「東日本」の下に「関東」「東北」がある、といった親子関係を構築できます。各テリトリーには、後述する割り当てルールが紐づけられます。

Territory2Type (テリトリータイプ)

テリトリーを分類するためのラベルです。例えば、「Geographic (地理)」「Industry (業種)」「Named Account」といったタイプを事前に定義しておくことで、テリトリーの目的を明確にし、管理やレポート作成を容易にします。

Assignment Rules (割り当てルール)

Territory Management の心臓部です。このルールに基づいて、アカウントが自動的に適切なテリトリーに割り当てられます。ルールは、アカウントオブジェクトの項目（例：Billing Postal Code, Industry, Annual Revenue など）を条件として設定します。例えば、「Industry が 'Manufacturing' で、かつ Annual Revenue が 1億円以上」のアカウントを「大手製造業担当テリトリー」に割り当てるといった定義が可能です。これらのルールは、アカウントが作成または更新された際に実行されます。

UserTerritory2Association (ユーザとテリトリーの関連)

Salesforce ユーザーを特定のテリトリーに割り当てるための関連オブジェクトです。一人のユーザーが複数のテリトリーに所属することも、一つのテリトリーに複数のユーザーが所属することも可能です。

ObjectTerritory2Association (オブジェクトとテリトリーの関連)

主にアカウントがどのテリトリーに割り当てられているかを示す関連オブジェクトです。割り当てルールが実行されると、このオブジェクトのレコードが自動的に作成されます。

これらのコンポーネントが連携することで、企業の複雑な営業戦略を Salesforce 上で体系的に表現し、アカウントの割り当てとアクセス権管理を自動化することができるのです。

サンプルコード

Territory Management は主に設定画面（UI）で構築しますが、Apex を利用してテリトリー割り当てのプレビューや、カスタムロジックへの組み込みを行うことも可能です。コンサルティングの現場では、「もしこのアカウントの業種を変更したら、どのテリトリーに割り当てられるか？」といったシミュレーション機能をカスタム画面で提供したい、という要望がよくあります。

以下のコードは、Salesforce の公式ドキュメントで紹介されている TerritoryMgmt.AssignmentRuleEvaluator インターフェースを使用した例です。このクラスは、特定のアカウントが現在有効なテリトリーモデルの割り当てルールに基づいて、どのテリトリーに合致するかを評価するために使用します。

// TerritoryMgmt.AssignmentRuleEvaluatorインターフェースを実装したクラスを定義
public class MyTerritoryEval implements TerritoryMgmt.AssignmentRuleEvaluator {

    // 評価対象のアカウントIDを保持する変数
    private Id accountId;

    // コンストラクタで評価したいアカウントのIDを受け取る
    public MyTerritoryEval(Id accountId) {
        this.accountId = accountId;
    }

    // getAssignmentResultsメソッドの実装（インターフェースで定義されている）
    // このメソッドが、実際に評価ロジックを呼び出す部分
    public List<TerritoryMgmt.AssignmentResult> getAssignmentResults(List<Id> objectIds) {
        
        // 結果を格納するためのリストを初期化
        List<TerritoryMgmt.AssignmentResult> results = new List<TerritoryMgmt.AssignmentResult>();

        // 現在有効なテリトリーモデルのIDを取得
        // Territory2Modelは一つしか有効にできないため、リストの0番目を参照
        List<Territory2Model> models = [SELECT Id FROM Territory2Model WHERE State = 'Active' LIMIT 1];
        
        // 有効なモデルが存在する場合のみ処理を続行
        if (!models.isEmpty()) {
            Id activeModelId = models[0].Id;

            // SOQLを使用して、指定されたアカウントに一致するテリトリーを検索
            // ObjectTerritory2Associationはアカウントとテリトリーの関連を示すオブジェクト
            // AssociationCauseが 'Territory2Manual' でないものは、ルールによって割り当てられたことを示す
            List<ObjectTerritory2Association> associations = [
                SELECT Territory2Id, ObjectId
                FROM ObjectTerritory2Association
                WHERE ObjectId = :this.accountId
                AND Territory2.Territory2ModelId = :activeModelId
                AND AssociationCause != 'Territory2Manual'
            ];

            // 見つかった関連ごとにAssignmentResultを作成
            for (ObjectTerritory2Association a : associations) {
                // isSuccessをtrueに設定し、テリトリーIDを結果に追加
                TerritoryMgmt.AssignmentResult res = new TerritoryMgmt.AssignmentResult();
                res.isSuccess = true;
                res.territoryId = a.Territory2Id;
                results.add(res);
            }
        }
        
        // 評価結果のリストを返す
        return results;
    }
}

// 呼び出し元の実行コード例
// Id accountIdToEvaluate = '001XXXXXXXXXXXXXXX'; // 評価したいアカウントのID
// MyTerritoryEval myEval = new MyTerritoryEval(accountIdToEvaluate);
// TerritoryMgmt.runAssignmentRules(myEval);

このコードは、特定のアカウントIDをコンストラクタで受け取り、TerritoryMgmt.runAssignmentRules メソッドから呼び出されると、そのアカウントがルールベースで割り当てられているテリトリーのリストを返します。これにより、標準の割り当て処理をトリガーすることなく、割り当て結果をプログラムで取得できます。この仕組みを利用して、カスタムのシミュレーションツールや、複雑なデータ連携処理を構築することが可能になります。

注意事項

Territory Management を導入・運用する際には、いくつかの重要な点に注意する必要があります。

権限設定

テリトリーモデルの設計やユーザーの割り当てを行うには、「テリトリーの管理」システム権限が必要です。この権限は非常に強力なため、付与するユーザーは慎重に選定する必要があります。また、テリトリーに割り当てられたユーザーは、そのテリトリー内のアカウントや関連レコード（商談、ケースなど）に対して、定義されたアクセスレベル（参照のみ、参照・更新など）を持ちます。共有設定との関係性を十分に理解しておくことが重要です。

API 制限とパフォーマンス

数万件以上のアカウントに対してテリトリーの再割り当て（リフレッシュ）を実行する場合、処理に時間がかかることがあります。特に大規模な組織変更に伴うテリトリーモデルの大幅な改変時には、Salesforce のバックグラウンドで非同期処理が実行されます。処理が完了するまでの時間を考慮し、業務への影響が少ない時間帯に実行するなどの計画が必要です。また、Apexトリガーなどから大量の割り当てルール評価を同期的に呼び出すと、ガバナ制限に抵触する可能性があるため、非同期処理（@future, Queueable, Batch Apex）の利用を検討すべきです。

データ品質

割り当てルールはアカウントの項目値に依存するため、データの品質が極めて重要です。例えば、郵便番号や業種コードの入力が不正確だったり、未入力だったりすると、アカウントはどのテリトリーにも割り当てられず、営業担当者から見えなくなってしまいます。データクレンジングや入力規則の整備を、Territory Management 導入の前提条件として取り組むことを強く推奨します。

予測とレポート

Enterprise Territory Management を有効にすると、売上予測の機能が「テリトリー別売上予測」に切り替わります。従来のロール階層ベースの予測とは異なるため、既存のレポートやダッシュボードに影響がないか、事前に確認とテストが必要です。テリトリー階層に基づいた新しいレポートを作成する必要が出てくるでしょう。

まとめとベストプラクティス

Salesforce の Enterprise Territory Management は、複雑な営業組織におけるアカウントの割り当てとアクセス権管理を、戦略的かつ効率的に行うための強力なツールです。適切に設計・導入されれば、営業担当者の生産性を高め、市場カバレッジを最適化し、正確な業績評価を実現することができます。

Salesforce コンサルタントとして、成功する Territory Management 導入のためのベストプラクティスを以下に示します。

  1. ビジネス戦略から始める: テクノロジーありきで考えず、まず「どのような営業戦略を実現したいのか」を明確にします。市場セグメンテーション、顧客ターゲティング、営業リソースの配分といったビジネス上の要件を定義し、それを実現する手段としてテリトリーを設計します。
  2. ステークホルダーを巻き込む: テリトリー設計は営業部門全体に影響を与えます。営業部長、現場マネージャー、営業担当者など、関係者からヒアリングを行い、合意形成を図りながら進めることが、導入後の定着化の鍵となります。
  3. 計画モデルでシミュレーションする: 新しいテリトリー構造をいきなり本番適用するのではなく、必ず「Planning (計画中)」状態のモデルを作成し、そこで設計とテストを繰り返します。レポート機能を使って、新しいモデルでのアカウント分布や担当者ごとの負荷をシミュレーションし、バランスの取れた設計を目指します。
  4. シンプルさを心がける: 最初から完璧で複雑な階層を目指す必要はありません。まずは主要なセグメンテーション（例：地理）から始め、ビジネスの成長や戦略の変化に応じて、段階的に業種などの軸を加えていくアプローチが有効です。
  5. 継続的な見直しと改善: 市場環境や組織は常に変化します。半期や年度ごとなど、定期的にテリトリーの有効性をレビューするプロセスを確立しましょう。レポートやダッシュボードを活用して、各テリトリーの業績や活動量を分析し、必要に応じてテリトリーの境界や割り当てルールを調整します。

Territory Management は、一度設定すれば終わり、という機能ではありません。企業の成長戦略と共に進化し続ける、生きた仕組みとして運用していくことが、その価値を最大限に引き出すための最も重要なポイントです。

コメント

コメントを投稿