マーケ・セールス連携の仕組み作り｜失敗しない5つのステップ

なぜマーケとセールスの連携は機能しないのか

連携施策を打つ前に、機能不全の構造的な原因を把握することが先決です。表層的な対処では再発します。

マーケセールス連携の失敗は、多くの場合「コミュニケーション不足」として片付けられます。しかし、それは症状であって原因ではありません。根本には以下の3つの構造問題があります。

• 評価指標の分断：マーケティングはリード数やCPA、セールスは受注数や売上で評価される。両者の指標が交わらないため、互いの行動が最適化される方向が異なる。
• リード定義の不一致：マーケが「良質なリード」と判断した基準とセールスが「アプローチ可能なリード」と感じる基準が文書化されておらず、暗黙の認識ズレが蓄積する。
• フィードバックループの欠如：セールスがアプローチした結果（商談化率、失注理由）がマーケに返ってこない。マーケは施策改善の材料を持てない。

これらは個人の努力では解決できません。仕組み、つまりプロセス・合意・ツールの組み合わせによって初めて構造ごと変えることができます。

仕組み作りの全体像：5つのステップ

連携の仕組みは一度に構築できるものではありません。優先度の高い順に段階的に整備することが、定着への近道です。

マーケセールス連携を仕組みとして機能させるには、以下の5つのステップを順番に整備することを推奨します。ステップをスキップすると後続の施策が空転します。

1. リード定義の合意（MQL/SQLの設計）
2. SLA（サービスレベルアグリーメント）の締結
3. 共有KPIと定例会議の設計
4. リードスコアリングの実装
5. ツール統合とデータの一元化

以降のセクションで各ステップを詳しく解説します。

ステップ1：MQL・SQLの定義を両部門で合意する

リード品質の認識を揃えることが、連携施策すべての土台になります。この合意なしには、SLAもスコアリングも機能しません。

MQLとSQLとは何か

MQL（Marketing Qualified Lead）は、マーケティング施策によって一定の関心を示したと判断されるリードを指します。SQL（Sales Qualified Lead）は、セールスがアプローチするに値すると判断したリードです。この2つの概念自体は広く知られていますが、実際の定義内容が組織によって大きく異なること、そして文書化されていないことが問題の核心です。

合意すべき具体的な項目

MQL/SQLを定義する際には、以下の項目を両部門の担当者が同席したうえで合意し、文書として残してください。口頭合意は数週間で形骸化します。

• 企業属性：対象業種、従業員規模、売上規模などのフィット条件
• 行動データ：ウェビナー参加、資料ダウンロード、特定ページ訪問などのエンゲージメント条件
• 役職・決裁権：担当者レベルか意思決定者レベルかの区別
• タイムライン：直近3ヶ月以内の検討フェーズにあるか否か
• 除外条件：競合他社、学生、既存顧客など対象外の明示

合意プロセスの進め方

実務上、最初の合意セッションは1時間程度のワーキングセッションとして設定し、マーケのマネージャーとセールスのマネージャーが同席する形が機能しやすいです。このとき「理想のリード像」を語り合うより、「過去1年間で受注に至ったリードの共通点」を実データから抽出するアプローチの方が合意に至りやすい傾向があります。

ステップ2：SLAを締結してリードの引き渡しルールを明文化する

SLAは互いへの約束であり、曖昧な期待値を排除するための最も実効性の高い手段です。

BtoBマーケにおけるSLAとは

SLAとは本来、IT・サービス領域で用いられるサービス品質の約束事を指しますが、マーケセールス連携においては「マーケはどれだけのリードを、どの品質で渡すか」「セールスはそのリードにどの期間内にコンタクトするか」という相互の約束として機能します。

SLAに盛り込むべき項目

• マーケからの供給量：月間MQL数の目標値と許容範囲
• マーケからの品質保証：MQL定義の充足率（例：スコア70点以上のリードを90%以上）
• セールスの初回コンタクト期限：MQL受領後○営業日以内に初回アプローチ（例：2営業日以内）
• セールスのフィードバック義務：アプローチ結果（商談化・保留・対象外）をCRMに入力する期限
• レビュー頻度：月次でSLA達成状況を確認する定例会議の設定

SLAが形骸化しやすい理由と対策

