インサイドセールスとマーケティングの連携｜違い・役割分担と仕組み化の4ステップ

インサイドセールスとマーケティングは何が違うのか

両者の違いは「担当する業務」ではなく「向き合う相手の粒度」と「時間軸」にあります。ここを取り違えると、役割分担の議論が業務の押し付け合いになります。

ISとMKTはどちらも受注前のプロセスを担い、どちらもリードに接触します。だからこそ違いが曖昧になりやすいのですが、構造的には明確に異なる仕事です。

MKTは「市場」を、ISは「個人」を相手にする

MKTが向き合うのは、まだ特定されていない市場全体と、獲得済みリードの母集団です。一人ひとりの顔は見えず、セグメント単位・チャネル単位で意思決定します。一方ISが向き合うのは、名前と所属が特定された個別の見込み顧客です。相手の発言に応じて次のアクションを変える、1対1の仕事です。

この違いは、そのまま成果指標の違いに直結します。MKTはリード獲得数やMQL数といった母集団の指標を持ち、ISは接触率や商談化数という個別接触の積み上げ指標を持ちます。

時間軸が異なるため、優先順位が衝突する

MKTの施策の多くは、成果が出るまでに数か月を要します。SEOコンテンツやナーチャリングメールは、中長期の資産形成に近い性質を持ちます。対してISは、当月から翌月のパイプラインに責任を負います。「今月あと何件の商談を作るか」が行動基準です。

同じ組織にいながら見ている時間軸が違うため、「質より量を渡してほしい」「量より質を上げてほしい」という主張の対立が構造的に発生します。これはどちらかが間違っているのではなく、役割設計上の必然です。

ザ・モデルにおける両者の位置づけ

国内BtoBで広く参照される分業モデル（いわゆる「ザ・モデル」型のプロセス分解）では、リード獲得・リード育成・商談創出・受注/契約後の各工程を別部門が担います。この枠組みでは、MKTがリードを創出して育成の初期を担い、ISがそれを引き継いで商談化まで持っていき、フィールドセールスへ渡します。

重要なのは、この分業が「工程の切り分け」であって「顧客の切り分け」ではない点です。顧客から見れば一連の体験であり、途中で担当が変わったことによる情報の断絶は、そのまま不信感になります。分業モデルを採用するほど、引き継ぎの設計が必須になるという関係です。

連携以前にインサイドセールス自体が回っていない場合は、インサイドセールスが機能しない理由で原因の切り分けを扱っています。

役割分担の線引きをどこに引くか

分担が曖昧になるのは全工程ではなく、「MQL判定」と「初回接触の見極め」という2か所に集中します。この2点だけを文書で固定すれば、連携の摩擦の大半は解消します。

リード獲得はMKT、商談創出はIS。この両端は迷いません。問題は中間です。

グレーゾーンその1：MQL判定の主体

「このリードを渡すかどうか」を最終的に誰が決めるのか。MKTが一方的に判定して渡す運用にすると、ISは「勝手に送りつけられた」と受け取ります。逆にISが取捨選択できる運用にすると、MKTのMQL数は実質的にIS次第となり、KPIが成立しなくなります。

実務上の解は、判定ロジックの合意はISと共同で行い、日々の判定の実行はMKT側の自動処理に委ねる、という分け方です。「基準を一緒に決め、運用は自動化する」ことで、個別案件ごとの交渉をなくします。

グレーゾーンその2：接触後の見極めと差し戻し

ISが接触し「今は検討フェーズではない」と判断したリードを、どちらが持つのか。ISが抱え続ければ稼働が圧迫され、放置されて死蔵します。かといってMKTへ無条件に戻すと、MKTのMQL実績が後から取り消される形になり、指標が不安定になります。

ここは「差し戻しの条件」と「差し戻し後の扱い」をセットで決めます。たとえば「3回接触して応答なし」または「検討時期が6か月以上先」を満たしたらMKTへ返し、返されたリードはナーチャリングの対象に戻す。差し戻しはMQL実績の取り消しではなく次サイクルへの引き渡しである、と定義しておけば、指標上の争いを避けられます。差し戻し後の育成設計はBtoBリードナーチャリングのシナリオ設計や休眠リードの再活性化で扱っている考え方が使えます。

線引きを文書化する最小フォーマット

大がかりな規程は不要です。次の3項目を1ページにまとめ、両部門の責任者が署名するだけで機能し始めます。

• 工程一覧と、各工程の主管・補助・関与なしの区分
• MQL判定基準と、その基準を変更する際の合意プロセス
• 差し戻しの条件、差し戻し先、差し戻し後の扱い

