「マーケが送ってくるリード、全然アポ取れないんですけど」——インサイドセールス（IS）チームからこの言葉を聞いたことがあるマーケティング担当者は多いはずです。
私自身、上場企業でマーケティング責任者を務めていた時、ISチームとの関係は最悪でした。マーケは「リードを月300件渡している」と胸を張り、ISは「アポ率2%で使い物にならない」と不満を募らせる。お互いが「相手の仕事の質が低い」と思っている状態です。
この対立を解消するのに1年かかりましたが、結論は「リードの定義が共有されていなかった」という単純な問題でした。MQL/SQLの定義を共同で作り、スコアリングを導入し、週次のフィードバックループを回し始めたことで、アポ率は2%から12%に改善しました。
この記事では、マーケとISの連携を仕組みとして構築する方法を解説します。
マーケとISが対立する根本原因
1. 「リードの質」の定義がない
マーケにとってのリードは「フォームを入力した人」、ISにとってのリードは「アポが取れそうな人」。この定義のズレが、すべての対立の起点です。
2. 引き渡しのタイミングが曖昧
ホワイトペーパーをDLしただけのリードも、料金ページを何度も閲覧しているリードも、同じ「リード」としてISに渡されていれば、ISの効率が下がるのは当然です。
3. フィードバックがない
ISがリードに架電した結果——アポが取れたのか、断られたのか、そもそもターゲット外だったのか——がマーケにフィードバックされなければ、マーケは改善のしようがありません。
MQL/SQLの定義を共同設計する
連携の第一歩は、MQL（Marketing Qualified Lead）とSQL（Sales Qualified Lead）の定義をマーケとISで共同で作ることです。
MQLの定義例
MQLとは「営業がアプローチする価値があるとマーケが判断したリード」です。以下の2軸で定義します。
属性スコア（フィットスコア）
| 属性 | 条件 | スコア |
|---|---|---|
| 企業規模 | 従業員100名以上 | +10 |
| 業種 | ターゲット業種に該当 | +10 |
| 役職 | 部長以上 | +10 |
| 役職 | 課長・マネージャー | +5 |
行動スコア（エンゲージメントスコア）
| 行動 | スコア |
|---|---|
| メール開封 | +1 |
| ブログ記事閲覧 | +2 |
| ホワイトペーパーDL | +5 |
| 事例ページ閲覧 | +5 |
| 料金ページ閲覧 | +10 |
| ウェビナー参加 | +10 |
| 問い合わせ | +30 |
MQL判定基準: 属性スコア15点以上 かつ 行動スコア20点以上
SQLの定義例
SQLとは「ISが商談化可能と判断したリード」です。ISがMQLに架電し、以下のBANT条件を確認して判定します。
- Budget（予算）: 予算の確保・見込みがある
- Authority（決裁権）: 意思決定者または意思決定者へのアクセスがある
- Need（ニーズ）: 具体的な課題を認識している
- Timeline（時期）: 3〜6ヶ月以内に導入検討の意向がある
4項目中3項目以上を満たせばSQLとして営業に引き渡す——というのが一般的な基準です。
リードスコアリングの設計と運用
スコアリング設計の3つの原則
1. シンプルに始める
最初から50項目のスコアリングモデルを作ると、運用が破綻します。属性3項目×行動5項目程度から始め、データを見ながら項目を追加・調整します。
2. 減点も設計する
スコアは加点だけでなく、減点も必要です。
- 30日以上アクションなし：-10点
- メール配信停止：-20点
- 競合企業のドメイン：スコア対象外
3. 定期的にキャリブレーションする
月次で「MQL判定されたリードのうち、ISが実際にアポを取れた割合」を確認し、閾値を調整します。
WebLeapがビットキーのリード獲得基盤構築を支援した際も、スコアリングモデルは四半期ごとに見直しを行い、MQLの精度を段階的に改善しました。初期設定のまま放置するのが最大のアンチパターンです。
フィードバックループの構築
マーケとISの連携で最も重要かつ、最もサボられがちなのがフィードバックループです。
週次フィードバック会議の設計
参加者: マーケ担当者、IS担当者（少なくとも各1名）
頻度: 週1回、30分
アジェンダ:
- 数字の共有（5分）
- 今週のMQL数、ISのアポ率、SQL数
- リードの質に関するフィードバック（10分）
- ISから：「今週のMQLでアポが取れたリードの特徴」「ターゲット外だったリードの特徴」
- マーケから：「今週の流入チャネル別リード数」「新しい施策のリード傾向」
- 改善アクションの決定（10分）
- スコアリング閾値の調整要否
- コンテンツの追加・修正要否
- ターゲティングの変更要否
- 翌週のアクション確認（5分）
フィードバックを仕組み化するツール
- SFA/CRM上のステータス更新: ISがリードのステータス（アポ取得/不在/ターゲット外/時期尚早）を入力
- Slack/Teamsチャネル: ISが架電結果をリアルタイムで共有
- ダッシュボード: MQL→アポ率の推移を可視化
よくある失敗パターン
失敗事例：スコアリングを導入したが、ISが無視した
ある企業でMAツールのスコアリング機能を設計し、MQL判定を自動化しました。しかし、ISチームは「スコアが高いリードでもアポが取れない」と感じ、結局自分たちで優先順位を付け直していました。
原因は、スコアリングの設計にISチームが関与していなかったことです。マーケが単独で設計したスコアリングモデルは、ISの現場感と乖離していました。MQL/SQLの定義もスコアリングも、必ずマーケとISの共同作業で作る必要があります。
SLA（サービスレベル合意）を設定する
フィードバックループを回すだけでなく、マーケとISの間でSLAを明文化することも有効です。
SLA例
| 項目 | マーケの約束 | ISの約束 |
|---|---|---|
| リード引き渡し | MQL判定基準を満たすリードのみ引き渡す | MQL受領後24時間以内に初回アプローチする |
| データ品質 | 企業名・氏名・メール・電話番号を確保 | 架電結果を48時間以内にCRMに入力する |
| フィードバック | 週次会議に必ず参加する | 週次会議に必ず参加する |
| 改善 | ISのフィードバックを月次でスコアリングに反映 | アポ不可理由を分類して記録する |
WebLeapでは、サービスサイト→リード基盤→データ分析の一貫構築を支援する中で、このマーケ-IS間のSLA設計も支援範囲に含めています。ツールの導入だけでなく、チーム間の連携の仕組みまで設計しなければ、リードは商談に変わりません。
実務者まとめ
- マーケとISの対立の根本原因は「リードの定義が共有されていない」こと
- MQL/SQLの定義は、必ずマーケとISの共同作業で設計する
- スコアリングは属性スコア+行動スコアの2軸で、シンプルに始めて定期的に調整する
- 週次フィードバック会議を仕組みとして回すことが、連携改善の最重要アクション
- SLAを明文化し、お互いの責任範囲と約束を明確にする
WebLeapのBtoBマーケティング支援サービスについて詳しくはこちら → /service/btob-marketing/