営業テリトリーのヒントとコツ

学習の目的

この単元を完了すると、次のことができるようになります。

• ロール階層とテリトリー階層がどのように連動するのかを説明する。
  
• テリトリーの積み上げ集計売上予測を表示する方法を説明する。
  
• 外部の一元化された情報源と同期する方法を説明する。
  
• データをクリーンアップするベストプラクティスを挙げる。
  
• 指名取引先の処理についてのヒントを挙げる。
  

はじめに

Maria は営業テリトリーに関連するパフォーマンス低下の解決について多くのことを学びました。

ただし、Capricorn Solar の営業テリトリー、取引先、担当が反映されるように機能の設定を完了した Maria には、まだ他にも学ぶべきことがあります。

この単元では、さまざまなトピックに関する Maria の残りの質問に答え、さらに詳しく学びます。

階層構造の重複の回避

Maria は Ursa Major のテリトリー階層にさらに変更を加える必要があり、どのような構造にしたらよいのか自信がありません。ユーザーロール階層を基にしたらよいのでしょうか?

いいえ。営業テリトリーで提供される取引先、商談、連絡先責任者、ケースへのアクセスレベルは、ロール階層に積み上げられます。ロール階層の営業ブランチにテリトリー構造を複製することは不要な重複です。

代わりに、ロール階層を使用して、管理リレーション、レポートの積み上げ集計、承認やその他の階層ワークフローを表します。これらの目的のために、ロールが 1 つだけ含まれるようにロール階層の営業ブランチを簡略化します。次に、テリトリー階層を使用して、ユーザーのテリトリー割り当てに基づいてレコードへのアクセス権を拡張します。

ロール階層とテリトリー階層が適切に使用されている場合、相互が補完され、企業情報のレポート、分析、セグメント化の二重モデルが提供されます。

• ロール階層は、1 人の上司に部下が 1 人しかいない、管理や人事のレポート構造種別をモデル化するのに最適です。
  
• テリトリー階層は、ユーザーが複数のマネージャーの部下になることができる、マトリックスレポート構造のモデル化に最適です。
  

テリトリーの積み上げ集計売上予測の表示

Ursa Major の営業チームは、コラボレーション売上予測を使用しており、最近テリトリーの売上予測を有効にしました。テリトリーの積み上げ売上予測金額がチームに表示されるようにするには、Maria はどうしたらよいでしょうか?

売上予測マネージャーを、積み上げ売上予測金額が必要なすべてのテリトリーに割り当てます。たとえば、AMER テリトリーの売上予測が毎月必要な場合、実際に管理しているマネージャーがいなくても、AMER テリトリーを売上予測マネージャーに割り当てます。

下位テリトリーのない各テリトリーに、売上予測マネージャーを割り当てるかどうかを決定します。

たとえば売上予測ユーザーに表示されるテリトリー売上予測は、次のようになります。

一元化された情報源との同期

Maria は営業テリトリーを設定する前に、Ursa Major テリトリーの外部の一元化された情報源を使用しました。このデータは今も有用です。営業テリトリーとこのデータを同期するには、どうしたらよいでしょうか?

カスタム外部 ID 項目を作成してテリトリーページレイアウトに追加することをお勧めします。

テリトリー階層と外部の一元化された情報源を統合する場合、その情報源に基づいてテリトリー階層を作成し、テリトリーの管理に使用します。ただし、このプロセスは自動的には行われません。データをインポートするか、API を使用する必要があります。テリトリー階層と外部の一元化された情報源の同期を保つために定期的に管理してください。

メモ: カスタム外部 ID 項目を一意として定義した場合は、テリトリーモデルを複製できません。

割り当てルール検索条件を使用したその他の操作

割り当てルールは、検索条件項目が 10 個までに制限されていることに気付かれたことでしょう。Maria は Capricorn の取引先のルールを設定していますが、この制限は彼女にも適用されます。これをどのように回避できるでしょうか?

条件エントリ数がビジネスの要件を満たさない場合は、数式項目を使用して、取引先の複数のデータ項目を組み合わせます。たとえば、必要な条件項目が 10 個を超える場合、[国(請求先)] 項目と [都道府県(請求先)] 項目を組み合わせて 1 つの数式項目を作成できます。「リソース」セクションに、数式項目について詳しく学ぶことができるリンクを記載しています。

条件が取引先の関連レコードに基づく場合、積み上げ集計項目かトリガーを使用して、取引先にデータを移動します。次に、それらの項目を使用して、取引先割り当てルール条件を適用します。

10 個の条件項目を使用できますが、6 個以下にすることをお勧めします。

最初にデータのクリーンアップ

Maria は Salesforce アプリケーションのデータに、レコードの重複などの問題があることに気付きます。テリトリーモデルを変更しているときに、テリトリー割り当てルールを使用してデータをクリーンアップするというアイデアが浮かびます。いい考えだと思いませんか?

実は、データをクリーンアップするために、特にどの取引先にリードを関連付けるかを判断するときに、テリトリー割り当てルールを使用することはお勧めしません。データのクリーンアップはテリトリー割り当てとは切り離して行い、テリトリールール構造をリーンにしておきます。

