マーケティングとインサイドセールスの連携を仕組み化する実践ガイド

なぜインサイドセールスとマーケの連携は壊れるのか

このセクションでは、IS×MKT連携が機能不全に陥る構造的な原因を整理します。「うちだけの問題」ではなく、仕組みの欠如によって必然的に起きることを理解することが、設計の出発点です。

IS×MKT連携の断絶には、大きく3つの構造的原因があります。

原因1：MQLの定義が曖昧で共有されていない

「温度感が高そうなリード」「ある程度興味がある人」——このような主観的な基準でMQL（Marketing Qualified Lead）を運用している組織は多くあります。MKT側が「渡せる」と判断したリードと、IS側が「追いかける価値がある」と考えるリードの基準がずれていると、ISは渡されたリードを放置し、MKTは「なぜ動かないのか」と不満を抱えます。定量的なスコアリング基準がなければ、この認識のずれは永続します。

原因2：ハンドオフのルールが設計されていない

リードをMKTからISへ渡す際、「いつ・どの情報と一緒に・どのアクションを期待して渡すのか」が定義されていないと、ISは渡されたリードを何から着手すべきかわかりません。CRMにコンタクトが入っているだけで、コンテキスト（何に反応したか、どのページを見たか、どのフェーズの検討者か）が伝わっていなければ、ISは「また質の低いリードが来た」と判断します。

原因3：フィードバックループが存在しない

MKTはリードを渡した後、そのリードが商談化したか、失注したか、その理由を知る機会がほとんどありません。一方ISは、「マーケが送ってくるリードは検討フェーズが浅すぎる」という感覚を持っていても、それをMKTに正式にフィードバックする場がありません。フィードバックループがなければ、MKTはリード品質を改善できず、同じ問題が繰り返されます。

連携仕組み化の全体像：4つの構造要素

IS×MKT連携を仕組み化するには、4つの要素を順番に設計する必要があります。このセクションでは全体像を俯瞰し、各要素の役割と相互関係を整理します。

4要素はそれぞれ独立しているように見えますが、実際には①→②→③→④の順に依存しています。MQLが定義されていなければ何をハンドオフするか決まらず、ハンドオフルールがなければSLAの「何を守るか」が宙に浮きます。逆にいえば、①から順に設計すれば、後工程が自然に決まっていきます。

STEP1：MQL定義の設計——「渡せる」の共通言語を作る

MQL定義は連携仕組み化の最初の難関です。定性的な感覚を定量的なルールに落とす方法と、BtoBでよく使われる設計パターンを紹介します。

属性スコアと行動スコアの2軸で設計する

BtoBのMQL定義は、大きく「属性条件」と「行動条件」の2軸で構成します。

• 属性条件（フィットスコア）：企業規模、業種、役職、従業員数など、ICPに合致するかを評価する。例：「従業員50名以上・IT/SaaS業種・課長職以上」でスコア+20
• 行動条件（エンゲージメントスコア）：資料ダウンロード、ウェビナー参加、価格ページ閲覧など、購買意図を示す行動を評価する。例：「資料DL+10点、価格ページ閲覧+15点、ウェビナー参加+20点」

両スコアを合算し、一定のしきい値（例：合計40点以上）を超えたコンタクトをMQLとして定義します。しきい値の設定に正解はなく、ISとMKTが合議の上で仮設定し、3ヶ月後に商談化率をもとに調整するサイクルで運用することが現実的です。

「ネガティブスコア」も設計する

競合企業のドメインからの問い合わせ、学生・研究者属性、フリーメールアドレスなど、商談化する見込みが低いコンタクトにはマイナスのスコアを設定します。これにより、ISが「また使えないリードが来た」と感じるケースを減らせます。

MQL定義をドキュメントとして残す

スコアリングのルールだけでなく、「なぜその基準にしたか」という設計意図もドキュメントに残します。担当者が変わったときや、ルールを見直すときに、設計の背景が残っていると議論がスムーズになります。

STEP2：ハンドオフ設計——「何を・どう・誰に渡すか」を固める

MQLが定義できたら、次はそのリードをISへ渡す際の情報・手順・アクション期待を設計します。ここを省略すると、ISは渡されたリードをどう扱えばよいかわからず、結局放置されます。

ハンドオフ時に渡すべき情報の標準セット

ISがリードを受け取った瞬間に「次のアクション」を判断できるよう、以下の情報をCRM上で構造化して渡します。

• コンタクト基本情報（社名・氏名・役職・メール・電話番号）
• MQLになった理由（スコアの内訳・直近の行動履歴）
• 過去の接触履歴（何のメルマガを開封したか、どのページを何回見たか）
• 検討フェーズの推定（認知段階か、比較検討段階か）
• 推奨する初回アプローチ方法（メール・電話・LinkedIn等）と推奨メッセージの骨子

