%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
The Modelは役割分担を明確にする一方、部門間の情報分断を招くことがあります。次世代営業組織の核心は、分業を残しながらデータと顧客体験をつなぎ直すことです。
The Modelは役割分担を明確にする一方、部門間の情報分断を招くことがあります。次世代営業組織の核心は、分業を残しながらデータと顧客体験をつなぎ直すことです。
「マーケティングが渡したリードの背景を営業が把握できていない」「受注までの経緯がカスタマーサクセスに伝わらない」「各部門は目標を達成しているのに、収益全体が伸びない」——こうした現場の声は、The Modelの運用が部分最適に陥っている兆候です。
The Modelとは、BtoB営業のプロセスを機能別に分け、各部門がKPIを持ちながら顧客を引き渡す営業組織モデルです。限界を乗り越えるには分業をやめるのではなく、顧客情報、判断基準、収益指標を部門横断で共有する仕組みへ再設計する必要があります。
福田康隆氏が提唱したThe Modelは、日本のBtoB営業に科学的な分業体制という考え方を広げました。マーケティング、インサイドセールス、フィールドセールス、カスタマーサクセスの役割を明確にし、属人的な営業活動をプロセスとして管理できる点は、現在も有効です。
一方、役割を分けることと情報を分けることは同じではありません。顧客の検討背景や過去の接点が部門ごとのスプレッドシート、個人のメモ、会議資料に散らばれば、引き渡しのたびに情報が薄くなります。次世代営業組織では、組織図を変える前に、分断されたデータと業務フローをつなぎ直すことがポイントになってきます。
この記事でわかること
The Modelの課題や次世代営業組織の設計に関心があるBtoB営業責任者・経営者に向けた記事です。分業型モデルの良さを残しながら、サイロ化を抑える考え方を整理します。
- The Modelの限界が生まれる理由 — 情報分断、顧客体験の断絶、部門別KPIによる部分最適がどのように起きるかを解説します
- 次世代営業組織の選択肢 — RevOps、Pod型、AIハイブリッドの違いと、それぞれが解決しやすい課題を整理します
- CRMを営業組織の基盤にする方法 — 一元管理、自動化、可視化を通じて、部門間の引き渡しを仕組み化する考え方を紹介します
- 移行を段階的に進める手順 — データ定義、会議体、業務プロセス、組織構造の順に見直す進め方を解説します
本記事を通じて、CRMを営業の武器に変えるための実践的なアプローチが見えてきます。「ツールを入れたけど活用できていない」と感じている方にこそ、読んでいただきたい内容です。
The Modelとは何か｜機能分業がもたらした価値
The Modelを見直す前に、何を残すべきかを整理しておきます。課題が出ているからといって、機能分業やKPI管理そのものを否定する必要はありません。
役割の明確さを保ちながら、顧客情報と収益プロセスを再接続することが重要です。
マーケティングからカスタマーサクセスまでの役割分担
The Modelでは、顧客との接点を機能別に分け、それぞれの担当が専門性を発揮します。
前工程が次工程へ顧客を引き渡すため、営業活動を個人の経験だけに依存せず、組織のプロセスとして扱いやすくなります。
| 機能 | 主な役割 | 管理する指標の例 |
|---|---|---|
| マーケティング | リードの獲得と育成 | リード数、MQL数 |
| インサイドセールス | リードの精査と商談機会の創出 | 商談化数、商談化率 |
| フィールドセールス | 商談の推進と受注 | 受注数、受注金額 |
| カスタマーサクセス | 契約継続、アップセル、解約防止 | 解約率、NRR |
この役割分担は、誰が何を担うのかを明確にするうえで有効です。ただし、各機能が別々のデータを見て判断する状態になると、専門性の分担が情報の分断へ変わります。
属人的な営業からプロセス管理へ移行できる
The Modelが広がった背景には、属人的な営業から脱却し、経営層が営業活動を定量的に把握したいという需要がありました。
福田氏の著書も、分業とKPI管理の考え方が日本のBtoB企業へ浸透するきっかけになりました。
- 従来の営業 ── 従来の営業では、案件の進め方や顧客情報が担当者の頭の中に残りやすく、引き継ぎや育成が難しくなります。
- 共通化の効果 ── 役割、プロセス、判断基準を共通化すれば、新人でも次に確認すべき情報を理解しやすくなり、担当者が変わっても業務を引き継げる仕組みに近づきます。
ただし、KPIを設定しただけでは全体最適にはなりません。各部門の数値が、受注、継続、顧客体験とどのようにつながるかまで設計する必要があります。
The Modelの限界はなぜ生まれるのか
The Modelの限界は、機能分業そのものよりも、引き渡しの設計不足から生まれます。
部門ごとにツール、指標、会議、データ定義が分かれると、同じ顧客を見ていても判断の前提がそろいません。ここでは、現場で起きやすい問題を分解します。
情報が部門間の引き渡しで圧縮される
- リードの引き渡し ── マーケティングが把握していたWebサイトの閲覧履歴やダウンロードしたコンテンツが、インサイドセールスには「資料をダウンロードしたリード」とだけ伝わることがあります。
- 受注後の引き渡し ── さらに商談が進み、フィールドセールスからカスタマーサクセスへ渡る段階では、検討理由や合意の背景が抜け落ち、受注結果だけが共有されるケースもあります。
引き渡しのたびに要約だけを作り直す運用では、担当者の解釈によって情報量が変わります。重要な顧客接点をCRMへ蓄積し、次の部門が元の履歴を確認できるようにすることが必要です。
- 顧客レコードとの結び付き ── また、チャットやメールで補足しても、その情報が顧客レコードと結び付いていなければ、後から検索しにくくなります。
- 業務ルール ── 情報共有を担当者の丁寧さに任せず、どの情報をどこへ残すかを業務ルールとして設計することがポイントです。
顧客体験が担当変更のたびに途切れる
社内では適切に分業できていても、顧客から見れば同じ会社との継続的な対話です。担当部門が変わるたびに同じ背景を説明したり、前の担当者と合意した内容が共有されていなかったりすると、顧客体験は断絶します。
- 複雑な商材 ── 特に商材が複雑で、複数の関係者が意思決定へ関わる場合は、単純な連絡先の引き渡しだけでは不十分です。
- 一続きの情報 ── 関心事項、検討上の懸念、商談中の合意、導入後に期待する成果を一続きの情報として扱う必要があります。
顧客中心の営業組織とは、担当者を固定することではありません。担当者が変わっても、これまでの文脈を引き継いだ対話ができる状態を仕組みで作ることです。
部門別KPIが部分最適を招く
各部門が自部門のKPIだけを追うと、全体の収益や顧客体験とずれることがあります。
マーケティングがMQL数を増やしても、営業が求める条件と合わなければ商談につながりません。インサイドセールスが商談化率を重視しすぎれば、将来の機会を見送る可能性があります。
| 部門で起きる最適化 | 全体で生じる問題 | 見直す観点 |
|---|---|---|
| リード数を優先する | 営業が対応しにくいリードが増える | MQLとSQLの定義をそろえる |
| 商談化率を優先する | 育成すべきリードを見送る | 見送り後のナーチャリングを設計する |
| 受注をゴールにする | 導入背景がCSへ伝わらない | 受注時の引き渡し項目を決める |
| 継続率だけを見る | 新規獲得時の期待とのずれが見えない | 獲得から継続までを横断して振り返る |
部門別KPIをなくすのではなく、その上に収益全体を確認する共通指標と会議体を置くことが必要です。部分の成果と全体の成果を同じデータから確認できる状態が、サイロ化を抑える土台になります。
The Modelの限界が顕在化しているかを判断する
組織構造を変える前に、自社で何が分断されているのかを確認します。名称だけをRevOpsやPod型へ変えても、データと会議の運用が変わらなければ問題は残ります。
現状診断では、ツールの数よりも、同じ顧客情報を部門横断で追えるかを見ます。
スプレッドシートの手作業を棚卸しする
顧客一覧、商談管理表、受注後の引き継ぎ表が別々に存在すると、担当者は同じ情報を何度も転記することになります。
更新のタイミングがずれれば、どのファイルが正しいのか判断しにくくなり、会議のたびに数値や案件状況を確認し直す作業も発生します。
- 洗い出し ── まず、各部門が日常的に更新しているスプレッドシートを洗い出します。
- つなげて見る ── そのうえで、顧客名、担当者、案件ステータス、次のアクション、受注後の引き継ぎ事項がどこに保存されているかをつなげて見ます。
- 引き渡し地点 ── 転記や照合作業が多い箇所は、情報ロスが起きやすい引き渡し地点です。
ただし、表計算ソフトを使っていること自体が問題なのではありません。
検討初期の整理や一時的な集計には使いやすい一方、複数部門が同じ顧客を継続的に更新する基盤としては、差分管理や関連付けが複雑になりやすい点に注意が必要です。
サイロ化の兆候を業務フローで確認する
次のような状態が複数見られる場合は、The Modelの限界が顕在化している可能性があります。
| 確認する場面 | サイロ化の兆候 | 確認したい状態 |
|---|---|---|
| リードの引き渡し | 営業が検討背景を再度聞いている | マーケティング接点を営業が確認できる |
| 商談の進行 | 部門ごとに案件ステータスが異なる | 共通のステージ定義で管理している |
| 受注後の移管 | CSが導入目的や合意内容を把握できない | 商談経緯が顧客情報と関連付いている |
| 失注後の対応 | 失注案件がそのまま放置される | 理由に応じて育成へ戻せる |
| 経営会議 | 部門ごとに異なる集計を持ち寄る | 共通データから収益全体を確認できる |
顧客からのたらい回しに関する指摘、部門間での責任の押し付け、会議ごとの集計や照合が増えている場合も見直しの合図です。
個人の連携意識だけを改善しようとせず、情報が流れる経路と入力ルールを確認してください。
次世代営業組織の進化モデルを比較する
The Modelを拡張する方向には、RevOps、Pod型、AIハイブリッドがあります。どれかだけを選ぶ必要はなく、課題に応じて考え方を組み合わせることもできます。
重要なのは、流行している名称ではなく、どの分断を解消したいのかから選ぶことです。
RevOpsは収益プロセスを横断して管理する
RevOpsは、マーケティング、セールス、カスタマーサクセスのオペレーションを横断し、データ基盤、プロセス、テクノロジー、KPIを統合して管理する考え方です。
各部門の専門性を残しながら、共通ルールを設計できる点に特徴があります。
- 検討しやすい場面 ── The Modelの役割分担を大きく変えずに、サイロ化を見直したい場合に検討しやすいモデルです。
- そろえるもの ── MQLやSQLの定義、商談ステージ、受注後の引き継ぎ項目、レポートの集計元をそろえることで、部門間の認識差を小さくできます。
ただし、RevOpsという担当名を置くだけでは機能しません。
データ定義を決める権限と、現場の運用を調整する責任の範囲が曖昧なままでは、各部門から集計を依頼されるだけの役割になりやすいためです。
Pod型は顧客単位で協働する
Pod型は、特定の顧客セグメントに対して、マーケティング、インサイドセールス、フィールドセールス、カスタマーサクセスが小規模な横断チームを組むモデルです。
部門間で顧客を渡すだけでなく、同じ顧客群を継続して見るため、検討背景や反応を共有しやすくなります。
- 向いている商材 ── 顧客の意思決定が複雑で、営業だけでは解決しにくい商材では、複数機能が早い段階から協働できる点が有効です。
- 一気通貫 ── 顧客への提案、受注後の支援、追加提案を一気通貫で考えられます。
ただし、Podごとに運用が閉じると、今度はPod間でナレッジが分断されます。
共通のCRM、ステージ定義、レビュー項目を持ち、他のPodでも再利用できる形で知見を残す必要があります。
AIハイブリッドは定型業務と人の判断を分ける
AIハイブリッドは、リードスコアリング、議事録の整理、商談情報の要約、データの分類などをAIが支援し、人は関係構築や複雑な意思決定に集中するモデルです。
HubSpotのBreezeも、CRMに蓄積された情報を扱う支援役として位置付けると、活用範囲を考えやすくなります。
- AIに任せやすいこと ── AIに任せやすいのは、決められた基準に沿う整理や下書きです。
- 人が担うこと ── 一方、パイプライン設計、顧客ごとの優先順位、大型案件への対応、送信前の判断は人が担う必要があります。
- 確認の工程 ── AIが作った内容をそのまま外部へ送る運用ではなく、人が確認して改善する工程を組み込みます。
ただし、CRMのデータが不足していたり、入力ルールが部門ごとに異なったりする状態では、AIが参照する前提もそろいません。
AI活用を先行させるのではなく、データ品質と業務ルールの整備を同時に進めることが重要です。
| 進化モデル | 主に解決する課題 ／ 活かすべきThe Modelの要素 | 注意点 |
|---|---|---|
| RevOps | 主に解決する課題 データ定義とKPIの分断 活かすべき要素 部門ごとの専門性 |
権限と責任範囲を明確にする |
| Pod型 | 主に解決する課題 顧客体験と連携の断絶 活かすべき要素 各機能の専門性 |
Pod間のナレッジ共有を設計する |
| AIハイブリッド | 主に解決する課題 定型作業と情報整理の負荷 活かすべき要素 標準化されたプロセス |
人による確認とデータ品質が必要 |
CRMで分業を一元管理・自動化・可視化する
どの進化モデルを選ぶ場合も、共通の土台になるのがCRMです。
CRMは顧客情報を保存するだけのデータベースではなく、営業プロセスを標準化し、部門間の連携と経営判断を支える事業成長のエンジンとして設計します。
入力項目を増やす前に、誰が何の判断に使うデータかを明確にします。
顧客と取引の情報を一つの流れとして扱う
スプレッドシートで部門ごとに表を作ると、リード、商談、顧客、請求へ進む過程で情報が複製されます。
CRMでは、コンタクトと取引を関連付け、受注後の顧客対応や請求へ渡す情報まで、同じ業務フローの中で整理します。
- 先に決めること ── HubSpotを使う場合も、機能を個別に導入するのではなく、コンタクトから取引、顧客、請求へ進む全体フローのどこで何を記録し、次の担当へ何を渡すかを先に決めることが重要です。
- つながった状態 ── マーケティングの接点、営業の商談履歴、カスタマーサクセスの対応情報がつながれば、担当者は前工程の文脈を確認できます。
以下の画面は、取引をステージごとの列に分け、取引カードにクローズ日や担当者などを表示したボード画面です。
ボード表示は案件状況を把握する入口になりますが、見た目だけを整えても運用は改善しません。
各ステージの意味、移動条件、確認すべき項目をそろえることで、部門をまたいでも同じ基準で案件を見られるようになります。
自動化で引き渡し漏れを仕組みとして防ぐ
担当者へ「忘れずに入力してください」と伝えるだけでは、案件が増えたときに漏れが起きます。
ステージ移行時に必要な項目を設定し、条件に応じた通知や担当者へのタスク作成を自動化すれば、引き渡しを個人の記憶に頼らずに運用できます。
- 商談化・受注 ── 例えば、商談化したときに営業へ通知し、受注時にはカスタマーサクセスが必要とする導入目的や合意内容を確認する流れを作ります。
- 失注 ── 失注した場合は、失注理由を記録し、ナーチャリングへ戻す対象を判断できる状態にします。
ただし、自動化する前に業務ルールがそろっていないと、誤った通知や更新が広がります。まず手動で運用を確認し、判断基準が固まった範囲から自動化を広げる進め方をおすすめします。
可視化は経営判断と現場改善をつなぐ
CRMに情報が集まれば、部門別の活動だけでなく、リードから商談、受注、継続までの流れを同じデータから確認できます。
マーケティングが獲得したリードのうち、どの条件が商談や受注につながったかを振り返り、次の施策へ反映できます。
- 目的 ── 可視化の目的は、現場を監視することではありません。
- 見つけるもの ── 停滞している工程、情報が欠けている引き渡し、失注が増えている理由を見つけ、業務プロセスを改善することです。
- ダッシュボード ── ダッシュボードの項目も、経営会議で使う指標と現場が次の行動を決める指標を分けて設計します。
ただし、入力されていない情報はレポートにも反映されません。使っていない項目を増やすのではなく、判断に必要な項目へ絞り、入力の目的を現場へ共有することが定着の前提です。
パイプラインを共通言語として再設計する
部門横断で営業プロセスを運用するには、パイプラインを単なる案件一覧ではなく、共通の判断基準として設計します。ステージ名だけでは、担当者ごとに解釈がずれるためです。
ステージ、角度、定義、必須入力プロパティを組み合わせることが、データの信頼性を高めるポイントです。
ステージと角度を営業プロセスに合わせる
取引ステージは、顧客との関係や受注の見込みが変わる地点で分けます。
社内作業の進捗だけで区切るのではなく、顧客側で何が確認できたかを基準にすると、案件の状態を共通理解にしやすくなります。
- 角度とは ── 角度は、各ステージの受注見込みをフォーキャストへ反映するための考え方です。
- 感覚だけの評価 ── 担当者の感覚だけで案件を評価すると、同じ状態でも見込みが異なります。
- 設計の基準 ── 過去の受注状況と現場の知見を踏まえ、自社の営業プロセスに合う基準を設計します。
ただし、標準的なステージ名をそのまま採用しても、自社の意思決定プロセスと合わない場合があります。商材、顧客の検討方法、契約までの流れを整理してから設定してください。
定義と必須入力プロパティで属人化を抑える
ステージ定義では、その段階へ移動できる条件を文章で明確にします。「提案中」のような幅の広い表現だけでなく、顧客と何を合意した状態か、次に何を確認する必要があるかを共有します。
- 必須入力プロパティ ── 必須入力プロパティは、ステージ移行時に確認すべき情報を抜けにくくする仕組みです。
- 理由の記録 ── 受注時に受注理由を記録し、失注時に失注理由を残せば、後から傾向を分析できます。
- 新人のガイド ── 新人にとっても、案件を進めるために何を確認するかを学ぶガイドになります。
| 設計要素 | 決める内容 | 組織で得られる効果 |
|---|---|---|
| 取引ステージ | 顧客の状態が変わる区切り | 案件状況を共通化できる |
| 角度 | ステージごとの見込みの考え方 | フォーキャストの基準をそろえられる |
| ステージ定義 | 移動条件と確認事項 | 担当者ごとの解釈を抑えられる |
| 必須入力プロパティ | 次工程で必要な情報 | 引き渡し漏れを仕組みで防げる |
入力項目は多いほど良いわけではありません。営業活動と経営判断に使う項目へ絞り、使われていない項目が増えないように管理します。
パイプラインの限界と運用上の注意点
パイプラインは商談管理に有効ですが、顧客との関係全体を取引レコードだけで表現しようとすると情報が偏ります。
同じ会社に複数の担当者や商談がある場合は、会社、コンタクト、取引の関係を踏まえて見る必要があります。
- 受注後の編集 ── また、受注後に金額や日付が自由に変わると、過去のレポートと現在の集計が合わなくなることがあります。
- 編集権限 ── 誰が、どの段階で、どの項目を編集できるかを決め、必要に応じて承認や編集制限を検討します。
ただし、制限を増やしすぎると現場が更新を避ける原因になります。データの信頼性を守る範囲と、現場が変更できる範囲のバランスを取り、自社の運用に合わせて調整してください。
The Modelから次世代営業組織へ移行する
移行は組織図の変更から始めるのではなく、現状の情報ロスを可視化し、共通データを整えるところから進めます。先に名称や所属だけを変えると、運営方法は以前のまま残りやすくなります。
データ、会議体、業務プロセス、組織構造の順に検討することをおすすめします。
共通データ定義と会議体を先にそろえる
最初に、MQL、SQL、商談、受注、更新、解約など、部門をまたいで使う言葉の定義を確認します。同じ言葉を使っていても、部門ごとに判定条件が異なることがあるためです。
- 会議体を作る ── 次に、部門横断で案件と顧客体験を振り返る会議体を作ります。
- 会議の進め方 ── 会議では各部門の活動報告を並べるのではなく、リードから受注、受注後までの流れを一つのデータで確認します。
- 停滞・失注 ── 停滞や失注の原因を部門単独の責任にせず、前後工程を含めて改善します。
| 優先して見直すもの | 主な内容 | 後に続く変更 |
|---|---|---|
| 共通データ定義 | MQL、SQL、受注、更新、解約の定義 | レポートと自動化 |
| 共通KPI | 部門KPIと収益全体の関係 | 経営判断と評価 |
| レビュー会議 | 案件と顧客体験の横断的な振り返り | 改善サイクル |
| 組織構造 | RevOps、Pod型、AIハイブリッド | 役割と権限の再配置 |
小さな範囲で試し、運用を確認する
すべての部門と顧客へ同時に新しい運用を広げると、問題の原因を特定しにくくなります。
特定の顧客セグメントやチームで共通ステージ、引き渡し項目、レビュー会議を試し、現場が使えるかを確認します。
- 試行で振り返ること ── 試行では、入力率だけでなく、情報の再確認が減ったか、次の担当者が顧客の背景を理解できたか、会議で同じデータを見られたかを振り返ります。
- 見直し ── 運用上の負担が大きい項目は削り、判断に不足する情報は追加します。
この段階的な進め方なら、The Modelの良さである役割の明確さを維持しながら、サイロ化を生む部分を調整できます。
スモールスタートは導入規模を小さくするだけでなく、学びを次の設計へ反映するための方法です。
自動化と組織変更は運用が固まってから広げる
- 手動での確認 ── 手動で回らない業務を先に自動化しても、問題が見えにくくなるだけです。
- 自動化の追加 ── 共通定義と引き渡し方法が現場で機能した後に、通知、タスク作成、ステータス更新、レポート配信などの自動化を追加します。
組織変更も同様です。
- RevOps ── RevOpsの役割を置く場合は、どのデータとプロセスに責任を持つのかを明確にします。
- Pod型 ── Pod型を採用する場合は、Pod内の協働だけでなく、Podをまたいだ情報共有の方法も決めます。
ただし、移行途中は旧運用と新運用が混在しやすくなります。
正しいデータの保存先、移行対象、旧ファイルの参照ルールを示し、現場が迷わない状態を作ることが重要です。
受注後と失注後までを一気通貫で設計する
次世代営業組織では、受注を営業プロセスの終点として扱いません。受注後の顧客体験や失注後の関係も、次の収益機会につながる流れとして設計します。
マーケティングからカスタマーサクセスまでを同じCRMデータで振り返ることが重要です。
失注理由を記録し、ナーチャリングへ戻す
失注案件をそのまま閉じると、検討時期が合わなかった顧客や、条件が変われば再検討できる顧客との接点が途切れます。
失注理由を価格、競合他社、製品機能、時期、社内決裁などの観点で整理し、その後の対応を分けます。
- 流れを作る ── ナーチャリングへ戻す場合は、営業対象から外した後に、再び適切なライフサイクルステージへ設定する流れを作ります。
- 接点を持つ ── マーケティングが配信する情報と営業が把握した失注背景をつなげれば、同じ提案を繰り返すのではなく、顧客の状況に応じた接点を持てます。
ただし、すべての失注顧客へ同じ頻度で連絡する方法は適切ではありません。失注理由や顧客の意向を確認し、再接触の対象と方法を分ける必要があります。
受注時の情報をカスタマーサクセスへつなぐ
カスタマーサクセスが必要とするのは、契約内容だけではありません。顧客が何を課題としていたか、商談中にどの成果を期待していたか、どの点に懸念があったかという背景が、導入後の支援に影響します。
- 引き渡し ── 受注時の引き渡しでは、営業が自由形式の文章を毎回作るだけでなく、共通項目と補足情報を組み合わせます。
- 使い分け ── 共通項目はレポートや検索に使い、補足情報は顧客固有の文脈を伝えるために残します。
カスタマーサクセスで得た利用状況や顧客の声も、営業やマーケティングへ戻します。失注理由と顧客の声を部門横断で見れば、提案方法や製品に求められる内容を見直しやすくなります。
AIは情報整理を支援し、人が判断する
- 要約と下書き ── BreezeなどのAIは、CRMに蓄積された商談情報の要約や、次の対応を考えるための下書きを支援できます。
- 履歴の把握 ── 部門をまたいだ履歴を短時間で把握する用途では、引き渡しの負担を軽くする助けになります。
- 人が判断すること ── 一方、顧客へ何を伝えるか、どの案件を優先するか、営業プロセスをどう変えるかは、人が事業と顧客を理解したうえで判断します。
- 重要な案件 ── 特に重要な案件では、AIの出力を参考情報として扱い、元の履歴を確認して内容を調整します。
ただし、AIは不足している情報を補う仕組みではありません。入力されていない商談経緯や、定義が曖昧なステータスを前提にすると、出力も不安定になります。
まずCRMのデータと運用ルールを整え、そのうえで支援範囲を広げる順序が適切です。
よくある質問
The Modelの見直しでは、組織変更の規模や導入順序に迷いやすくなります。ここでは、次世代営業組織へ移行するときに生じやすい疑問を整理します。
The Modelはもう古いのでしょうか？
The Modelの基本思想である分業とKPI管理は、現在も営業活動を標準化する土台になります。問題は、役割分担と同時にデータや判断基準まで分かれてしまうことです。The Modelを捨てるのではなく、部門横断のデータ基盤、共通指標、顧客起点の運用を加えて拡張する考え方が適しています。
RevOpsを始めるには専任チームが必要ですか？
開始時点から専任チームを設けることだけが選択肢ではありません。まずCRM管理、データ分析、プロセス設計を横断して見る役割と責任範囲を決め、共通データ定義や会議体を整えます。運用上の課題と必要な業務量が見えてから、体制の拡張を判断できます。
Pod型と従来の営業チームは何が違いますか？
従来のThe Modelでは、機能ごとに顧客を引き渡します。Pod型では特定の顧客セグメントに対して複数機能が継続的に協働するため、顧客の背景を共有しやすくなります。ただし、Pod内だけで情報が閉じないように、共通のCRMとナレッジ共有が必要です。
AIハイブリッド組織はすぐに導入できますか？
商談情報の要約、議事録の整理、データ分類など、限定した支援から始めることはできます。一方、データが不足している状態や、部門ごとに定義が異なる状態では、AIの出力を業務判断へ使いにくくなります。CRMのデータ整備と人による確認ルールを先に決めてください。
移行中に現場が混乱しないようにするにはどうすればよいですか？
対象となる顧客セグメントやチームを絞り、共通定義と引き渡し方法を試すことから始めます。旧運用と新運用の保存先を明確にし、会議で不便な点を確認しながら項目やルールを調整します。運用が固まった後に自動化や組織変更へ広げると、変更点を理解しやすくなります。
まとめ
The Modelの限界は、分業という考え方ではなく、顧客情報、判断基準、KPIが部門ごとに分断されることで生まれます。次世代営業組織では、役割の明確さを残しながら、顧客の検討から受注後までを一気通貫で見られる仕組みへ再設計します。
押さえておきたい要点は次の通りです。
- RevOpsはデータとプロセスの横断管理、Pod型は顧客単位の協働、AIハイブリッドは定型業務と人の判断の役割分担に向いています
- CRMはデータの保管場所ではなく、一元管理、自動化、可視化を通じて営業プロセスを標準化する基盤として設計します
- パイプラインでは、ステージ、角度、定義、必須入力プロパティをそろえ、引き渡しを個人の力量に依存させないことが重要です
- 受注後の顧客体験と失注後のナーチャリングまでを同じ流れで管理すると、部門間の学びを次の活動へ戻せます
- 自動化や組織変更は、共通データ定義と手動運用を確認した後に段階的に広げます
まずは、部門間の引き渡しで失われている情報を棚卸しすることから始めてください。読者自身で進められる次の行動は以下の通りです。
- 各部門が使うスプレッドシート、CRM項目を並べ、重複と転記箇所を見つけます
- MQL、SQL、商談、受注、失注、更新の定義と、次工程へ渡す情報を整理します
- 対象を絞って共通ステージとレビュー会議を試し、運用後に自動化や組織変更を検討します
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
The Modelの再設計とあわせて、営業プロセスやCRM活用に関する記事もご覧ください。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