この線引きが決まらないまま個別施策を進めても、成果は担当者の相性に依存し続けます。自社の分担設計に第三者の視点が必要であれば、現状の役割分担について相談するところから始めるのも一つの方法です。

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

連携不全の原因は3つに集約されます。いずれも仕組みの欠如によるもので、担当者を入れ替えても再発します。

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

「温度感が高そうなリード」「ある程度興味がありそうな人」。このような主観的な基準でMQL（Marketing Qualified Lead＝マーケティング部門が営業に渡す価値があると判断したリード）を運用している組織は少なくありません。MKT側の「渡せる」とIS側の「追いかける価値がある」がずれていると、ISは渡されたリードを後回しにし、MKTは「なぜ動かないのか」と不満を抱えます。定量的な基準がなければ、この認識のずれは永続します。

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

リードをMKTからISへ渡す際、「いつ・どの情報とともに・どのアクションを期待して渡すのか」が定義されていないと、ISは何から着手すべきか判断できません。CRMにコンタクトが登録されているだけで、何に反応したのか、どのページを見たのか、どの検討段階なのかが伝わっていなければ、ISは「また質の低いリードが来た」と結論します。

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

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

この3つはいずれも、次章以降で扱う4つの構造要素の欠落として説明できます。

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

連携の仕組み化は、MQL定義・ハンドオフ設計・SLA合意・レビュー設計の4要素を、この順番で積み上げることで完成します。順番を飛ばすと後工程が宙に浮きます。

4要素は並列ではなく直列です。MQLが定義されていなければ何をハンドオフするか決まらず、ハンドオフルールがなければSLAの「何を守るか」が定まりません。SLAの数値がなければ、レビューで確認すべき対象が存在しないことになります。

逆に言えば、1から順に設計すれば後工程は自然に決まります。連携改善に着手するとき、いきなり定例会議を設置しても機能しないのは、この順番を飛ばしているからです。マーケティングと営業全体の連携設計についてはマーケ・セールス連携の仕組み作りで全体像を整理していますので、フィールドセールスまで含めた設計を検討する場合はそちらもご参照ください。

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

MQL定義は「属性条件」と「行動条件」の2軸で組み立て、しきい値はISとの合議で仮決めして3か月後に実績で調整します。初回から正解を狙う必要はありません。

属性条件は、企業規模・業種・役職など、自社の理想顧客像に合致するかを評価する軸です。「従業員50名以上」「IT・SaaS業種」「課長職以上」といった条件に点数を割り当てます。行動条件は、資料ダウンロード・料金ページ閲覧・ウェビナー参加など、購買意図を示す行動を評価する軸です。

この2軸を合算し、一定のしきい値を超えたコンタクトをMQLとします。両者を分けて設計する理由は、「条件に合う企業だが今は動いていない」と「動いているが対象外の企業」を区別するためです。合算値だけを見ていると、この2つが同じスコアになり、ISの打ち手が決まりません。

加えて、競合ドメインからの問い合わせ、学生・研究目的の資料請求など、商談化しないことが明らかなコンタクトにはマイナス点を設定します。これがないと、ISの体感的な品質評価が実際の数値と乖離します。

スコア設計の具体的な考え方、SQLへの引き上げ基準、スコア減衰の扱いについてはMQL・SQLの定義と設計方法で詳しく扱っています。HubSpotでの実装手順はHubSpotリードスコアリングの設定方法を参照してください。

そして、スコアリングのルール以上に重要なのが「なぜその基準にしたか」の記録です。担当者の交代時や基準の見直し時に、設計意図が残っていないと議論が振り出しに戻ります。ICPの整理から始める場合はBtoBのICP設定方法が出発点になります。

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

ハンドオフの設計とは、ISが受け取った瞬間に次の一手を判断できる情報セットを標準化することです。ここを省略すると、MQL定義がどれだけ精緻でも放置が発生します。

引き渡す情報の標準セット

ISが受け取った直後にアクションを決められるよう、以下をCRM上で構造化して渡します。

• コンタクト基本情報（社名・氏名・役職・連絡先）
• MQLになった理由（スコアの内訳と直近の行動履歴）
• 過去の接触履歴（開封したメール、閲覧ページと回数）
• 検討段階の推定（情報収集段階か、比較検討段階か）
• 推奨する初回アプローチ手段と、切り出し方の骨子

最後の項目は省略されがちですが、ISの立ち上がり速度に最も効きます。「料金ページを2回閲覧しているので、導入規模の確認から入る」といった一文があるかどうかで、初回接触の質が変わります。

通知方法を1つに統一する

CRMのタスク通知、Slackの専用チャンネルへの自動投稿、メール通知。どれを使うかを事前に1つに決めます。複数併用は「どこかで見たはず」という状態を生み、結果として見落としが増えます。

