Sales・CSをまたぐテリトリーデザイン：対立なしに共有するブックの構築

著者: Tracy N · 更新日: 2026年5月4日

対立はほぼいつも同じように始まります。営業はQ3の計画でテリトリーモデルを設計します：AEが地域、セグメント、または業種で分担し、取締役会がヘッドカウントを承認します。CSは同じ四半期に、通常は別の計画プロセスでカバレッジモデルを設計します：CSMがアカウント数、地域、または製品ラインで割り当てられます。どちらのチームも、AEがCSMが予期していなかったテリトリーで新規ロゴをクローズするか、CSMがAEがまだ「自分の」と考えているアカウントで拡張機会を特定するまで、相手がどのように構成されているかを完全には把握していません。

衝突点はほぼ常に更新です。3年前に元の取引をクローズしたAEが再関与しようと戻り、CSMの関係を踏みにじり、誰が商業的な会話をリードすべきかを争います。18か月間アカウントを管理してきたCSMは、自分の採用作業を可能にした取引から疎外されます。どちらのシナリオもテリトリーの問題ですが――顧客が異なるVPに報告する2人が、自分たちが顧客を「所有している」と暗黙的に主張しているのを見ているときには、対立として表面化しています。更新オーナーシップフレームワークは、そうした曖昧さが顧客に届くのを防ぐための仕組みです。

境界部でのテリトリーデザインとは、ヘッドカウントスプレッドシートに行を追加することではありません。対立が始まる前に共有ブックのロジックを組み込むことです。

4モデルのテリトリーデザインは、共有するSales-CSのブックオブビジネスを、4つの異なるカバレッジ構造（業種アライメント、地域アライメント、アカウントサイズのティア（ARRバンド）、ハイブリッド）で構造化するためのフレームワークです。各モデルには、適用条件、失敗パターン、必要なキャパシティ比率が定義されています。どのモデルが適切かは、製品の複雑さ、セグメントの構成、そしてCSMの価値創出が業種特有か、関係の近さに依存するか、ARRバンドで決まるかによって決まります。

引用可能な指標： 「収益チームの44%が、更新遅延の主な要因としてオーナーシップの曖昧さを挙げています（Gainsightの「State of Customer Success」レポートより）。SalesとCSの間のテリトリーのミスアライメントが、その主な構造的原因です。CRMでの共有ブックの定義を、RevOpsが四半期ごとにレビューすれば、この曖昧さは顧客に届く前に解消されます。」

引用可能な指標： 「テリトリー変更（担当者の離職、セグメントの再分類、企業買収）によるアカウントの移行は、再割り当て後の6か月間にChurnリスクを3～5倍高めます（Bain & Companyの調査より）。テリトリーの安定性は、運用上の好みではなく、測定可能なリテンションのレバーです。」

重要データ：ミスアライメントしたテリトリーデザインのコスト

• Gainsightの「State of Customer Success」レポートによると、収益チームの44%が「オーナーシップの曖昧さ」を更新遅延のトップ要因として報告しており、テリトリーのミスアライメントが主要な構造的原因として挙げられています。
• TSIA 2024年の収益チーム連携に関する研究によると、SalesとCSの間で正式な共有テリトリー定義を設ける企業は、更新サイクルの長さを平均18日短縮します。
• テリトリー変更（担当者の離職、セグメントの再分類、企業買収）によるアカウントの移行は、Bain & Companyの顧客関係継続性に関する研究によると、再割り当て後の6か月間にChurnリスクが3～5倍高まります。

境界でテリトリーデザインが重要な理由

ほとんどの企業は、SalesのテリトリーデザインとCSのカバレッジデザインをまったく別の計画作業として扱っています。Gartnerは、テリトリー管理を、営業担当者がセグメントごとに整理された顧客の優先順位づけと管理を行うプロセスと定義しています。この定義はCSのカバレッジについて何も語っておらず、それがまさに問題です。Sales VPは地域、業種、またはアカウントサイズのバンドで区割りします。VP CSはCSMのアカウント負荷と割り当てルールを決定します。両計画は同じCROまたはCEOによって承認されますが、オーバーラップのロジック――両チームが同じアカウントに接触しているとき誰が何を所有するか――はほとんど明示的ではありません。

結果として3つの失敗モードが生まれます。

孤立したアカウント。 AEがCSチームがまだスタッフを配置していない業種で新規ロゴをクローズします。アカウントはCSMなしで30～60日間放置されます。最初の90日間にCSMがいないアカウントの初年度Churnは、すぐにCSMが割り当てられたアカウントより大幅に高くなります。テリトリー計画にはこのギャップを誰が対応するかの答えがありませんでした。

