マーケティング部門が獲得したリードをセールスに渡した途端、進捗が見えなくなる。「このリードは質が低い」「そもそも件数が足りない」という応酬が繰り返される。こうした摩擦は多くのBtoB企業で慢性化しており、担当者の努力だけでは解消できません。
原因は個人の意識ではなく、連携を機能させる仕組みの不在にあります。マーケとセールスの連携は「リード定義の合意→SLA→共有KPI→スコアリング→ツール統合」の順で仕組み化すれば、属人性に頼らず機能させられます。本記事ではこの5ステップに加え、失注・保留リードをナーチャリングで資産化する体制までを実務レベルで解説します。
マーケとセールスの分業が始まったBtoB企業の担当者・マネージャー、これから連携体制を設計する経営者の方を対象としています。
目次
なぜマーケとセールスの連携は機能しないのか
連携不全の原因はコミュニケーション不足ではなく、評価指標・リード定義・フィードバックの3層で起きている構造的な断絶です。構造を変えない限り、対話を増やしても再発します。
マーケセールス連携の失敗は、多くの場合「コミュニケーション不足」として片付けられます。しかし、それは症状であって原因ではありません。根本には次の3つの構造問題があります。
- 評価指標の分断：マーケティングはリード数やCPA、セールスは受注数や売上で評価される。両者の指標が交わらないため、行動が最適化される方向も異なる。
- リード定義の不一致：マーケが考える「良質なリード」の基準と、セールスが感じる「アプローチする価値のあるリード」の基準が文書化されておらず、暗黙の認識ズレが蓄積する。
- フィードバックループの欠如：セールスがアプローチした結果（商談化率、失注理由）がマーケに返ってこない。マーケは施策改善の材料を持てない。
この3つの断絶は、BtoBファネル全体の設計のなかで「リードの受け渡し地点」がブラックボックスになっていることの表れです。個人の努力ではなく、プロセス・合意・ツールの組み合わせによって構造ごと変える必要があります。
営業の現場で何が起きているかを知る手段として、商談録画の活用があります。マーケティングが取り出せる情報は商談録画の活かし方で扱っています。
仕組み作りの全体像：5つのステップ
連携の仕組みは①MQL/SQL定義→②SLA→③共有KPI・定例→④スコアリング→⑤ツール統合の順で整備します。順番を守ることが定着への最短経路です。
マーケセールス連携を仕組みとして機能させるには、次の5つのステップを順番に整備します。ステップをスキップすると後続の施策が空転します。たとえばリード定義が曖昧なままスコアリングを組んでも、セールスは点数を信頼しません。
- リード定義の合意（MQL/SQLの設計）
- SLA（サービスレベルアグリーメント）の締結
- 共有KPIと定例会議の設計
- リードスコアリングの実装
- ツール統合とデータの一元化
さらに本記事では、5ステップの先にある「失注・保留リードのリサイクル体制」も後半で解説します。仕組みが一巡した後の成果を大きく左右する領域です。
ステップ1：MQL・SQLの定義を両部門で合意する
リード品質の認識を揃えることが、連携施策すべての土台です。この合意なしには、SLAもスコアリングも機能しません。
MQLとSQLとは何か
MQL（Marketing Qualified Lead）とは、マーケティング施策によって一定の関心と適合度を示したと判断されるリードのことです。SQL（Sales Qualified Lead）とは、セールスがアプローチする価値があると判断したリードを指します。概念自体は広く知られていますが、実際の定義内容が組織ごとに大きく異なること、そして文書化されていないことが問題の核心です。定義設計の詳細な手順はMQL・SQLの定義と設計方法で解説しています。
合意すべき具体的な項目
MQL/SQLを定義する際には、次の項目を両部門の責任者が同席したうえで合意し、必ず文書として残してください。口頭合意は数週間で形骸化します。
- 企業属性：対象業種、従業員規模、売上規模などのフィット条件
- 行動データ：ウェビナー参加、資料ダウンロード、特定ページ訪問などのエンゲージメント条件
- 役職・決裁権：担当者レベルか意思決定者レベルかの区別
- タイムライン：直近3ヶ月以内の検討フェーズにあるか否か
- 除外条件：競合他社、学生、既存顧客など対象外の明示
HubSpotを利用している場合は、合意した定義をライフサイクルステージに反映します。実装手順はHubSpotでのMQL定義・設定方法を参照してください。
合意プロセスの進め方
最初の合意セッションは1時間程度のワーキングセッションとして設定し、マーケとセールス双方のマネージャーが同席する形が機能しやすいです。このとき「理想のリード像」を語り合うより、過去1年間で受注に至ったリードの共通点を実データから抽出するアプローチの方が、合意に至りやすい傾向があります。
MQL定義は理想像の議論からではなく、過去1年の受注リードの共通点をデータから逆算する方が、両部門の合意に早くたどり着けます。
ステップ2：SLAを締結してリードの引き渡しルールを明文化する
SLAは両部門の相互の約束であり、曖昧な期待値を排除する最も実効性の高い手段です。作って終わりではなく、測定される状態にして初めて機能します。
BtoBマーケにおけるSLAとは
SLAとは本来、IT・サービス領域で用いられるサービス品質の約束事を指しますが、マーケセールス連携においては「マーケはどれだけのリードを、どの品質で渡すか」「セールスはそのリードにどの期間内にコンタクトするか」という相互の約束として機能します。一方的な要求ではなく双方向の義務にすることがポイントです。
SLAに盛り込むべき項目
最低限、次の5項目を数値つきで明文化します。
| 項目 | 内容 | 設定例 |
|---|---|---|
| マーケの供給量 | 月間MQL数の目標値と許容範囲 | 月間30件（±20%） |
| マーケの品質保証 | MQL定義の充足率 | スコア70点以上のリードを90%以上 |
| セールスの初回コンタクト期限 | MQL受領後の初回アプローチ期限 | 2営業日以内 |
| セールスのフィードバック義務 | 結果（商談化・保留・対象外）のCRM入力期限 | アプローチ後3営業日以内 |
| レビュー頻度 | SLA達成状況を確認する場の設定 | 月次の連携定例で確認 |
SLAが形骸化しやすい理由と対策
SLAは作成した時点では機能しても、3ヶ月後には誰も参照していないケースが多くあります。形骸化の主因は「測定されていないこと」です。SLA達成状況をダッシュボード化し、月次の連携会議で数値を可視化することが、継続的な実効性を保つための最低条件です。
ステップ3：共有KPIと連携定例の設計
両部門が共同で責任を持つKPIを設けることで、行動の方向が初めて揃います。あわせて、数値を確認し意思決定する定例の設計まで含めて仕組み化します。
共有KPIの設計思想
マーケとセールスの評価指標が分断している限り、連携は表面的なものにとどまります。共有KPIとして機能しやすい指標は次の通りです。
- パイプライン貢献額：マーケ起点のリードから生まれた商談の合計金額。マーケの活動が売上にどれだけ貢献しているかを可視化する。
- MQL→SQL転換率：マーケが渡したリードのうち、セールスが商談化した割合。リード品質の継続的な改善指標として機能する。詳しくはBtoBの商談化率を上げる方法で解説しています。
- リードサイクルタイム：リード獲得から初回商談までに要した日数。プロセスの滞留ポイントを特定するために使う。
共有KPIは単独で存在するものではなく、部門別KPIと接続したツリーとして設計します。全体設計の考え方はBtoBマーケのKPI設計ガイドを、可視化の実装はBtoB向けKPIダッシュボードの作り方を参照してください。
連携定例会議の設計
共有KPIを機能させるには、定期的に数値を確認し、課題を言語化する場が必要です。連携定例は次の構成が実務的に機能しやすいです。
- 頻度：月1回（立ち上げ期は隔週）
- 参加者：マーケマネージャー、セールスマネージャー、インサイドセールスリーダー
- アジェンダ：①前月のSLA達成状況の確認 ②共有KPIのレビュー ③失注・保留リードの原因分析 ④翌月の変更点の決定
- 所要時間：60分以内に収める（長くなると形骸化する）
ステップ4：リードスコアリングの設計と運用
スコアリングはMQL判定を属人的な感覚値から解放する手段です。初期設計の完成度よりも、セールスの実感とすり合わせる運用サイクルの方が重要です。
スコアリングの基本構造
リードスコアリングとは、各リードの属性情報と行動データにポイントを付与し、合計スコアによってMQLを自動判定する仕組みのことです。主に次の2軸で設計します。
- デモグラフィックスコア（フィットスコア）：企業規模・業種・役職など、理想顧客プロフィールへの適合度を数値化する
- ビヘイビアスコア（エンゲージメントスコア）：ウェビナー参加（+10点）、価格ページ閲覧（+15点）、メール開封（+3点）など行動の重みを設定する
HubSpotでの具体的な設定手順はHubSpotリードスコアリングの設定方法で解説しています。
スコアリング設計で陥りやすい失敗
設計段階でよくある失敗は、点数を付けること自体が目的化し、スコアの根拠をセールスが信頼しないまま運用がスタートするケースです。「スコアが高いのに商談化しなかったリード」の共通点を毎月確認し、スコア設計をアップデートするサイクルを仕組み化してください。最初の設計が完璧である必要はなく、改善サイクルを回せることの方が価値があります。
インサイドセールスとの役割分担
MQLをそのままフィールドセールスに渡すのではなく、インサイドセールスがナーチャリングと商談化のフィルタリングを担う3層構造は、企業規模を問わず有効です。マーケ→インサイドセールス→フィールドセールスの各フェーズに責任者を置くことで、リードの滞留と放置を防げます。役割設計の詳細はインサイドセールスとマーケの連携の仕組みを、SDR/BDRの体制論はSDRとBDRの違いを参照してください。
ステップ5：ツール統合とデータの一元化
ツール連携は手段であって目的ではありません。MQL定義・SLA・KPIが整った後に統合することで、初めて仕組みが自動的に回り始めます。
MAとCRMの統合が基本
マーケセールス連携の技術的基盤は、MA（マーケティングオートメーション）とCRM（顧客管理システム）の連携です。MAでリードの行動データを蓄積し、スコアに基づいてCRMへリードを自動移行する流れを構築することで、手動でのリード引き渡しを排除できます。両者の役割の違いが曖昧な場合は、先にCRMとMAの違いを整理しておくと選定を誤りません。
データの一元化で得られる具体的な効果
- マーケがセールスのパイプライン状況をリアルタイムで確認できる
- セールスがリードの過去の行動履歴を見てアプローチ内容をパーソナライズできる
- 失注・保留リードを自動的にナーチャリングシナリオに戻せる
- 共有KPIのダッシュボードを自動更新できる
セールス側の入力・活用まで含めた一気通貫の設計は、HubSpot Sales HubのBtoB活用法で具体的に解説しています。
ツール選定より先に問うべきこと
「どのMAを使うべきか」という質問の前に、「現状のリード数は何件か」「セールスは何名いるか」「既存のCRMは何か」を確認してください。リード数が月間50件未満、セールス5名以下のフェーズでは、高機能なMAよりCRMの活用精度を上げる方が先決のケースが多くあります。ツールの比較検討に進む段階になったら、中小企業向けMAツール比較とMA導入の失敗しない進め方が判断材料になります。
ツール統合はプロセス整備の後です。MQL定義とSLAが未完成の段階でMAを導入すると、設定が複雑化し、誰も使わないまま放置されるリスクが高くなります。
CRMの項目とステージをどう設計するかで、統合の実効性が変わります。設計の順序はCRM導入が失敗する原因で扱っています。
失注・保留リードを資産に変えるナーチャリング体制
連携の仕組みが一巡した後の成果を左右するのは、商談化しなかったリードの扱いです。失注・保留リードをマーケに戻し、再びMQL化するリサイクル経路まで設計して初めて、連携ループが閉じます。
リードリサイクルの経路を設計する
BtoBのリードのうち、初回アプローチで商談化するのは一部にすぎません。残りの大多数を「対応済み」として放置するか、育成対象として管理するかで、半年後のパイプラインは大きく変わります。設計すべきは、セールスがCRMに入力する処理結果（保留・時期尚早・失注）ごとに、リードをどのナーチャリング経路へ戻すかのルールです。たとえば「時期尚早」は3ヶ月後の再アプローチリストへ、「情報収集段階」はメールナーチャリングへ、といった振り分けを自動化します。
ナーチャリングシナリオへの接続
戻されたリードには、検討フェーズに応じたコンテンツを段階的に届けます。シナリオの組み立て方はBtoBリードナーチャリングのシナリオ設計を、メール連続配信の設計はBtoBステップメールの設計方法を参照してください。また、長期間接点のないリードを掘り起こす手法は休眠リードの掘り起こし方法で解説しています。
ナーチャリングが空回りする典型パターン
リサイクル経路を作っても、配信頻度が高すぎて配信停止を招いたり、全リードに同じメールを一斉送信して反応が取れなかったりするケースは少なくありません。こうした典型的なつまずきはリードナーチャリングが失敗する理由で整理しています。重要なのは、ナーチャリングの成果（再MQL化率）も連携定例のアジェンダに含め、セールスからの処理結果データとセットで改善を回すことです。
失注・保留リードは獲得コストを支払い済みの資産です。リサイクル経路を設計するだけで、新規獲得より低いコストで商談を生み出せます。
自社のリード状況に合わせたリサイクル設計から着手したい方は、無料相談で現状の連携フローを一緒に棚卸しすることも可能です。
既存顧客からの売上拡大についても、マーケティングと営業の分担が要ります。役割の分け方はBtoBのアップセル・クロスセルで扱っています。
よくある失敗パターンと回避策
連携の仕組み作りでは、多くの企業が同じ箇所でつまずきます。典型3パターンを先に把握しておくことで、同じ轍を踏む確率を下げられます。
失敗パターン1：セールスが非協力的なまま進める
マーケ主導で仕組みを設計し、セールスに「使ってください」と展開するアプローチは高確率で失敗します。セールスにとって新しいプロセスは業務負荷の増加に見えるため、初期段階から巻き込むことが必要です。MQL定義の合意セッションにセールスのトップパフォーマーを参加させると効果的です。彼らが設計に関わることで、現場への浸透速度が変わります。
失敗パターン2：仕組みが整う前にツールを先行導入する
MA導入後に「どう使えばいいかわからない」という状況は、プロセスが未整備のままツールを入れた結果です。ツールはプロセスを自動化するものであり、プロセスの代替にはなりません。ステップ1〜3が完成した後でツール選定を進めてください。
失敗パターン3：PDCAが回らず施策が陳腐化する
月次の連携定例が数字の確認会に終始し、施策の改善が起きないケースがあります。これを防ぐには、アジェンダに「翌月の変更点の決定」を必ず含め、会議の終わりにアクションオーナーと期日を決めるルールを設けることです。
自社がどのパターンに近いか判断がつかない場合は、第三者の視点で連携体制を診断してもらうのも有効です。
まとめ
マーケセールス連携を機能させるための要点を整理します。
- 連携不全の原因は「評価指標の分断」「リード定義の不一致」「フィードバックループの欠如」の3層構造にある
- 仕組み作りは①MQL/SQL定義→②SLA→③共有KPI・定例→④スコアリング→⑤ツール統合の順で進める。逆順は機能しない
- セールスを設計段階から巻き込むことが、現場定着の最重要条件
- 失注・保留リードのリサイクル経路まで設計して初めて連携ループが閉じる
- 月次の連携定例でSLA・共有KPI・再MQL化率をレビューし、改善サイクルを止めない
仕組みの完成度より、改善サイクルが回り続けていることの方が長期的な成果に直結します。最初の一手として最も投資対効果が高いのは、「MQL定義の合意セッション」を今月中に設定することです。
無料相談受付中
マーケとセールスの連携設計、専門家と一緒に進めませんか？
MQL定義の合意からSLA設計、HubSpotでのスコアリング実装まで、戦略から実行まで一気通貫で支援します。現状の連携フローの棚卸しだけでもお気軽にご相談ください。
よくある質問（FAQ）
- MQLとSQLはどう違うのですか？
- MQL（Marketing Qualified Lead）はマーケティング施策によって一定の関心・適合度を示したと判断されたリードです。SQL（Sales Qualified Lead）は、MQLのうちセールスが実際にアプローチ可能と判断し、商談化フェーズに移行したリードです。両者の違いは「判断主体」にあり、MQLはマーケが、SQLはセールスが判定します。
- SLAはどの規模の企業から導入すべきですか？
- 明確な規模基準はありませんが、マーケとセールスが別々の担当者として分業している状態であれば、リード数に関わらずSLAの設計は有効です。月間MQL数が10件程度であっても、初回コンタクト期限を明文化するだけで連携精度が変わります。
- リードスコアリングを始めるのに高機能なMAは必要ですか？
- スコアリングの概念自体はスプレッドシートでも実装可能です。重要なのはスコア設計の合意とフィードバックサイクルの仕組みであり、ツールの機能レベルではありません。月間リード数が安定し、判定基準が固まった段階でMAへの移行を検討するのが現実的です。
- 連携定例会議が毎回議論にならず形骸化するのはなぜですか？
- 最も多い原因は、アジェンダが数字の読み合わせだけになっていることです。「前回決めたアクションの確認」と「翌月の変更事項の決定」をアジェンダの必須項目にすることで、会議が意思決定の場として機能しやすくなります。
- マーケとセールスの連携改善を、経営層に承認してもらうにはどうすればよいですか？
- パイプライン貢献額とリードサイクルタイムの2指標を使い、現状の非効率がどれだけの機会損失を生んでいるかを定量化するアプローチが有効です。「現状のMQL→SQL転換率が○%で、○%に改善できれば年間○件の商談増加が見込める」という試算が、抽象的な連携改善の話より承認を得やすい傾向があります。