SLAは作成した時点では機能しても、3ヶ月後には誰も参照していないケースが多くあります。形骸化の主因は「測定されていないこと」です。SLA達成状況をダッシュボード化し、月次の連携会議で数値を可視化することが、継続的な実効性を保つための最低条件です。

ステップ3：共有KPIと連携定例の設計

評価指標を揃えることで、両部門が同じゴールに向かって動く構造を作ります。会議の設計もあわせて整備します。

共有KPIの設計思想

マーケとセールスの評価指標が分断している限り、連携は表面的なものにとどまります。両部門が共同で責任を持つKPIを設けることで、行動の方向を揃えることができます。共有KPIとして機能しやすい指標は以下の通りです。

• パイプライン貢献額：マーケ起点のリードから生まれた商談の合計金額。マーケの活動が売上にどれだけ貢献しているかを可視化する。
• MQL→SQL転換率：マーケが渡したリードのうち、セールスが商談化した割合。リード品質の継続的な改善指標として機能する。
• リードサイクルタイム：リード獲得から初回商談まで要した日数。プロセスの滞留ポイントを特定するために使う。

連携定例会議の設計

共有KPIを機能させるには、定期的に数値を確認し、課題を言語化する場が必要です。連携定例会議は以下の構成が実務的に機能しやすいです。

• 頻度：月1回（状況によっては隔週）
• 参加者：マーケマネージャー、セールスマネージャー、インサイドセールスリーダー
• アジェンダ：①先月のSLA達成状況の確認 ②共有KPIのレビュー ③失注・保留リードの原因分析 ④翌月の施策調整
• 所要時間：60分以内に収める（長くなると形骸化する）

ステップ4：リードスコアリングの設計と運用

スコアリングはMQL判定を属人化・感覚値から解放するための手段です。設計よりも運用サイクルの方が重要です。

スコアリングの基本構造

リードスコアリングとは、各リードの属性情報と行動データに対してポイントを付与し、合計スコアによってMQL/SQLを自動判定する仕組みです。主に以下の2軸で設計します。

• デモグラフィックスコア（フィットスコア）：企業規模・業種・役職など、理想顧客プロフィールへの適合度を数値化する
• ビヘイビアスコア（エンゲージメントスコア）：ウェビナー参加（+10点）、価格ページ閲覧（+15点）、メール開封（+3点）など行動の重みを設定する

スコアリング設計で陥りやすい失敗

スコアリングの設計段階でよくある失敗は、「点数を付けること」が目的化してしまい、スコアの根拠をセールスが信頼しないまま運用がスタートするケースです。セールスが実際にアプローチして「スコアが高いのに商談化しなかったリード」の共通点を毎月確認し、スコア設計をアップデートするサイクルを仕組み化することが重要です。最初の設計が完璧である必要はなく、改善サイクルを回せることの方が価値があります。

インサイドセールスとの役割分担

MQLをそのままフィールドセールスに渡すのではなく、インサイドセールスがMQLのナーチャリングと商談化のフィルタリングを担う構造は、企業規模を問わず有効です。マーケ→インサイドセールス→フィールドセールスという3層構造を設計することで、各フェーズの責任者を明確にできます。

ステップ5：ツール統合とデータの一元化

ツールの連携は手段であって目的ではありません。データが一元化されることで、初めて仕組みが自動的に機能します。

MAとCRMの統合が基本

マーケセールス連携の技術的基盤は、MA（マーケティングオートメーション）とCRM（顧客管理システム）の連携です。MAでリードの行動データを蓄積し、スコアに基づいてCRMにリードを自動移行する流れを構築することで、手動でのリード引き渡しを排除できます。

ただし、ツールを導入・連携すること自体は目的ではありません。ツールが正しく機能するためには、前述のMQL定義・SLA・KPI設計が先に完成している必要があります。ツールから始めると、設定が複雑化し、誰も使わないまま放置されるリスクがあります。

データの一元化で得られる具体的な効果

• マーケがセールスのパイプライン状況をリアルタイムで確認できる
• セールスがリードの過去の行動履歴を見てアプローチ内容をパーソナライズできる
• 失注・保留リードを自動的にナーチャリングシナリオに戻すことができる
• 共有KPIのダッシュボードを自動更新できる