カバレッジの争い。 アカウントがSMBからミッドマーケットにアップグレードします。2年前にクローズしたSMBのAEはまだそれが自分のアカウントだと考えています。そのテリトリーが属するようになったミッドマーケットのAEはオーナーシップを引き継ぐことを期待しています。実際の意思決定者との関係を持つCSMはどちらのAEと一緒に仕事をすべきかわかりません。顧客は内部の議論が解決される間、混乱した体験を受けます。

コミッションの衝突。 CSMが拡張機会を特定します――新しい部署が製品を採用したいと考えています。元のAEはそれについて聞き、「取引をサポートする」ために登場します。両者がコンプを期待します。テリトリーと帰属ルールが事前に書かれていなければ、事後的にこれを解決することになり、誰かが不満を感じます。expansion ownership and upsell motionの記事では、こうした争いを防ぐ帰属のフレームワークを紹介しています。

境界でのテリトリーデザインとは、これらの決定が争いになる前に行うことです。

4つのテリトリーデザインモデル

Sales-CSの共有テリトリーを構造化する方法に普遍的な正解はありません。選択は製品、セグメント、CSMが実際にどのように価値を創出するかによって異なります。実践される4つのモデルを紹介します。

モデル1：業種アライメント

AEとCSMの両方が同じ業種を担当します。金融サービスを担当するAEは、金融サービスを担当するCSMとペアになります。ポッドまたは共有ブックの全員が業種特有の専門知識を持ち、コンプライアンス要件について話し、その業種のステークホルダーマップを知っています。

機能するとき： 製品の価値提案が業種特有で、顧客との会話が深い業種知識を必要とする場合。HIPAA準拠のワークフロー要件について話せるヘルスケアのCSMがいるワークフロー自動化ツールは、すべてのミーティングで基本的な質問をしなければならないジェネラリストCSMよりもはるかに効果的です。

壊れるとき： 顧客ベースが業種できれいにクラスター化されない場合、または1つの業種がARR分布で著しく不均等になる場合。ARRの60%がフィンテックにあるが、CSMの業種カバレッジモデルがCSMの20%しかそこに割り当てていない場合、比率の計算がモデルを損なう妥協を強制します。

モデル2：地域アライメント

AEとCSMの両方が同じ地域をカバーします。東海岸のAEは東海岸のCSMとペアになります；EMEAチームには専任のCSカバレッジがあります。価値はタイムゾーンのアライメントと、関連する場合はオンサイトの関係へのアクセスです。

機能するとき： 製品がオンサイトの実装を必要とし、QBRが対面で実施され、または関係が物理的な近接性によって駆動される場合（製造業、医療システム、政府市場で一般的）。地域アライメントはまた、営業チームが強い地域テリトリーのアイデンティティを持ち、CSがそれを横断した場合に調整の摩擦が生まれる場合にも機能します。

壊れるとき： 現代のSaaS製品は製品自体に地域アライメントを必要とすることはほとんどありません。CSMがアカウントを完全にリモートで管理している場合、地域アライメントは本物の運用要件ではなく、旧来のフィールドセールスモデルの遺物かもしれません。また業種の専門知識を分散させる可能性もあります――西海岸の3人のCSMがフィンテック、ヘルスケア、製造業を同時にカバーし、それぞれに浅い専門知識しか持てない。

モデル3：アカウントサイズのティア（ARRバンド）

テリトリーは地域や業種ではなくARRバンドで定義されます。ARR 2万5,000ドル未満はプールされたSMBのCSチームへ。2万5,000～10万ドルは30～40のアカウント負荷を持つミッドマーケットのCSMへ。10万ドル以上は12～20のアカウントを持ち、名前のあるエンタープライズAEとペアになるエンタープライズCSMへ。

機能するとき： CSMのキャパシティ比率が拘束的な運用上の制約である場合、そしてCSサービスの経済性がARRバンドによって大幅に異なる場合。エンタープライズアカウントは高タッチの名前のあるCSMカバレッジを正当化します。SMBアカウントは経済的に成立するためにプールされたカバレッジが必要です。ARRバンドモデルはこれを明示的にします。

壊れるとき： ARRバンドモデルはティア移行時にChurnリスクを生み出します。ARR 2万2,000ドルから2万8,000ドルに成長したアカウントは、SMBプールから名前のあるミッドマーケットCSMに再割り当てされます――顧客が最も関与しているその瞬間に関係を混乱させる移行です。これをうまく管理するために明示的な移行プロトコルが必要です。SMBからエンタープライズまでのアライメントスペクトラムでは、その移行プロトコルがセグメントごとにどう異なるかを整理しています。