HubSpotやSalesforceなどのCRMを使っている場合、これらの情報はコンタクトレコードのカスタムフィールドとタイムラインで管理し、IS担当者に自動的にタスク通知が届く設定にすることを推奨します。

ハンドオフ通知の方法を統一する

「CRMのタスク通知」「Slackの専用チャンネルへの自動投稿」「メール通知」など、どの方法でISに通知するかを事前に合意します。通知方法が統一されていないと、ISがリードに気づかないまま時間が経過するケースが発生します。

「ハンドバック」のルールも設計する

ISが接触を試みたが連絡がとれない、または商談化の見込みがないと判断した場合に、リードをMKTへ返すルール（ハンドバック）も設計します。「3回コンタクトを試みて反応なし」「決裁権なし」などの条件を定義し、ハンドバックされたリードはMKTがナーチャリングシーケンスに戻す、という循環を設計します。

STEP3：SLA合意——双方の義務を数字で握る

SLA（Service Level Agreement）は、MKTとIS双方が果たすべき義務を数値で合意したものです。「ベストエフォート」では連携は機能しません。

MKT側のSLAとIS側のSLAは対称に設計する

SLAはISに課すものとMKTに課すもの、双方を対称に設計します。「ISは24時間以内に初回接触する」だけを決めてMKT側に何も課さないと、ISは「そんな数を渡されても追いきれない」と反発します。MKTは供給するMQL数と品質基準を、ISは初回接触期限とフォロー回数を、それぞれ数値で合意します。

SLAは「守れる水準」から始める

初回SLAの数値設定は、現状の実績をベースに「少しだけ背伸びした水準」にすることを推奨します。いきなり理想値を設定すると、最初の月でSLAを達成できず、形骸化します。3ヶ月ごとに見直し、達成率が安定したら数値を引き上げるサイクルで運用します。

STEP4：週次レビュー設計——フィードバックループを制度化する

SLAを合意したら、次はその達成状況を定期的に確認し、問題を早期に検知して改善するレビュー体制を設計します。このレビューがフィードバックループの核心です。

週次IS×MKTミーティングのアジェンダを固定する

週次のレビューミーティングは30分を上限とし、以下の固定アジェンダで運用することを推奨します。

1. KPI確認（10分）：MQL数、商談化数、商談化率、SLA達成率を数字で確認
2. MQL品質フィードバック（10分）：ISから「今週で特に動いたリード・動かなかったリード」を2〜3件共有し、なぜ動いた/動かなかったかを言語化する
3. 次週のアクション合意（10分）：KPI未達の原因に対して誰が何をするかを決める

このミーティングでISが「価格ページを見た人は比較検討フェーズが明確で商談になりやすい」「ウェビナー参加者はまだ情報収集フェーズが多く即商談は難しい」といったフィードバックを出すことで、MKTはMQL定義のスコアリングを調整する材料を得ます。これが「連携の改善サイクル」です。

レビューに使うダッシュボードを事前に整備する

毎週の会議でKPIを手作業で集計するのは非効率です。HubSpotのレポート機能やLooker Studioなどを活用し、MQL数・商談化率・SLA達成率が自動更新されるダッシュボードを事前に作成します。これにより、ミーティングの議論を「数字の確認」ではなく「原因分析とアクション合意」に集中させることができます。

よくある失敗パターンと対処法

仕組みを設計しても、運用フェーズで陥りやすい落とし穴があります。あらかじめ知っておくことで、同じ失敗を回避できます。

失敗1：MQLのしきい値を高く設定しすぎてISが暇になる

MQL品質を重視するあまり、しきい値を高く設定しすぎると、ISに渡るMQL数が激減し、ISの稼働率が下がります。MQL数と商談化率はトレードオフの関係にあるため、両者のバランスを月次で確認しながら調整します。「月間MQL数が目標の半分以下になったら、しきい値を10点下げる」といった調整ルールをあらかじめ決めておくと運用がスムーズです。

失敗2：SLAを設定したが誰も達成率を確認しない

SLAを合意しても、それを定期的にモニタリングする仕組みがなければ形骸化します。SLA達成率は週次レビューの必須アジェンダに組み込み、未達の場合は「なぜ未達か」を必ず議題にします。「今週は忙しかった」という説明だけでクローズしない運用ルールを設けることが重要です。

失敗3：レビューミーティングがKPI報告会になる

レビューミーティングで「先週のMQLは何件でした」「商談化率は何%でした」を読み上げるだけで終わるケースがあります。これはレビューではなく報告です。レビューの目的は「なぜその数字になったか」の原因分析と「来週どう変えるか」のアクション合意です。アジェンダに「原因分析」と「次週アクション担当者の明記」を必ず含めることで、会議を改善の場として機能させます。

