▼ この記事の内容
SaaSの営業マーケ連携では、リードを渡す基準、受領後の担当、営業から戻す情報、会議で変える項目を分けて決めます。リード数だけではなく、工程ごとの記録を確認すると、次の会議で合意すべき条件を選べます。
営業とマーケティングの間で認識が分かれる場面は、獲得したリードを誰が受け取り、いつ何を確認し、どの状態になったら次へ進めるかが曖昧なときに生じます。本記事では、特定ツールの導入効果や一律の数値目標ではなく、営業マネージャーが連携会議で決められる運用条件を整理します。
SaaSの営業・マーケ連携で最初にそろえる範囲
営業とマーケティングで使う「引き渡し合意表」は、判定条件、受領後の担当、営業から返す情報、会議で変更する項目をまとめる表です。部門ごとの評価やツール設定を先に議論せず、次の確認項目を自社の運用に合わせて埋めます。
| 確認項目 | 会議で合意する内容 | 判断が分かれたときに残すこと |
|---|---|---|
| 判定条件 | 営業へ渡す情報と、商談へ進める条件 | 不足している情報と追加確認の方法 |
| 受領後の担当 | 受け取る人、初回対応の期限、記録先 | 担当不在時の引き継ぎ先 |
| 営業からの返却 | 対象外・保留などの理由と戻す相手 | 顧客の反応と判断に使った事実 |
| 次の変更 | 見直す条件、確認する担当、次回の確認日 | 変更する理由と、比較する対象期間 |
工程ごとの判定条件と担当を定める
リードを渡す工程ごとに、「どの情報があれば渡せるか」「誰が受け取るか」「受領後に何を記録するか」を文章で決めます。用語だけを共有しても、判定者と確認項目が決まらなければ、担当者ごとに判断が変わります。
たとえば、対象の企業・担当者・接点の内容・把握済みの課題のうち、受領時に必要な項目と不足時の扱いを分けます。商材、購買プロセス、営業体制によって条件は異なるため、現場で判断が割れた事例を会議で見直す前提にします。
責任論ではなく工程の事実を確認する
連携不全を部門間の責任問題にする前に、リードの受領、初回対応、商談判断、結果の返却のどこで認識が分かれたかを確認します。工程ごとの事実を分けると、次に見直す条件と担当を選べます。
MQLとSQLの引き渡し条件を定める
MQLとSQLは、営業へ渡す判断と、営業が商談として進める判断を混同しないための区切りです。名称を採用するかどうかより、各状態で確認する情報、判断者、記録先を合意対象にします。
MQLは営業が受領後に確認する情報で定める
Zoho CRM Academyの営業・マーケティング連携に関する解説では、MQLを営業へ渡す基準、SQLを営業が商談に進めると判断した基準として説明しています。自社では、営業が受領後に確認する情報からMQLの条件を決めます。
会社規模や役職のような属性だけでなく、課題、検討状況、接点の内容などから、営業が優先順位を付けるために必要な情報を選びます。すべてを必須にせず、情報不足ならマーケティングへ戻すのか、補足確認を依頼するのかも決めます。
参考：マーケティングと営業の連携を強化する方法｜Zoho CRM Academy（連携設計に関する一般解説）
SQLと受領状況を分けて記録する
SQLは、営業がヒアリングなどを通じて商談として進めるか判断した状態として置けます。組織内でSALを置く場合も、営業が受領しただけの状態なのか、商談判断まで済んだ状態なのかを別の記録にします。
初回対応の期限を決めるなら、期限内に対応できたかだけでなく、受領、保留、対象外のいずれだったかを残します。担当不在や情報不足などの例外では、判断者、追加する情報、戻す工程を決めておくと、期限だけが独り歩きしません。
初回対応・返却・再判定の期限を合意する
営業とマーケティングのSLA（部門間の対応合意）には、初回対応、情報不足による返却、保留案件の再判定について、担当者と期限を記録します。期限は一律の日数にせず、顧客が希望する連絡時期、問い合わせの内容、営業時間、担当者の対応可能件数を照合して決めます。
期限を超えた案件は、受領担当が未対応の理由と次の対応予定を記録し、合意した責任者へ連絡します。情報不足なら追加確認する項目と返却先を示し、保留なら再判定日または顧客の検討再開などの確認条件を残します。担当不在時の代替担当も決め、次回の連携会議で期限内対応の件数と例外理由を確認します。
営業からのフィードバックを施策改善に生かす
営業から戻すべきなのは、商談にならなかったという結果だけではありません。次の施策で確認したい論点に絞り、どの対象・訴求・接触方法を見直すか判断できる記録にします。
理由を次の判断に生かせる粒度で分類する
営業は、対象外、情報不足、検討時期が合わない、課題との一致を確認できないといった理由を、あらかじめ決めた分類で返します。分類を細かくしすぎる前に、各項目を誰が読み、次に何を見直すのかを決めることが実施条件になります。
営業が顧客接点で得た反応や質問は、訴求・対象・接触方法のどれを見直すか選ぶ材料になります。反応を共有しただけで施策の成果が変わったとは判断できません。他の施策や案件条件も確認し、次回までに確かめる論点を一つ決めます。
共同レビューでは確認対象を一つに絞る
同じ理由が続く場合は、MQLの条件、施策で伝えた内容、営業の初回確認のどこに差があるかを見ます。一度にすべてを変更せず、次回までに確認する仮説と担当を一つ選び、判断に使った記録を残します。
連携会議で確認するKPIと次の変更を決める
会議では、リードの受領、商談への進行、案件の結果を同じ数字に混ぜず、工程ごとに確認します。数字の変化を結論にせず、次に検証する条件を決めるために使います。
数字と判断材料を結び付ける
たとえば受領数を見るなら、未受領や保留の理由も確認します。商談への進行を見るなら、どの条件で商談判断をしたか、対象・期間・集計方法が前回と同じかを確かめます。変化があっても、連携の変更だけが原因とは決めません。
工程別に指標を整理する際は、SaaS営業で見るべき指標の考え方も参照できます。自社の定義と照らし、各数値をどの判断に使うかを決めます。
営業AI・営業DX SaaS営業で見るべき指標｜4階層の分類と現場で動かす優先順位
次回までに検証する課題を一つ残す
会議では、すべての工程を一度に直すのではなく、次回までに検証する課題を一つ選びます。担当者、確認する記録、見直す条件を残すと、報告だけで終わりにくくなります。
SFA・MA・CRMは運用要件を定めてから見直す
SFA・MA・CRMの設定や製品を検討する前に、誰がどの状態を更新し、どの履歴を読んで次の行動を決めるかを確認します。ツールは、合意した運用を記録・共有できるかという要件から見直します。
必要な記録項目と更新責任を先に定める
確認する要件は、引き渡し時の情報、担当者、受領結果、初回対応、商談判断、非商談化理由、活動履歴です。それぞれについて、入力する担当、更新する時点、他部門が読む画面または記録先を定めます。
既存の仕組みで必要な状態や履歴を追えない場合に、項目、権限、連携方法、レポートのどこが不足しているかを切り分けます。製品ごとの機能や連携可否、設定手順は提供元の公開情報で個別に確認します。自社で必要な項目を使えるかを確かめてから設定を変更してください。
工程に沿って役割分担を確認する
引き渡し後の担当と確認順を見直す際は、SaaS営業組織で役割を分ける考え方も確認できます。自社の購買プロセスに合わせ、工程ごとの担当と未決定事項を整理します。
営業戦略・KPI設計 営業パイプライン管理とは？失敗しない5ステップとボトルネック分析の実践法
導入・連携・料金などを比較検討する段階では、導入前の確認事項を確認し、相談前に必要な論点を整理できます。個別の提供範囲、費用、設定条件は、必要な時点で確認する事項として扱います。
まとめ：連携を責任論ではなく改善手順に変える
引き渡し合意表にMQLとSQLの判断条件、受領後の担当、営業から返す理由、次に見直す項目をまとめると、会議で扱う課題を具体化できます。
まずは、判断が分かれた工程を一つ選び、必要な記録と担当を合意します。次回の会議では、その条件が使われたかを確認し、必要なら定義や運用を見直します。