モデル4：ハイブリッド（名前あり＋業種＋プール）

複数のセグメントを持つ企業のデフォルト。エンタープライズアカウントは名前あり――特定のAEとCSMが特定のロゴを所有します。ミッドマーケットのテリトリーはARRバンド内の業種で定義されます。SMBは自動割り当てでプールされます。

50以上の顧客を複数のセグメントにまたがって持つほとんどの企業は、最終的にはそのように設計したかどうかにかかわらず、ここに行き着きます。ハイブリッドモデルの利点は、ARRが正当化するところに高タッチのCSリソースを割り当て、SMBの経済性を維持できることです。その複雑さのコストは、どのルールがどのセグメントに適用されるか――そしてアカウントがセグメントの境界を越えたときに何が起きるか――を明確に文書化する必要があることです。では、その進化が起きる前に、適切な出発点をどう選べばよいのでしょうか。

意思決定の要因：適切なモデルの選択

業種アライメントを使用するとき： 製品の商業的価値が業種特有で、CSMが業種内で本物の専門知識を発展させられる場合。閾値：カバレッジの冗長性を維持するために業種ごとに最低3～4人のCSM。Forresterのテリトリーデザインへの体系的なアプローチは、業種の区割りを確定する前に、セグメントごとの獲得可能な市場全体のデータを評価することを推奨しています。テリトリーのポテンシャルが不均衡であることが、業種アライメントが1年以内に崩れる最も多い理由です。

地域アライメントを使用するとき： オンサイトの関係管理が（好ましいだけでなく）本当に必要な場合、または営業チームが強い地域テリトリーのアイデンティティを持っていてCSがそれを横断すると調整の摩擦を生み出す場合。テスト：QBRの90%がビデオコールで行われているなら、地域アライメントはおそらく要件ではなく遺物です。

アカウントサイズのティアを使用するとき： CSMのキャパシティが主要な計画上の制約であり、異なるARRバンドの経済性が本当に異なるサービスモデルを必要とする場合。これは顧客ベースがSMBからエンタープライズにまたがる企業にとって最も運用的に誠実なモデルです。

ハイブリッドをデフォルトとして使用する： 3つ以上の市場セグメントと30人以上のCSMを持つすべての企業に。ハイブリッドは妥協ではありません――異なるセグメントが異なるカバレッジロジックを必要とし、すべてに1つのモデルを適用すると、各セグメントに意図的に設計するより悪い結果をもたらすという認識です。

共有ブックの構築

共有ブックとは、特定のAEとCSMが共同で所有するアカウントのセットです。テリトリーモデルを正しくすることよりも共有ブックの定義を正しくすることの方が重要です――なぜなら共有ブックがコンプ計算、更新オーナーシップルール、CRM自動化を動かすからです。

共有ブックに属するもの： アクティブな顧客のみ。見込み客は契約署名まで営業が所有します。Churnしたアカウントはアーカイブされます。共有ブックは現在両チームが責任を持つライブの契約済みARRです。

名前付きアカウントリスト： 誰がそれを作成し、誰が維持し、どのくらいの頻度でレビューされるかは運用の整合性にとって重要です。ベストプラクティス：RevOpsがCRMのマスター名前付きアカウントリストを所有し、四半期ごとのスケジュールで更新します。McKinseyのCustomer Success 2.0の調査は、アカウントプランニング（各アカウント内でSalesとCSの担当範囲を明確に定義すること）を、テリトリーの争いが顧客に届くのを防ぐ運用上の要としています。AEとCSMは変更を提案できます；RevOpsが承認して実装します。誰かの頭の中にのみ存在する非公式の「これは私のアカウント」テリトリーはありません。両チームが使うシステムにRevOpsがこれらのルールをどう組み込むかについては、アライメントの接着剤としてのRevOpsを参照してください。

グリーンフィールドと既存アカウント： 新規ロゴの獲得と既存アカウントの管理は異なるテリトリールールに従います。AEは既存の顧客ベースを超えてグリーンフィールドのテリトリー（まだ契約がない顧客にアプローチできるアカウント）を持つかもしれません。これは意図的です――AEには既存顧客ベースを超えて見込み客を開拓してほしいのです。共有ブックは契約署名時にのみ確定します。

CSMがいないアカウント： これはほとんどのテリトリーデザインで最も危険なギャップです。アカウントがクローズし、CSMの割り当てキューが3週間バックアップされています。その間、アカウントはオンボーディングサポートを受けられず、初期採用のマイルストーンを逃し、初日からの初年度Churnリスクが積み上がります。テリトリーデザインは回答しなければなりません：CSMの割り当てを待っているアカウントのデフォルトのCSオーナーは誰か（通常はチームリードまたはプールカバレッジのCSM）。