ツール選定より先に問うべきこと

「どのMAを使うべきか」という質問の前に、「現状のリード数は何件か」「セールスは何名いるか」「既存のCRMは何か」を確認してください。リード数が月間50件未満、セールス5名以下のフェーズでは、高機能なMAよりもCRMの活用精度を上げることが先決のケースが多くあります。

よくある失敗パターンと回避策

多くの企業が同じ失敗を繰り返します。典型パターンを把握することで、同じ轍を踏む確率を下げられます。

失敗パターン1：セールスが連携に非協力的なまま進める

マーケ主導で仕組みを設計し、セールスに「使ってください」と展開するアプローチは高確率で失敗します。セールスにとって新しいプロセスは業務負荷の増加に見えるため、初期段階から巻き込むことが必要です。MQL定義の合意セッションにセールスのトップパフォーマーを参加させるのが効果的です。彼らが設計に関わることで、現場への浸透速度が変わります。

失敗パターン2：仕組みが整う前にツールを先行導入する

MA導入後に「どう使えばいいかわからない」という状況は、プロセスが未整備のままツールを入れた結果です。ツールはプロセスを自動化するものであり、プロセスの代替にはなりません。ステップ1〜3が完成した後でツール選定を進めることを推奨します。

失敗パターン3：PDCAが回らず施策が陳腐化する

月次の連携定例が「数字の確認会」に終始し、施策の改善が起きないケースがあります。これを防ぐには、アジェンダに「翌月の変更点の決定」を必ず含め、会議の終わりに必ずアクションオーナーと期日を決めるルールを設けることです。

まとめ

マーケセールス連携を機能させるためのポイントを整理します。

• 連携不全の原因は「評価指標の分断」「リード定義の不一致」「フィードバックループの欠如」の3層構造にある
• 仕組み作りは①MQL/SQL定義 → ②SLA → ③共有KPI・定例 → ④スコアリング → ⑤ツール統合の順で進める
• ツールはプロセスが整った後に導入する。逆順は機能しない
• セールスを設計段階から巻き込むことが、現場定着の最重要条件
• 月次の連携定例でSLAと共有KPIを継続的にレビューし、改善サイクルを止めない

仕組みの完成度より、改善サイクルが回り続けていることの方が長期的な成果に直結します。まず「MQL定義の合意セッション」を設定することが、最初の一手として最も投資対効果が高い行動です。

よくある質問（FAQ）

MQLとSQLはどう違うのですか？

MQL（Marketing Qualified Lead）はマーケティング施策によって一定の関心・適合度を示したと判断されたリードです。SQL（Sales Qualified Lead）は、MQLのうちセールスが実際にアプローチ可能と判断し、商談化フェーズに移行したリードです。両者の違いは「判断主体」にあり、MQLはマーケが、SQLはセールスが判定します。

SLAはどの規模の企業から導入すべきですか？

明確な規模の基準はありませんが、マーケとセールスが別々の担当者として分業している状態であれば、リード数に関わらずSLAの設計は有効です。月間MQL数が10件程度であっても、初回コンタクト期限を明文化するだけで連携精度が変わります。

リードスコアリングを始めるのに高機能なMAは必要ですか？

スコアリングの概念自体はスプレッドシートでも実装可能です。重要なのはスコア設計の合意とフィードバックサイクルの仕組みであり、ツールの機能レベルではありません。月間リード数が安定し、スコアリングの判定基準が固まった段階でMAへの移行を検討するのが現実的です。

連携定例会議が毎回議論にならず形骸化するのはなぜですか？

最も多い原因は「アジェンダが数字の読み合わせだけになっていること」です。会議の設計として「前回決めたアクションの確認」と「翌月の変更事項の決定」をアジェンダの必須項目にすることで、会議が意思決定の場として機能しやすくなります。

マーケとセールスの連携改善を、経営層に承認してもらうにはどうすればよいですか？

パイプライン貢献額とリードサイクルタイムの2指標を使って「現状の非効率がどれだけの機会損失を生んでいるか」を定量化するアプローチが有効です。抽象的な連携改善の話より、「現状のMQL→SQL転換率が○%で、業界水準の○%に改善できれば年間○件の商談増加が見込める」という試算が意思決定者の承認を得やすい傾向があります。