%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}
この記事の結論
MA・CRM・SFAは守備範囲の違う3つの仕組みです。成果を分けるのは、MQLからSQLへの引き渡しを誰が・いつ・どの基準で行うかという連携設計。
MA・CRM・SFAは守備範囲の違う3つの仕組みです。成果を分けるのは、MQLからSQLへの引き渡しを誰が・いつ・どの基準で行うかという連携設計。
「マーケがせっかくリードを集めても、営業がフォローしてくれない」「どのリードが"今すぐ客"なのか、マーケと営業で認識がずれている」「MAで育成したリードをSFAに渡した途端、その後がブラックボックスになる」——。
MA・CRM・SFAの違いとは、MAが見込み顧客の獲得と育成を、SFAが商談と営業活動の管理を、CRMが顧客情報を部門横断で一元管理する基盤を担うという、守備範囲の違いです。3つを別々に運用すると、リードが部門をまたぐ瞬間に情報と責任が途切れます。
マーケティング部門と営業部門の間に生まれるこうした溝は、多くのBtoB企業が抱える構造的な課題です。その根本原因の一つが、3つのツールの役割分担と連携設計が曖昧なまま運用されていることにあります。
本記事は「MA（マーケティングオートメーション）導入の教科書｜失敗しないための設計と運用の全ステップ」シリーズの一部です。
この記事でわかること
マーケと営業の連携がうまくいかない、MAで育成したリードがSFAに渡った後に見えなくなる、と感じている方に向けて、次の4点を整理します。
- MA・CRM・SFAの役割の違いとカバー範囲 — 3つのツールが担うプロセス領域を「リードの旅」の視点で整理し、なぜ連携が要になるのかを構造的に解説します。
- MQL→SQL→商談のステージ定義と引き渡し基準 — どの状態のリードを、いつ、どう渡すかをマーケと営業で合意するためのSLA設計を紹介します。
- データが途切れない連携フローと運用ワークフロー — 同期する項目・方向・タイミングの決め方と、フォロー漏れを防ぐ自動化の組み立て方を示します。
- 引き渡しプロセスの定量評価と改善の回し方 — 商談化率やフォロー状況をKPIとして追い、定義やスコアリングを見直すサイクルを紹介します。
MA・CRM・SFAとは？3つのツールの基本的な違い
MA（マーケティングオートメーション）、CRM（顧客関係管理）、SFA（営業支援システム）は、いずれも顧客との関係を管理・強化するためのツールですが、守備範囲ははっきり分かれています。違いを理解しないまま導入を進めると、データの二重管理や部門間での責任の押し付け合いが起き、リード獲得から受注までのプロセスに断絶が生まれます。Excel管理からの脱却を目指してツールを導入したのに、結局「ツールごとのExcel」が増えただけ、という状況に陥っている企業も少なくありません。まずは3つの役割を分けて整理します。
MAの役割：見込み顧客の獲得と育成
MA（Marketing Automation）は、リードの獲得（リードジェネレーション）と育成（リードナーチャリング）を自動化するツールです。メール配信、ランディングページ作成、フォーム管理、リードスコアリングなどの機能を通じて、まだ購買意欲が顕在化していない見込み顧客を「営業がアプローチすべきタイミング」まで育てる役割を担います。
手作業でこれを行う場合、展示会の名刺リストやフォームの回答をスプレッドシートに転記し、メールを一斉送信し、反応を目視で追うことになります。リストが複数に分かれるほど差分が生まれ、誰にいつ何を送ったのかが追えなくなります。MAの価値は、この「育成の履歴」を個人単位で残し、次のアクションを自動で起こせる点にあります。
SFAの役割：商談管理と営業活動の効率化
SFA（Sales Force Automation）は、商談の進捗管理、営業活動の記録、売上予測などを通じて営業プロセスを効率化するツールです。案件のパイプライン管理、訪問・電話・メールなどの活動ログ、見積書作成などの機能を提供し、営業担当者の生産性向上と営業マネジメントの精度向上を支援します。
SFAは入力されて初めて機能します。「ちゃんと入力してね」と呼びかけるだけでは定着しにくいため、どの段階で何を入力すれば次に進めるのかをツール側のルールとして組み込んでおくことが、SFA運用の出発点になると考えています。
CRMの役割：顧客情報の一元管理と関係構築
CRM（Customer Relationship Management）は、顧客に関するあらゆる情報を一元管理し、企業と顧客の長期的な関係構築を支えるプラットフォームです。3つの違いを理解するうえで押さえておきたいのは、CRMは特定の業務プロセスを自動化するツールというよりも、顧客データの「基盤」としての役割が強いという点です。
コンタクト（担当者）、会社、取引（商談）といった情報が互いに紐づいていれば、ある会社の誰がどの資料を読み、どの商談に関わり、いつ受注したのかを一つの画面でたどれます。MAとSFAがそれぞれ別の顧客リストを持つのではなく、同じ顧客データを参照する状態をつくるのがCRMの役目です。
3ツールの機能比較表
| 比較項目 | MA | SFA | CRM |
|---|---|---|---|
| 主な利用部門 | マーケティング | 営業 | 全部門 |
| 対象フェーズ | 認知～MQL | SQL～受注 | 全フェーズ（特に既存顧客） |
| 主要機能 | メール配信、スコアリング、LP作成 | 商談管理、活動記録、売上予測 | 顧客DB、履歴管理、分析 |
| 自動化の対象 | マーケティングプロセス | 営業プロセス | データ統合・レポーティング |
| KPI例 | リード数、MQL転換率、開封率 | 受注率、商談期間、案件単価 | LTV、顧客満足度、解約率 |
| データの中心 | 行動データ（Web、メール） | 商談・活動データ | 顧客マスターデータ |
「リードの旅」で理解するMA・SFA・CRMの連携ポイント
3つのツールの違いを直感的に理解するには、1件のリードが最初の接点から受注、契約後のフォローに至るまでの「旅」を追うのが近道です。個々の機能を比べるよりも、旅のどこでどのツールが主役になり、どこで主役が交代するのかを見るほうが、連携の設計ポイントが見えてきます。
リードの旅の全体像
リードの旅は、大きく次のステージに分かれます。
- Anonymous（匿名訪問者） — Webサイト訪問、広告クリック
- Known Lead（実名リード） — フォーム送信、名刺交換
- MQL（Marketing Qualified Lead） — スコアリング基準を達成
- SQL（Sales Qualified Lead） — 営業が商談価値ありと判断
- Opportunity（商談） — 具体的な提案・見積フェーズ
- Customer（顧客） — 受注・契約締結
- Advocate（推奨者） — リピート・紹介
この旅は一方通行ではありません。SQLに至らなかったリードや失注した商談は、再び育成の段階に戻り、次の検討タイミングを待ちます。旅を「ループ」として設計しておくことが、後述するリサイクル運用の前提になります。
各ツールの守備範囲マッピング
| ステージ | 主担当ツール | サブ担当ツール | 主担当部門 |
|---|---|---|---|
| Anonymous～Known Lead | MA | CRM | マーケティング |
| Known Lead～MQL | MA | CRM | マーケティング |
| MQL→SQL（引き渡し） | MA→SFA | CRM | マーケ→営業 |
| SQL～Opportunity | SFA | CRM | 営業 |
| Opportunity～Customer | SFA | CRM | 営業 |
| Customer～Advocate | CRM | MA（リテンション施策） | CS/営業 |
表を見ると、CRMはどのステージでもサブ担当として登場します。旅全体を通して同じ顧客データを持ち続けるのがCRMであり、MAとSFAはその上で自分の担当区間を動かす、という関係です。
引き渡しポイントで起きること
リードの旅の中で断絶が起きやすいのが、MQL→SQLの引き渡しポイントです。主担当ツールも主担当部門も同時に切り替わるため、ここでマーケと営業の連携がうまくいかないと、次のような問題が発生します。
- MAで育成したリードが営業に渡った後、放置される
- 営業が「このリードは質が低い」と感じ、MAへの信頼が低下する
- マーケ側は「リードを渡したのに営業が動かない」と不満を持つ
- 結果として、マーケと営業の対立構造が固定化する
これらは担当者の姿勢の問題に見えがちですが、多くは「MQLとは何か」「渡された後に何をいつまでにするか」が決まっていないことから生じます。次の章では、この基準をどう設計するかを扱います。
MQL→SQLの引き渡し基準（SLA）を設計する
引き渡しを仕組みにするには、MQLの定義、SQLの判断基準、双方の約束事（SLA）の3点をそろえます。いずれもマーケティング部門だけ、営業部門だけで決めると、もう一方が納得せずに形骸化します。両部門のマネージャーと、受注経験の多い営業担当者が同じテーブルで決めることをおすすめします。
MQL定義の設計方法
MQLは、企業や担当者が自社のターゲットに合っているか（属性）と、どれだけ関心を示しているか（行動）の2軸で判定します。点数の付け方は業種や商材で変わるため、ここでは項目と重みの考え方を示します。
属性スコア（Fit Score）の設計項目：
| スコア項目 | 配点例 | 判定基準 |
|---|---|---|
| 企業規模 | 0～20点 | 従業員数・売上規模で区分 |
| 業種 | 0～15点 | ターゲット業種に合致するか |
| 役職・部門 | 0～20点 | 意思決定者・影響者か |
| 地域 | 0～5点 | 対応可能エリアか |
行動スコア（Engagement Score）の設計項目：
| スコア項目 | 配点例 | 判定基準 |
|---|---|---|
| Webページ閲覧 | 1～5点/回 | 製品ページは高配点 |
| 資料ダウンロード | 10～20点/回 | 導入事例は高配点 |
| セミナー参加 | 15～25点/回 | 個別相談会は最高配点 |
| メール開封・クリック | 1～3点/回 | クリックを重視 |
| 料金ページ閲覧 | 15点/回 | 購買意欲の強いシグナル |
MQL認定の閾値は「属性スコア○点以上 かつ 行動スコア○点以上」のように、2軸の両方に下限を置く形が扱いやすいと考えています。たとえば自社の検証用に属性スコア40点以上、行動スコア30点以上と仮置きし、両方を満たしたリードだけを営業に渡します。これは製品や業界の共通基準ではありません。過去の受注者と失注者に同じルールを当て、MQL件数と営業が対応に値すると判断した割合を見て調整します。行動スコアだけで判定すると、ターゲット外の熱心な情報収集者がMQLになり、営業の信頼を失う原因になります。閾値は、過去に受注した顧客が受注前にどんな行動をしていたかを振り返り、そこから仮置きするのが現実的です。
SQL認定の判断基準
営業がMQLを受け取った後、初回アプローチを経てSQLとして認定するかどうかを判断します。BANT条件を基本フレームワークとして使うのが一般的です。
- Budget（予算）： 予算の目途が立っているか
- Authority（決裁権）： 意思決定者またはその影響者か
- Need（ニーズ）： 具体的な課題・要件が存在するか
- Timeline（時期）： 導入検討の時期が明確か
何項目を満たせばSQLとするかは、事前にマーケと営業で合意しておきます。判定結果は口頭ではなくSFA上の項目として残し、「SQLにしなかった理由」も選択式で記録しておくと、あとでマーケ側がスコアリングを直す材料になります。
マーケ営業連携のSLAテンプレート
マーケと営業の連携を仕組み化するために、次のようなSLA（Service Level Agreement）を取り決めます。基準値は自社の体制に合わせて決める欄です。たとえば月間MQLが20件、営業が期限内に初回対応した件数が15件なら、対応率は15÷20＝75%です。分母を「受け渡したMQL」、分子を「合意した期限内に対応したMQL」と定義し、翌月の改善対象を特定します。20件・15件は計算方法を示す架空の例であり、推奨値ではありません。
マーケティング側のコミットメント：
| SLA項目 | 基準値 | 測定方法 |
|---|---|---|
| 月間MQL創出数 | ○件以上 | MA管理画面で計測 |
| MQLの品質基準 | スコアリング基準を満たすこと | 属性+行動スコア |
| リード情報の完全性 | 必須項目入力率95%以上 | CRMレポート |
営業側のコミットメント：
| SLA項目 | 基準値 | 測定方法 |
|---|---|---|
| 初回コンタクトまでの時間 | MQL通知後24時間以内 | SFA活動ログ |
| フォローアップ回数 | 最低3回のアプローチ | SFA活動ログ |
| SQL/非SQL判定の報告 | MQL受領後5営業日以内 | SFAステータス更新 |
| 非SQL理由のフィードバック | 必須（選択式+自由記述） | SFAカスタム項目 |
基準値を決めるときは、営業が今のリソースで守れる水準から始めるのがおすすめです。守れない約束を置くとSLAそのものが無視されるようになります。数か月運用して遵守状況が安定してから、時間や回数を詰めていく順番が扱いやすいと考えています。
MA・SFA連携のデータフロー設計
基準を決めたら、それをツール間のデータの流れに落とし込みます。「どのデータを、どの方向に、どのタイミングで」同期するかを決めないまま連携を始めると、片方でしか更新されない項目が生まれ、結局スプレッドシートで突き合わせる作業が残ります。ここでは項目、方式、タイミング、項目数の順に整理します。
連携すべきデータ項目の整理
MA→SFA方向（マーケ→営業）：
- リード基本情報（会社名、氏名、連絡先）
- リードスコア（属性スコア+行動スコア）
- 行動履歴サマリー（直近のWeb閲覧、資料DL、セミナー参加）
- MQL認定日時
- 流入チャネル・キャンペーン情報
SFA→MA方向（営業→マーケ）：
- 商談ステータス（SQL認定/不認定、進捗状況）
- 不認定理由（マーケ施策改善のフィードバック）
- 受注/失注結果と失注理由
- 商談金額・受注金額
連携方式の選択肢
| 連携方式 | 特徴 | 適するケース |
|---|---|---|
| ネイティブ連携 | 同一ベンダーのツール間連携 | 統合型プラットフォーム利用時 |
| API連携 | 各ツールのAPIを直接接続 | 開発リソースがある場合 |
| iPaaS連携 | Zapier、Make等の連携ツール経由 | ノーコードで素早く実現したい場合 |
| CSV手動連携 | 定期的なファイルインポート/エクスポート | 暫定対応・小規模運用 |
ただし、CSV手動連携は担当者の作業に依存するため、担当者が休んだり異動したりすると更新が止まります。CSVで始める場合は、誰が・何曜日に・どのファイルを取り込むかを手順書にし、取り込み漏れが続いたらAPIかiPaaSへ移る、という切り替え条件を最初に決めておくと移行判断がぶれません。
リアルタイム連携とバッチ連携の判断基準
MQLの引き渡しは、リードの温度感が高いうちに営業がアプローチできるかどうかが成果を左右します。そのため、MQL認定→SFAへの通知とタスク作成は、リアルタイム（またはそれに近いタイミング）で行う設計が理想です。
一方、SFA→MAへの商談結果のフィードバックは、日次のバッチ処理でも多くの場合は足ります。判断に迷ったら、「そのデータを受け取った人が、当日中に行動を変えるか」で分けてください。行動を変えるならリアルタイム、翌日以降の分析に使うだけならバッチ、が一つの目安です。
同期する項目は最小限から始める
連携を設計するとき、「念のため」に項目を増やしたくなります。
同期・入力の対象は、「営業プロセス上、次のアクションを決めるのに知っておくべき情報」と「経営レポートで管理する情報」の2種類に絞ることをおすすめします。項目の追加・変更は管理者だけが行える運用にしておくと、部門ごとに項目が増殖するのを防げます。
リード引き渡しプロセスの運用設計
データの流れができても、それを誰がいつ動かすかが決まっていなければ引き渡しは回りません。ここでは、自動化するワークフロー、ツールでは埋まらない認識のずれを埋める定例、SQLにならなかったリードを戻すリサイクルの3つを設計します。いずれも個人の頑張りではなく、担当者が入れ替わっても同じように回る形を目指します。
引き渡しワークフローの構築
リード引き渡しを属人化させないために、次のワークフローを自動化します。
- MQL認定トリガー： スコアリング基準達成を自動検知
- 営業担当アサイン： 地域・業種・ラウンドロビン等のルールで自動割り当て
- 通知送信： SFA上のタスク作成+メール/Slack通知
- 引き渡し情報の自動生成： リードの行動履歴サマリーを自動作成
- フォロー期限の設定： SLA基準に基づく期限アラート
- エスカレーション： 期限超過時にマネージャーへ自動通知
最初から6段階すべてを作る必要はありません。まず1〜3（検知・割り当て・通知）を動かし、営業が通知を受けて動ける状態になってから、4〜6を足していく順番をおすすめします。
フォームからの問い合わせには、営業目的の売り込みや採用の問い合わせも混ざります。これを人が1件ずつ仕分けている場合、AIによる分類をワークフローに組み込む方法があります。次の画面は、問い合わせ内容をAIで判定し、その結果に応じて分岐してレコードを更新するワークフローの例です。
ただし、AIの分類は誤ることがあります。AIに任せるのは「営業問い合わせか、検討中の見込み顧客か」といった一次分類までにとどめ、SQLとして商談化するかどうかは営業担当者が判断する分担をおすすめします。運用開始後は、AIの判定と営業の判断が食い違った問い合わせを週に一度まとめて見直し、分類の指示文を修正していくと精度が上がっていきます。
定例ミーティングの設計
ツール連携だけでは解決しない「認識のずれ」を埋めるために、マーケと営業の定例ミーティングを設計します。
週次ミーティング：
- 今週のMQL引き渡し件数と営業フォロー状況の共有
- 営業からのリード品質フィードバック共有
- 直近の注目リード・案件の情報共有
月次レビュー：
- MQL→SQL転換率の推移分析
- SLAの遵守状況レビュー
- スコアリング基準・MQL定義の見直し検討
- 次月のキャンペーン計画と営業側の受入体制のすり合わせ
定例で使う数字は、会議の前にスプレッドシートで集計し直すのではなく、CRMのダッシュボードをそのまま画面に映す形にしておくと準備の手間が消えます。数字の出どころが一つになるため、「その数字はどこから取ったのか」という議論に時間を使わずに済みます。
リサイクルリードと失注掘り起こしの運用
SQLに認定されなかったリードや、商談化したものの失注したリードを、MAに戻して再育成する「リサイクル」の仕組みも重要です。
- 非SQL判定リード： MAのナーチャリングプログラムに自動投入
- 失注リード： 失注理由に応じたフォローアップシナリオを設定（時期尚早なら一定期間後に再アプローチ、予算不足なら次の予算策定時期に合わせて情報提供）
- 休眠リード： 一定期間アクションがないリードに再活性化キャンペーンを実施
失注理由は、価格・競合他社・製品機能・時期・社内決裁のようにカテゴリーで記録しておくことをおすすめします。自由記述だけでは集計できませんが、カテゴリーで残っていれば、どの理由で失注しているのかを円グラフなどで可視化できます。製品機能が理由の失注が多ければ、その声をマーケや製品開発に共有できるため、営業とマーケの連携の材料にもなります。
引き渡しプロセスを評価する5つのKPI
引き渡しがうまく回っているかは、感覚ではなく数字で見ます。ここで挙げるKPIは、MA・SFA・CRMのどれか一つだけでは算出できず、データが連携して初めて測れるものです。言い換えれば、これらのKPIが出せるかどうかが、連携設計ができているかの試金石になります。
ファネル全体のKPI設計
| KPI | 計算式 | 目安値 | 測定ツール |
|---|---|---|---|
| MQL創出数 | 月間のMQL認定件数 | 業種・規模により異なる | MA |
| MQL→SQL転換率 | SQL数 ÷ MQL数 × 100 | 20～30% | MA+SFA |
| 平均初回コンタクト時間 | MQL通知～初回アプローチの平均時間 | 24時間以内 | SFA |
| SLA遵守率 | SLA基準内に対応した件数 ÷ 全MQL数 × 100 | 90%以上 | SFA |
| SQL→受注転換率 | 受注数 ÷ SQL数 × 100 | 15～25% | SFA+CRM |
一般的な「業界平均」を目標にするより、自社の過去実績を起点に置くほうが、改善の手応えをつかみやすいと考えています。まだデータがない場合は、最初の数か月を計測期間と割り切り、その実績を基準にしてください。
KPIの定期レビューと改善サイクル
KPIは、商談のクローズ日やステージ別に集計できる形で見られるようにしておきます。以下の画面は、取引をクローズ日別に集計したHubSpotのレポート例です。
KPIが目標を下回った場合は、どこで詰まっているかによって打ち手を変えます。
| 下回ったKPI | 疑うべき原因 | 改善アクション |
|---|---|---|
| MQL→SQL転換率 | MQLの基準が緩い | 属性スコアの重み調整、行動スコアの閾値引き上げ |
| 初回コンタクト時間 | 通知が届いていない・埋もれている | 通知方法の見直し、アサインルールの調整 |
| SLA遵守率 | 営業の手が足りていない | エスカレーションルールの強化、営業リソースの再配分 |
MQL→SQL転換率が極端に高い場合は、逆にMQLの基準が厳しすぎて、営業に渡すべきリードまで取りこぼしている可能性があります。転換率は高ければよいのではなく、MQL創出数と組み合わせて見るのがポイントです。
日本企業特有の課題と対処法
稟議文化とリードスコアリングの調整
日本企業の購買プロセスでは、稟議を通すために複数の関係者が関与します。そのため、個人単位のスコアリングだけでは、実際には社内で検討が進んでいるのに、一人ひとりのスコアが閾値に届かないという状況が起きます。
- 対処法： 同一企業からの複数リードを会社単位で集約評価する「アカウントベーススコアリング」を取り入れる
- 決裁者だけでなく、起案者・影響者のアクションもスコアに反映する
コンタクト（個人）と会社の両方でステージを管理すると、「リード数は多いのに、会社単位で見ると意外と少ない」といった実態も見えるようになります。個人の最も進んだステージを会社のステージとして扱う設計にすると、営業は会社単位で優先順位を判断しやすくなります。
部門間サイロ化への対策
マーケティング部門と営業部門が別の事業部に属しているケースや、それぞれが異なるKPIで評価されているケースでは、連携が困難になります。マーケはMQL数で、営業は受注額で評価されていると、引き渡しの質は誰の責任でもなくなります。
- 対処法： 共通KPI（例：MQL→受注の一気通貫転換率）を設定し、両部門が同じゴールを追う構造を作る
- 経営層がスポンサーとなり、部門横断プロジェクトとして連携設計を推進する
Excel依存からの段階的移行
現在Excelでリード管理を行っている場合、一足飛びにMA・SFA・CRMの3ツールを同時導入するのは現実的ではありません。顧客リストと担当者リストが別々のファイルにあり、どちらが最新か分からないという状態のままツールを入れると、その混乱がそのままツールに持ち込まれます。
推奨する段階的移行ステップ：
| フェーズ | 取り組み | 次へ進む目安 |
|---|---|---|
| Phase 1 | CRMを導入し、顧客データの一元管理基盤を構築 | 顧客情報の参照先がCRMに一本化されている |
| Phase 2 | SFAを導入（またはCRMのSFA機能を活用）し、商談管理を仕組み化 | 商談の状況をCRM上のレポートで追える |
| Phase 3 | MAを導入し、リード獲得・育成プロセスを自動化 | MQLの定義が決まり、営業と合意できている |
| Phase 4 | 3ツールの連携設計を最適化し、引き渡しプロセスを確立 | SLAとKPIを定例で回せている |
受注目標や受注件数のように、まず数えやすいところから始めて、各フェーズの目安を満たしてから次に進む進め方をおすすめします。
1つのプラットフォームで運用する場合の設計ポイント
ここまでは、MA・SFA・CRMを別々のツールとしてつなぐ前提で説明してきました。一方で、1つのプラットフォーム上でMA・SFA・CRMの機能を統合的に使う選択肢もあります。この場合、ツール間の同期という課題は小さくなりますが、ステージの定義やルールの設計はそのまま残ります。HubSpotを例に、コンタクト→取引→顧客→請求という流れの中で引き渡しをどう表現するかを整理します。
ライフサイクルステージで引き渡しを表現する
HubSpotでは、コンタクトや会社が検討段階のどこにいるかを「ライフサイクルステージ」で管理します。（出典：Use lifecycle stages）
ステージの名前や数は標準のままにせず、自社のカスタマージャーニーをもとに定義し、各ステージの担当部門と担当者を決めることをおすすめします。BtoBとBtoCでは当然設計が変わりますし、同じBtoBでも商材によってMQLに求める条件は異なります。
取引パイプラインで商談以降をつなぐ
SQL以降は、コンタクトに紐づく「取引」をパイプライン上で管理します。パイプラインは次の4要素で設計すると、商談の状況が属人化しにくくなります。
| 要素 | 設計の考え方 |
|---|---|
| 取引ステージ | 受注の可能性が変わるポイントでステージを区切る |
| 受注確度 | ステージごとに受注確度を置き、金額と掛け合わせてフォーキャストを出す |
| ステージ定義 | 各ステージに進む条件を言葉で定義し、社内で共有する |
| 必須入力項目 | ステージを進めるときに入力が要る項目を決め、ツール側で必須にする |
必須入力項目は、データの品質を保つだけでなく、新しく入った営業担当者に「この段階で何を確認すべきか」を教える役割も果たします。受注後に金額やクローズ日を変更できないようにしておくと、「先月締めた数字とレポートが違う」という事態も防げます。取引が受注になれば、コンタクトと会社のライフサイクルステージを顧客に進め、その後の請求や契約更新の管理へとつなげていく流れになります。
統合型でも解決しないこと
ただし、ツールを1つにまとめても、MQLとSQLの定義が合意されていなければ、引き渡しの問題はそのまま残ります。統合型が解決するのはデータの断絶であり、部門間の基準のずれではありません。
また、ここで紹介したステージ設計や失注ループの考え方は、HubSpotに限らず、コンタクト・会社・商談を関連付けて管理できるCRMであれば同じように組めます。ツール選定で迷っている場合は、「今のExcelの管理項目を、どのオブジェクトにどう置き換えるか」を書き出してみると、自社に合う構成が見えてきます。
BtoBマーケティングの全体像はBtoBマーケティング完全ガイドで体系的にまとめています。また、このテーマのカテゴリ全体はメールマーケティング・MAで網羅しています。
よくある質問
Q. MA・SFA・CRMは3つとも導入すべきですか？
企業の規模やフェーズによって異なります。まずCRMで顧客データの一元管理を始め、営業プロセスが複雑化してきたらSFA、リード数が増えてきたらMAという順序で段階的に導入するのが現実的です。1つのプラットフォームでMA・SFA・CRMの機能を統合的に提供するツールを選べば、段階ごとに機能を追加していく進め方もとれます。
Q. MQLの定義は一度決めたら変えないほうがよいですか？
定期的に見直すことをおすすめします。MQL→SQL転換率が低すぎる場合は基準が緩すぎ、高すぎる場合は基準が厳しすぎて機会損失が起きている可能性があります。月次レビューで転換率とMQL創出数の推移を見て、定義を変えるかどうかをマーケと営業で判断する運用が扱いやすいと考えています。
Q. マーケと営業でツールが異なる場合、連携はどうすればよいですか？
API連携やiPaaS（Zapier、Makeなど）を活用したデータ同期が基本です。完全なリアルタイム連携が難しい場合でも、MQL通知とリード情報の受け渡しだけをまず自動化すると、フォロー漏れは大きく減らせます。商談結果の戻しは、その後に日次バッチで追加する順番で構いません。
Q. リードスコアリングの点数設定はどう決めればよいですか？
過去の受注データを分析し、受注に至ったリードに共通する属性や行動パターンを特定するのが理想です。データが十分にない場合は、営業担当者へのヒアリングをもとに仮説ベースで設定し、運用しながら調整していく方法が現実的です。非SQL理由のフィードバックが溜まってきたら、その内容を配点の見直しに反映してください。
Q. 小規模な組織でもMA・SFA連携の設計は要りますか？
マーケと営業の担当者が少人数であっても、リードの引き渡し基準を明確にしておく価値はあります。少人数のうちは口頭で回っていても、担当者が増えたり入れ替わったりした時点で基準が失われます。人数が少ないうちに基準とプロセスをツールに組み込んでおけば、組織が拡大した際にスムーズにスケールできます。
まとめ
MA・CRM・SFAは、それぞれ育成・商談管理・顧客データ基盤という異なる役割を持つツールですが、「リードの旅」という一つの流れの中で連携してこそ効果を発揮します。特にMQL→SQLの引き渡しポイントは、主担当のツールと部門が同時に切り替わるため、マーケティングと営業の連携品質を左右します。
押さえておきたいポイントは次のとおりです。
- 定義の合意： MQL・SQLの定義をマーケと営業が共同で策定する
- SLAの設計： 引き渡し基準と対応期限を明文化し、双方がコミットする
- データの往復： MA→SFAだけでなく、商談結果と非SQL理由をMAに戻す
- リサイクルの仕組み： 非SQL・失注リードを育成段階に戻すループを自動化する
- 継続的改善： KPIを定期的にレビューし、スコアリング基準やプロセスを見直す
まずは、現在マーケと営業がそれぞれ「MQL」「SQL」をどう捉えているかを書き出すところから始めてみてください。次の行動としては、以下の3ステップをおすすめします。
- 過去に受注した顧客を数件選び、受注前にどのような行動や属性があったかを振り返る
- その結果をもとに、MQLの仮定義とSQLの判断基準をマーケ・営業の責任者で合意する
- MQL認定から営業への通知・担当割り当てまでを自動化し、月次でKPIを見直す
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
MAと営業の連携設計を深める際は、次の記事も参考にしてください。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