カバレッジ衝突のシナリオと解決ルール

これらのルールは対立が起きる前に書いておいてください。事後的には、すべての解決が誰かの敗北のように感じられます。

シナリオ1：AEがCSMのテリトリーで新規ロゴをクローズし、CSMが更新を管理している間。 解決ルール：新規アカウントは最初の連絡まで14日のSLAでCSMのキューに入ります。CSMのキャパシティが超過している場合、アカウントはプールカバレッジのCSMに90日間移り、その後再割り当てされます。CSMはアカウントを永久に失いません――キャパシティが確保でき次第それを受け入れます。

シナリオ2：CSMが拡張機会を特定した――AEはコミッションを得るか？ 解決ルール：拡張取引がクローズする前にコンプ計画でこれを定義します。一般的なアプローチ：CSMが発掘した場合はCSMが拡張クレジットを得ます；AEは商業プロセスに招待されますが、交渉を主導しない限りコミッションを得ません。AEが拡張を発掘しCSMがサポートした場合は、AEがコミッションを得ます。帰属はCRMで最初に機会を登録した人によって決定されます。

シナリオ3：アカウントのティアが変わる――テリトリーの再割り当てがトリガーされる。 解決ルール：ARRティアの移行は即座の再割り当てではなく30日のハンドオフウィンドウをトリガーします。現在のCSMが次のCSMにブリーフィングし、顧客がコンテキストとともに新しいCSMに紹介され、共同QBRが提供されます。未解決の更新交渉の途中でアカウントを再割り当てしないでください。

シナリオ4：AEが退職した――アカウントのオーナーシップが不明確になる。 解決ルール：退職したAEのアカウントはCRMで「未割り当てAE」ステータスに移ります。CSMの関係は中断されません（CSMは「未割り当て」にはなりません）。地域のAEマネージャーまたは名前のあるカバレッジAEが、永続的なAEが割り当てられるまで更新と拡張の商業的責任を負います。これらのルールはすべて、先にキャパシティの計算を済ませていることを前提としています。多くのテリトリー再設計が飛ばしてしまうのが、その部分です。

テリトリー入力としてのキャパシティ比率

テリトリーデザインはCSMのキャパシティに制約されます。CSMのヘッドカウントが1対3の比率をサポートしている場合、1対1のAE-CSMペアリングを必要とするテリトリーモデルを設計することはできません。キャパシティの計算はテリトリーデザインに先行しなければなりません。

セグメント別の典型的なCSMとアカウントの比率：

これらはルールではなくベンチマークです。製品の複雑さ、オンボーディングの深さ、拡張モーションはすべてこれらの数値を変化させます。3か月のオンボーディングと複雑なインテグレーションを持つ製品は、ベンチマークが示すよりも低いアカウント負荷を必要とします。

引用可能な指標： 「テリトリー変更の自動化を、手動のSlack更新に任せず、CRMでRevOpsチームが所有している場合、アカウントカバレッジのギャップ時間は平均23日から5日未満に短縮されます（SalesLoftの運用ベンチマークデータより）。その18日間のギャップこそ、初年度のChurnリスクが積み上がる期間です。CSMとの接点も、オンボーディングサポートも、初期採用のマイルストーンもありません。」

Rework分析： テリトリーデザインで最もよくある間違いは、SalesとCSのカバレッジを、たまたま同じアカウントに触れる別々の計画作業として扱うことです。両者を単一の計画プロセスとして運用している企業は、更新をめぐる争いの大半を、始まる前に解消しています。そこでは、RevOpsが共有ブックの定義を所有し、両VPが同じキャパシティモデルに承認し、計画が稼働する前にテリトリーIDがCRMに組み込まれています。上のキャパシティ比率の表は、この計画プロセスの出力ではなく入力です。まずCSMのキャパシティの計算を行い、その比率が実際に支えられる範囲でテリトリーモデルを設計してください。

テリトリーを再設計する前にCSMを追加するとき vs. 再設計を先に行うとき： テリトリーモデルが根本的に健全でもCSMの比率がベンチマークの20%超で過負荷になっている場合、ヘッドカウントを追加します。CSMの比率が範囲内でもテリトリーデザインが対立を生み出している場合、デザインを修正します。デザインの問題を解決するためにヘッドカウントを追加しないでください――壊れたシステムにただ多くの人を追加するだけです。

RevOpsの役割：CRMへのテリトリーロジックの組み込み