失敗4：IS担当者の個人スキルに連携品質が依存する

優秀なIS担当者が1人いると、その人だけがフィードバックをしっかりCRMに入力し、他の担当者は最低限しか入力しない、という状況が起きます。連携の品質は「仕組み」によって担保するのが原則です。CRMの必須入力フィールドを設定し、入力が完了していないとリードが次フェーズに進めないような設計にすることで、属人依存を減らします。

組織規模別の適用方針

IS×MKT連携の仕組みは、組織の規模や成熟度によって設計の優先順位が変わります。このセクションでは規模別の現実的な適用方針を整理します。

少人数スタートアップ（IS・MKT各1〜2名）

この規模では、正式なSLAドキュメントよりも「週次の短いチェックイン（15分）でMQL状況を口頭で確認し、決めたことをNotionやスプレッドシートに記録する」だけで十分機能します。まずMQL定義を簡易版（スコアリングなし・属性条件2〜3項目だけ）で合意し、ハンドオフのCRM記録フォーマットを統一することを最初のステップにします。

成長期の中堅企業（IS5〜20名、MKT3〜10名）

この規模では、MQLスコアリングの本格実装、SLAの数値合意、週次レビューミーティングの制度化、HubSpot/Salesforceのワークフロー自動化が有効になります。チャンネルが増えるにつれ、「どのチャンネルからのリードが商談化しやすいか」というアトリビューション分析も連携改善に活用できます。アトリビューション分析の設計については、別途解説した記事もご参照ください。

まとめ

インサイドセールスとマーケティングの連携不全は、個人の努力不足ではなく仕組みの欠如によって生じます。解決策は4つの構造要素——MQL定義・ハンドオフ設計・SLA合意・週次レビュー——を①から順に設計し、PDCAで改善し続けることです。

• MQL定義：属性スコア×行動スコアの2軸で定量化し、ISとMKTが共通言語を持つ
• ハンドオフ設計：渡す情報・通知方法・ハンドバックルールをドキュメント化する
• SLA合意：MKT側とIS側の双方の義務を数値で対称に合意する
• 週次レビュー：KPI確認・MQL品質フィードバック・アクション合意の固定アジェンダで30分以内に完結する

この仕組みを設計・運用できるかどうかが、マーケティングの成果が「活動量」に見合うか否かの分岐点になります。もし現在の連携状況やMQL定義の設計について、外部の視点でレビューや設計支援が必要であれば、お気軽にご相談ください。

よくある質問（FAQ）

MQLのスコアリングしきい値はどう決めればよいですか？

初期設定に正解はありません。まず「IS全員が直感的に『これは追いかけたい』と感じるリード」の行動・属性を洗い出し、それを点数化した合計値を仮のしきい値とします。運用開始後3ヶ月で商談化率を確認し、低すぎる（品質が粗い）なら引き上げ、供給数が足りないなら引き下げる、というサイクルで調整します。

HubSpotを使っていない場合でも仕組み化できますか？

可能です。CRMが整備されていない段階でも、GoogleスプレッドシートとSlack通知を組み合わせれば、ハンドオフ情報の共有と通知は実現できます。ただし、リード数が月100件を超えてくると手動管理の限界が来るため、そのタイミングでCRM導入の検討を推奨します。

SLAを設定しようとするとISチームから抵抗があります。どう対処しますか？

抵抗の多くは「品質の悪いリードを大量に渡されるのに、追いかける義務だけ課せられる」という不信感から来ています。IS側のSLAを提示する前に、MKT側のSLA（MQL品質基準・供給数コミット）を先に提示し、「MKTも義務を負う」という対称性を示すことで、受け入れられやすくなります。

インサイドセールスが1名しかいない場合、SLAは必要ですか？

人数が少ない場合、SLAのドキュメント化より「何を・いつまでに・どうする」という口頭での合意と記録が優先されます。ただし、1名でも「MQLの定義」と「ハンドオフ時に渡す情報の標準化」は最低限行っておくことを推奨します。これがないと、IS担当者が変わったときに連携が完全に機能しなくなります。

マーケとISで目標設定（KGI）が別々に管理されていますが、連携できますか？

KGIが分断されている組織では、連携の仕組みを整えても「自分の数字だけ追えばいい」という行動原理が残ります。根本的な解決策は、共通KPI（例：MQL数ではなく商談化数や受注金額）をMKTとISが共同で持つことです。組織設計の問題のため、現場だけでは変えにくい場合は、経営層を巻き込んだKGI再設計が必要になります。