「マーケティングと営業の連携がうまくいかない」「営業担当者が新規開拓と既存顧客対応の両方を抱えて疲弊している」「SaaSビジネスを成長させるための組織設計がわからない」――BtoBビジネスに取り組む経営者・マーケター・営業担当者がこうした課題を抱えることは多くあります。ザ・モデルとは、BtoBビジネスにおける収益創出プロセスをマーケティング・インサイドセールス・フィールドセールス・カスタマーサクセスの4つの部門に分業し、各部門が連携してLTVを最大化する組織モデルです。本記事では、ザ・モデルの定義・背景・4部門の役割・各部門のKPI・実践上の注意点・よくある失敗と対策まで徹底解説します。

ザ・モデルとは何か ― 定義と背景

ザ・モデルとは、Salesforceが自社のSaaS事業の急成長を支えた営業組織モデルを体系化したものです。日本では福田康隆氏の著書「THE MODEL」(翔泳社)によって広く知られるようになり、SaaS企業を中心に多くのBtoBビジネスで採用されています。

ザ・モデルが生まれた背景には、従来の「一人の営業担当者がリード獲得から受注・顧客対応まですべてを担う」という属人的なモデルの限界があります。このモデルでは営業担当者の能力・経験に依存するため、スケールが難しく・パフォーマンスのばらつきが大きくなりがちです。ザ・モデルは収益創出プロセスを4つの専門部門に分業することで、各部門が自分の役割に集中・最適化でき・組織全体としてスケーラブルな成長を実現する設計思想です。

ザ・モデルの全体像

ザ・モデルは以下の4部門が連携して収益を創出するモデルです。リードが各部門を経由しながら、最終的に顧客となりLTVを最大化する流れを設計します。

部門役割主なKPIバトンを渡す先
マーケティングリード獲得・需要創出リード数・MQL数・CPLインサイドセールス
インサイドセールス(SDR/BDR)リードの育成・商談化・アポ獲得商談数・SQL数・アポ率フィールドセールス
フィールドセールス(AE)商談・提案・クロージング受注数・受注率・ARRカスタマーサクセス
カスタマーサクセス(CS)顧客維持・利用促進・アップセルチャーンレート・NRR・NPS(マーケティングへの紹介・口コミ)

各部門がバトンを渡す「ハンドオフ」の設計と、部門間で共有するデータの仕組みがザ・モデルの成否を左右します

マーケティング部門の役割

マーケティング部門の役割は、自社の製品・サービスに関心を持つ見込み顧客(リード)を獲得し、インサイドセールスに渡すことです。

  • 需要創出(デマンドジェネレーション):SEO・コンテンツマーケティング・Web広告・ウェビナー・ホワイトペーパーなどを活用してリードを獲得する
  • MQLの定義と管理:MQL(Marketing Qualified Lead)とは、マーケティング部門が「営業が対応する価値がある」と判断したリードのこと。MQLの定義をインサイドセールスと合意しておくことが重要
  • ブランド認知・コンテンツ資産の構築:中長期的なブランド認知とコンテンツ資産の積み上げで、継続的なリード流入の基盤を作る

マーケティング部門は「リード数」だけでなく「MQLの質」で評価されることが重要です。質の低いリードを大量に送っても、インサイドセールスの工数を無駄にするだけになります

インサイドセールスの役割

インサイドセールスとは、対面・訪問を行わず電話・メール・オンラインミーティングで見込み顧客にアプローチする内勤営業のことです。ザ・モデルではマーケティングから渡されたリードを育成・商談化し、フィールドセールスにバトンを渡す役割を担います。

インサイドセールスはアプローチの方向性によって2種類に分類されます。

種類正式名称役割
SDRSales Development Representativeマーケティングが獲得したインバウンドリード(問い合わせ・資料請求)を受け取り、ヒアリング・育成を行い商談化する。反響型インサイドセールス
BDRBusiness Development Representative自社でターゲットアカウントを選定し、アウトバウンドでアプローチして新規商談を創出する。新規開拓型インサイドセールス

インサイドセールスの主な業務は以下の通りです。

  • リードへの初期対応・ヒアリング:リードの課題・ニーズ・予算・検討時期・決裁者を確認する(BANT条件の確認)
  • リードナーチャリング:まだ購買意欲が高くないリードに対して、メール・コンテンツ提供・定期的な連絡で関係を維持・育成する
  • SQLの創出:SQL(Sales Qualified Lead)とは、フィールドセールスが対応する価値があると判断されたリードのこと。SQLをフィールドセールスに渡す

フィールドセールスの役割