差し戻しのルールもセットで設計する

前章で触れた差し戻し条件を、ここで運用ルールに落とし込みます。条件を満たしたリードは自動的にMKTのナーチャリング対象へ戻る、というワークフローまで作って初めて仕組みになります。手動運用にすると、忙しい時期に必ず滞留します。

HubSpotを使っている場合の具体的な自動化設計はHubSpotワークフロー設計、IS側の操作環境の整備はHubSpot Sales Hubの使い方で扱っています。

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

SLAはIS側だけに課すものではありません。MKT側の供給数と品質基準を対称に定めることが、合意が受け入れられる条件です。

SLA（Service Level Agreement）とは、両部門が果たすべき義務を数値で合意した取り決めです。「できる限り早く対応する」という表現のままでは、達成・未達成の判定ができず、レビューが感想の交換になります。

数値はあくまで設計例です。自社の現状実績を確認し、それより少しだけ高い水準から始めてください。理想値をいきなり設定すると初月で未達となり、SLA自体が形骸化します。

対称性が重要なのは、心理的な理由からです。「ISは24時間以内に接触する」だけを決めてMKT側に何も課さない設計は、ISから見れば一方的な義務の追加です。MKT側が先に供給数と品質基準をコミットして提示する順番にすると、合意形成がはるかに進みます。

3か月ごとに見直し、達成率が安定したら水準を引き上げる。このサイクルを最初から予定として組み込んでおくことで、「一度決めたら変えられない」という警戒感を減らせます。SLAの数値設計や現状実績の棚卸しに外部の視点が必要であれば、設計内容をご相談ください。

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

レビューは30分・固定アジェンダで運用します。数字の読み上げに時間を使わせないため、ダッシュボードの事前整備が前提条件になります。

アジェンダを固定する

週次のIS×MKTミーティングは、以下の3ブロックで構成します。

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

2番目のブロックが、この会議の中核です。「料金ページ閲覧者は比較検討段階が明確で商談になりやすい」「ウェビナー参加者は情報収集段階が多く即時の商談化は難しい」といった具体的な観察がISから出ることで、MKTはスコアリング調整の材料を得ます。抽象的な「質が低い」という評価では、改善のしようがありません。

ダッシュボードを事前に用意する

毎週手作業でKPIを集計していると、会議の大半が数字合わせに消えます。MQL数・商談化率・SLA達成率が自動更新される画面を先に作り、会議では原因分析とアクション合意だけに時間を使う設計にしてください。構成の考え方はBtoBマーケKPIダッシュボードの作り方で扱っています。

チャネルごとの商談化への寄与を見たい段階になったら、BtoBアトリビューション分析の観点を加えると、MQL定義の見直しがより精度の高いものになります。

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

仕組みを設計しても、運用フェーズで陥る落とし穴があります。頻度の高い4つを、対処法とあわせて整理します。

失敗1：MQLのしきい値を高くしすぎてISの稼働が空く

品質を重視するあまりしきい値を上げすぎると、ISに渡る件数が激減します。「月間MQL数が目標の半分を下回ったらしきい値を10点下げる」といった調整ルールを事前に決めておくと、その場の交渉なしで運用できます。

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

モニタリングの仕組みがなければSLAは形骸化します。達成率を週次レビューの必須項目に組み込み、未達の場合は理由を必ず議題にします。「今週は忙しかった」で終わらせないルールを明文化しておくことが必要です。

失敗3：レビューがKPI報告会になる

「先週のMQLは何件でした」を読み上げるだけの会は、レビューではなく報告です。アジェンダに「原因分析」と「次週アクションの担当者名」を必ず含めることで、改善の場として機能させます。数字を読み上げる時間が長いと感じたら、ダッシュボード整備が不足しているサインです。

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

優秀な担当者だけがCRMにフィードバックを丁寧に入力し、他は最低限しか入力しない、という状態はよく起こります。CRMの必須入力フィールドを設定し、入力が完了していないとリードが次の段階に進めない設計にすることで、属人性を下げられます。データ品質の維持についてはHubSpotのデータクレンジングもあわせて参考にしてください。

なお、ナーチャリング側の失敗パターンはリードナーチャリングが失敗する理由で別途整理しています。連携の問題に見えて、実際にはリードの育成設計に原因があるケースも少なくありません。

組織規模別の適用方針

4要素すべてを最初から実装する必要はありません。規模によって、どこまでを文書化しどこを口頭運用に留めるかの最適解が変わります。

少人数フェーズ（IS・MKT各1〜2名）

この規模では、正式なSLAドキュメントよりも「週15分のチェックインでMQL状況を確認し、決めたことを共有ドキュメントに記録する」運用で十分に機能します。優先すべきは次の2点です。