テリトリーの決定はコンプ、レポーティング、自動化を動かすシステムに組み込まれている場合にのみ保持されます。スプレッドシートにのみ存在する適切に設計されたテリトリーモデルは、1四半期以内に回避されるでしょう。

テリトリー組み込みのためのCRMフィールドチェックリスト：

• Account Owner（AE）：プライマリフィールド、AEのコンプ計算を動かす
• CSM Owner：必須フィールド、契約署名から14日以内に入力されなければならない
• Territory ID：AEとCSMの両方が属する名前付きテリトリー（共有ブックレポーティングを可能にする）
• ARR Band：自動ティア分類、すべてのARR変更イベントで更新
• Last Territory Review Date：RevOpsが四半期ごとに追跡する監査フィールド
• Territory Change Log：タイムスタンプと理由コードを含むすべての再割り当ての不変の履歴

真実の源泉： CRMがアカウントオーナーシップの真実の源泉です――スプレッドシートでも、Slackのメッセージでも、非公式な合意でもありません。CRMにないテリトリー変更はコンプの目的では存在しません。顧客レコードのシングルソースオブトゥルースは、SalesとCSの両方が同じビューを見られるよう、そのCRMレコードをどう構造化するかを扱っています。

ティア再割り当ての自動化： アカウントのARRがティアの閾値を越えるとき（例：3万8,000ドルから4万2,000ドルへ、コマーシャルからミッドマーケットの境界を越える）、CRMは再割り当てワークフローをトリガーするべきです――即座にアカウントを再割り当てするのではなく、RevOpsと現在のCSMおよび次のセグメントのCSMリードに通知します。実行前の人間によるレビューは、デリケートな更新ウィンドウ中の自動再割り当てを防ぎます。

テリトリー変更の監査証跡： すべてのテリトリー変更はCRMに日付付きのレコードを作成するべきです：誰が変更し、いつ、なぜ。この監査証跡はコンプ争いの主要な証拠です。「拡張がクローズしたとき私がそのアカウントを所有していた」を証明するにはCRMの履歴が必要です――監査証跡なしに、これらの争いはより信頼できる説明を持つ人によって解決されます。

新しいテリトリーモデルのパイロット

すべてのセグメントで同時にテリトリーを再設計しないでください。1つのセグメントを選び、1四半期実行し、拡大する前に測定します。

パイロット設定：

• 1つのセグメントを選ぶ：ミッドマーケットは通常最も目に見える対立があり、最も明確な測定ベースラインがある
• パイロットグループの8～12のアカウントで新しいテリトリーモデルを実行；現在のモデルで8～12のアカウントのコントロールグループを維持
• 両グループを追跡し争いを解決する1人のRevOpsオーナーを指定する
• パイロット開始前に測定指標を定義する

測定すること：

• カバレッジギャップ頻度：アカウントに14日以上名前のあるAEまたはCSMが不在の頻度
• 争いの頻度：RevOpsのエスカレーションを必要とするコンプまたはオーナーシップの争いの数
• 更新サイクルの長さ：更新トリガーから署名まで何日か
• NRRのデルタ：パイロットグループは四半期末にコントロールグループよりNRRで上回るか

争いが少なく更新サイクルが短いテリトリーの再設計は、NRRが中立または良好であれば拡大する価値があります。争いを減らすが更新サイクルの長さを増やすものは、おそらく顧客体験を犠牲にして内部プロセスを最適化しています――拡大する前に診断する価値があります。

テリトリーデザインはインフラです

テリトリーデザインはアライメントの会話で当然の評価を受けていません。報酬の再設計より目に見えず、ポッドモデルの立ち上げよりも魅力的ではなく、現在進行中のChurnクライシスの解決よりも緊急性がありません。しかしそれは他のすべてのアライメントメカニズムを機能させる――または失敗させる――インフラです。

NRRでAEとCSMをアライメントするコンプ計画は、共有ブックが定義されていなければ価値がありません。ポッドモデルはポッドのテリトリーが他の3人のAEのグリーンフィールドの見込み客と重複している場合に摩擦があります。更新オーナーシップフレームワークは、更新が発動したときにCRMが誰がアカウントを所有しているかを教えてくれない場合に崩壊します。

テリトリーデザインを正しくすれば――4つのモデル、共有ブックの構築、CRMへの組み込み、争いの解決ルール――その上に構築されたアライメントイニシアチブは持続します。間違えると、すべての下流の取り組みが壊れた基盤と戦います。

関連記事

• Pod Model: AE + CSM Pairs
• Compensation Aligned on NRR
• Renewal Ownership: AE vs AM vs CSM
• Stakeholder Alignment in Deal Closing
• Sales-CS Alignment Glossary