フィールドセールス(AE:Account Executive)は、インサイドセールスから渡されたSQLに対して商談・提案・クロージングを担当します。対面・オンラインでの商談を通じて顧客の課題を深く理解し、最適なソリューションを提案して受注につなげます。

  • 商談・ニーズヒアリング:顧客の課題・目標・意思決定プロセスを詳細に把握する
  • 提案・デモンストレーション:顧客の課題に合わせたカスタマイズされた提案・製品デモを行う
  • クロージング・契約:価格交渉・条件調整を経て受注に導く
  • カスタマーサクセスへのハンドオフ:受注後、顧客の情報・期待値・合意内容をカスタマーサクセスに正確に引き継ぐ

フィールドセールスは「受注」をゴールにするのではなく、「顧客が成果を出せる受注」を目指すことが重要です。無理なクロージングは解約率の上昇につながりLTV全体を損ないます

カスタマーサクセスの役割

カスタマーサクセス(CS)は、受注後の顧客が製品・サービスで成果を出し続けられるよう支援し、解約を防ぎ・アップセル・クロスセル・口コミを創出する部門です。SaaS・サブスクリプションビジネスでは、カスタマーサクセスの質がLTV・NRR(ネットレベニューリテンション)を左右する最重要部門です。

  • オンボーディング:契約後に顧客が製品の価値を迅速に実感できるよう導入支援を行う。オンボーディングの質が初期解約率に大きく影響する
  • 継続的な活用支援:定期的なミーティング・利用状況のモニタリング・活用ノウハウの提供で顧客の利用を深める
  • 解約予兆の検知と対応:ログイン頻度の低下・サポート問い合わせの増加などの解約予兆を早期に検知し、先手でフォローする
  • アップセル・クロスセル:顧客の成長に合わせて上位プランへのアップグレード・関連製品の追加を提案する
  • 顧客の声の収集・フィードバック:NPSやCSATで顧客満足度を計測し、製品改善・マーケティングへのフィードバックを行う

部門間のハンドオフ設計

ザ・モデルを機能させるためには、各部門間のハンドオフ(引き継ぎ)の設計が重要です。

  • MQLの定義の合意:マーケティングとインサイドセールスが「MQLとはどんなリードか」を事前に合意する。定義が曖昧だと「質が低い」「渡すのが遅い」という摩擦が生まれる
  • SQLの定義の合意:インサイドセールスとフィールドセールスが「SQLとはどんな状態か」を合意する(BANT条件など)
  • 受注後のハンドオフ情報の標準化:フィールドセールスからカスタマーサクセスへの引き継ぎ情報(顧客の課題・合意内容・期待値)をCRMで標準化する

各部門のKPIと評価指標

部門主なKPI
マーケティングリード数・MQL数・CPL(リード獲得単価)・マーケティング起因パイプライン
インサイドセールスSQL数・商談化率・アポ獲得数・リードレスポンスタイム
フィールドセールス受注数・受注率・ARR(年間経常収益)・平均受注単価・営業サイクル期間
カスタマーサクセスチャーンレート・NRR(ネットレベニューリテンション)・NPS・CSATアップセル金額

よくある失敗と対策

失敗① MQL・SQLの定義が曖昧で部門間に摩擦が生じる

マーケティングが渡したリードを営業が「質が低い」と判断してフォローしない、または営業が「まだ早い」リードを無理にクロージングしようとするケースです。MQL・SQLの定義と引き継ぎ基準をマーケティング・インサイドセールス・フィールドセールスの三部門で合意し、CRMで管理することが摩擦解消の鍵です。

失敗② カスタマーサクセスを「サポート」と混同する

カスタマーサクセスを単なるサポート・問い合わせ対応部門として位置づけ、顧客の成果創出・アップセルという本来の役割を担わせていないケースです。カスタマーサクセスはコストセンターではなく、LTV最大化のための収益創出部門として設計することが重要です。

失敗③ 小規模組織でザ・モデルをそのまま導入しようとする

社員数が少ない段階でザ・モデルの4部門を完全に分業しようとして、各部門の人数が少なすぎて機能しないケースです。初期段階では1〜2名が複数の役割を兼任しながら徐々に分業を進め、組織の成長に合わせてザ・モデルの各部門を整備していくアプローチが現実的です。

まとめ

本記事では、ザ・モデルの定義・背景・マーケティング・インサイドセールス(SDR/BDR)・フィールドセールス・カスタマーサクセスの4部門の役割・KPI・ハンドオフ設計・よくある失敗と対策まで解説しました。

ザ・モデルはBtoBビジネスの収益創出プロセスを4部門に分業し・各部門が専門性を発揮しながら連携することで、スケーラブルな成長を実現する組織設計のフレームワークです。MQL・SQLの定義の合意・部門間のハンドオフの設計・CRMを活用したデータの統合から始めてみてください