• MQL定義の簡易版（スコアリングなし、属性条件2〜3項目のみ）で合意する
• ハンドオフ時のCRM記録フォーマットを統一する

この段階でスコアリングの精緻化に着手すると、母数が足りず検証ができないまま工数だけを消費します。そもそもISを置くべきかを含めて検討している段階であれば、SDRとBDRの違いから役割の切り分けを整理するのが先です。

成長フェーズ（IS5〜20名、MKT3〜10名）

この規模になると、スコアリングの本格実装、SLAの数値合意、週次レビューの制度化、ワークフローによる自動化がいずれも投資対効果に見合うようになります。担当者が複数いるため、口頭合意では認識が揃わなくなるからです。

同時に、商談化率そのものの改善が経営課題として浮上します。連携の仕組みが整った後の打ち手はBtoBの商談化率を上げる方法で扱っています。ファネル全体の設計を見直す場合はBtoBファネル設計が起点になります。

どの規模であっても、現状の連携がどの段階で詰まっているかを外部の目で診断することは有効です。自社の連携体制についてご相談いただけます。

これから初めて設置する場合は、必要なリード数の判定から入ります。手順はインサイドセールスの立ち上げ方にまとめています。

まとめ

インサイドセールスとマーケティングの連携不全は、担当者の努力不足ではなく、違いの言語化と役割分担の設計が欠けていることから生じます。この記事で扱った要点は以下のとおりです。

• MKTは市場と母集団に、ISは特定された個人に向き合う。KPIと時間軸が構造的にずれるため、対立は必然として設計に織り込む
• 役割が曖昧になるのは「MQL判定」と「初回接触後の見極め」の2工程。ここだけを文書で固定すれば摩擦の大半が消える
• 仕組み化は、MQL定義 → ハンドオフ設計 → SLA合意 → 週次レビューの順で積み上げる。順番を飛ばすと後工程が機能しない
• SLAはMKT側とIS側で対称に設計し、守れる水準から始めて3か月ごとに見直す
• 組織規模によって文書化すべき範囲は変わる。少人数フェーズでスコアリングを精緻化しても検証ができない

連携の設計は一度作って終わるものではなく、リード量・商品・組織が変わるたびに見直す対象です。まずは「今の役割分担を1ページに書き出し、IS側と読み合わせる」ところから始めることが、最も現実的な第一歩になります。

よくある質問（FAQ）

インサイドセールスとマーケティングの違いは何ですか？

向き合う相手の粒度と時間軸が異なります。マーケティングは未特定の市場と獲得済みリードの母集団を対象に、1対多の手段で中長期の成果を積み上げます。インサイドセールスは名前と所属が特定された個別の見込み顧客を対象に、1対1の接触で当月から翌月のパイプラインを作ります。担当する業務範囲の違いではなく、この構造の違いが両者を分けています。

マーケティングとインサイドセールスの役割分担はどう決めればよいですか？

全工程を細かく分ける必要はありません。責任が曖昧になるのは「MQL判定を誰が最終決定するか」と「接触後に見込みなしと判断したリードをどちらが持つか」の2点に集中します。判定基準は両者で合議し実行は自動化する、差し戻しは条件と戻し先をセットで定義する。この2点を1ページに書いて責任者が合意すれば、実務上の摩擦の大半は解消します。

MQLのしきい値はどう決めればよいですか？

初期設定に正解はありません。まず「IS担当者全員が直感的に追いかけたいと感じるリード」の属性と行動を洗い出し、それを点数化した合計を仮のしきい値とします。運用開始から3か月後に商談化率を確認し、質が粗ければ引き上げ、供給数が不足していれば引き下げる、というサイクルで調整してください。初回から精緻な設計を目指すと、検証データが揃う前に工数を使い切ります。

CRMやMAツールを導入していなくても仕組み化できますか？

可能です。スプレッドシートでのリード管理とチャットツールへの通知を組み合わせれば、ハンドオフ情報の共有と通知は実現できます。ただし月間のリード数が100件を超えたあたりから手動管理の限界が来るため、そのタイミングでツール導入を検討することを推奨します。ツール選定の観点はMAツール比較で整理しています。

SLAを設定しようとするとインサイドセールス側から抵抗があります。どう進めればよいですか？

抵抗の多くは「質の低いリードを大量に渡されるのに、追いかける義務だけを負わされる」という不信感に由来します。IS側のSLAを提示する前に、マーケティング側のSLA（MQL品質基準と月間供給数のコミット）を先に提示してください。マーケティング側も同じ形式で義務を負うことが可視化されると、合意形成の速度が大きく変わります。