次を使用することをお勧めします。

• 組み込みの重複管理機能で重複するレコードの管理とマージを行う。
  
• Lightning Data で、レコードを常に最新に保ち、最優良顧客に類似する新しい取引先を見つける。
  

「リソース」セクションに、重複管理機能と Lightning Data について詳しく学ぶことができるリンクを記載しています。

指定取引先の効果的な定義

多くの企業同様、Capricorn Solar にはいくつか指定取引先があります。これはその管理に適任の営業担当に割り当てられる大口顧客です。通常、指定取引先には、San Francisco などの営業テリトリー名ではなく、Solar Emporium など会社の名前が付けられます。Maria は指定取引先を扱った経験がないので、アドバイスを求めています。

標準の取引先割り当てルール構造内での指定取引先の定義には、いくつか戦略があります。

• ルール条件にある名前で取引先を定義します。取引先名は長くなる場合があるので、テリトリー内で定義された指定取引先の数が少ない小規模の顧客には、この戦略を使用することをお勧めします。
  
• 取引先名より簡潔な取引先番号に基づいて条件を定義します。この戦略では、営業チームはテリトリー内により多くの指定取引先を含めることができます。
  
• 本社の取引先レコードの属性に基づいて条件を定義します。顧客は数式項目または Apex を使用して、同じ取引先ファミリーにあるすべてのレコードに、本社の取引先の属性を指定できます。この方法では、同じ取引先ファミリーのすべての取引先を割り当てるために同じ条件セットが使用されます。
  
• 前のソリューションに適切な拡張性がない場合は、カスタマイズした割り当てソリューションを開発します。
  

API を使用した時間と労力の節約

Capricorn のテリトリー構造のために、Maria は自分のテリトリー階層が頻繁に変更されるだろうと考えています。頻繁に行われるテリトリーの再配置を簡略化するために何ができるでしょうか?

一部のお客様は、テリトリーの再配置を毎月、毎週、または毎日行い、大きなルールベースに更新情報を頻繁に送信しています。このようなお客様は、ルール構造を更新する自動化プロセスで、効率化を図ることができます。

標準の取引先割り当てルール構造のメンテナンスは、API を使用して自動化することをお勧めします。標準ルール構造をカスタマイズすることはお勧めしません。

メモ: Salesforce の標準ルール構造はリレーショナルで、幅広い顧客ベースに十分な柔軟性を提供します。規模の大きいお客様がこの標準ルール構造を維持することは、技術的には実現可能ですが、リレーショナル構造によって自動化メンテナンスが難しくなります。

不要な共有再適用の回避

Ursa Major では、チームセリングを採用しています。Maria は取引先の所有権の割り当てについて助けが必要です。また「営業テリトリーで解決」するでしょうか?

ある程度はそうかもしれません。営業テリトリーでは、取引先所有者が自動的に割り当てられたり、変更されたりすることはありません。ただし、お客様の中には、1 つ以上のテリトリーに複数の担当が割り当てられている場合、取引先所有者の代理として「ダミーユーザー」や「インテグレーションユーザー」を割り当て、その後、テリトリーに担当とロールを割り当てて、担当と取引先間の関連付けをモデル化しているところもあります。

この方法だと、共有再適用 (つまり取引先所有者の更新から生じる下流レコードの変更) の必要がなくなります。

また、Apex または別のプログラム型リソースを使用して、割り当て済みテリトリーユーザーを取引先所有者として指定することもできます。

営業テリトリーを使用した効率の向上

Maria の作業はもう少しで完了します。彼女は、Capricorn を買収した Ursa Major の取引先チームを採用すべきかどうか考えています。営業テリトリーと取引先チームを同時に使用できるのでしょうか?

営業テリトリーを使用している場合は、取引先チームを使用しないことをお勧めします。

どちらの機能にも、取引先、レコードに必要なアクセスコントロール、レポートの積み上げ集計に適切な担当を割り当てるメカニズムがあります。

ただし、営業テリトリーのほうが、積み上げ集計の階層構造、売上予測、自動的に取引先に担当を割り当てる機能に優れています。また、取引先チームから営業テリトリーに移行し、共有とレポートの要件を簡略化したお客様もいます。プロセスを自動化する場合、または営業チームの大きな増員が見込まれる場合は、営業テリトリーを使用することを検討してください。

まとめ

Maria は、Ursa Major による Capricorn Solar 買収に対応するために必要なことをすべて学びました。営業テリトリー機能には、両社の合併した営業テリトリー、取引先、担当が反映されるようになりました。Maria はよく頑張りました!

学んだ知識をテストする準備はできていますか?

リソース

• Salesforce ヘルプ: テリトリーへの売上予測マネージャーの割り当て
• Salesforce ヘルプ: 重複レコードの管理
• Salesforce ヘルプ: サードパーティデータとレコードの統合
• Salesforce ヘルプ: 数式項目の作成
• SOAP API 開発者ガイド: AssignmentRuleHeader