MQL営業RevOps

MQLの引き継ぎ設計|マーケと営業が揉めない基準づくり

2026年07月19日 ・ Stride

営業会議で、最近のリードは質が悪い、という話が出る。同じ週のマーケティング月次では、MQLの目標を達成しましたと報告されている。

同じ会社の、同じ月の話です。それなのに噛み合わない。

心当たりはありませんか。この食い違いは、どちらかが嘘をついているから起きるのではありません。

引き継ぎの基準が、言葉でしか共有されていないから起きます。

言葉は、読む人の頭の中で好きな形になります。だから毎月ずれる。

この記事では、行動データでMQLを定義し、引き継ぎの約束を双方向で決め、渡したあとまで追跡する。その一連の設計を、明日から手をつけられる順番で整理します。

MQLとは何で、なぜ毎月揉めるのか

用語を先に揃えておきます。GTMはGo To Marketの略で、作った製品を売れる状態にして顧客に届けるまでの活動全体を指します。

マーケティング、営業、カスタマーサクセスをひとまとめにした言い方だと思ってください。

RevOpsは、そのGTM全体を一つの数字と一つの業務フローでつなぐ役割です。部門ごとに最適化された仕組みを、収益という共通のゴールで並べ直す仕事、と言い換えてもいい。

そしてこの記事の主題であるMQLは、Marketing Qualified Leadの略です。マーケティング側が、営業に渡してよいと判断したリードのこと。

渡した先で営業が有望だと認めると、SQL(Sales Qualified Lead)に変わります。MQLからSQLへ移すこの受け渡しが、引き継ぎです。

言葉にすると単純ですよね。実務で揉めるのは、渡してよいという線引きが、人によって別のものを指しているからです。

検討度が高い、という言葉は共有できない

マーケ側が言う検討度が高いリードは、資料をダウンロードして、メールを開いて、料金ページを見た人かもしれません。

営業側が言う検討度が高いリードは、予算の話ができて、導入時期が今期中で、決裁に関われる人です。

どちらも間違っていません。ただ、同じ言葉で違う対象を指しているだけ。

この状態で件数の目標だけが設定されると、片方は数を作りに行き、もう片方は数の中身に不満を持ちます。構造上、揉めるようにできています。

揉めごとの正体は、不信ではなく未定義

多くの現場で、この対立は人間関係の問題として扱われがちです。連携が悪い、相互理解が足りない、といった言い方になる。

でも、飲み会を増やしても解決しません。定義がないという事実は、仲良くなっても変わらないからです。

定義がないまま件数だけを追うと、マーケは達成、営業は不満という報告が毎月そろって出てきます。どちらの報告も、その部門の中では正しい。

同じ指標なのに部門ごとに数字が違ってしまう問題は、KPI定義のすり合わせ|同じ指標なのに数字が食い違う理由でも扱っています。引き継ぎの揉めごとは、その特殊なケースだと考えるとわかりやすいはずです。

まずやるべきは、感情の調整ではありません。言葉を条件式に置き換えることです。

MQLは属性と行動の掛け算で定義する

条件式にすると言っても、いきなり複雑なスコアリングを作る必要はありません。最初は、属性条件と行動条件の2つに分けるだけで十分に効きます。

属性条件は、その会社や担当者が誰であるかという静的な情報です。業種、従業員規模、役職、地域など。

行動条件は、その人が実際に何をしたかという記録です。特定ページの閲覧、資料請求、価格表の再訪、問い合わせフォームの送信など。

属性だけで絞ると、ターゲット企業だけれど今は検討していない人がたくさん混ざります。行動だけで絞ると、熱心に読んでいるけれど自社の顧客になりえない人が混ざる。

だから掛け算にします。定義書は、たとえばこんな形で1枚に書き出せます。

[MQL定義 v1.2]  2026-07-01 施行 / 次回見直し 2026-10-01

■ 必須(属性)※すべて満たすこと
  - 従業員数 50名以上
  - 対象業種(SaaS / EC / 人材)のいずれか
  - 個人フリーアドレスではない

■ 必須(行動)※いずれか1つ
  - 問い合わせフォーム送信
  - 料金ページを7日以内に2回以上閲覧

■ 加点(合計6点以上でMQL)
  +3  料金ページ閲覧(7日以内)
  +2  導入事例ページ閲覧
  +2  再訪(別日のセッション)
  +1  ブログ3記事以上の閲覧
  -3  採用ページのみ閲覧して離脱
  -5  競合ドメインからのアクセス

■ 除外
  - 学生 / 個人利用の申告あり
  - 過去90日以内に営業が失注(理由:予算なし)

大事なのは、点数の細かさではありません。誰が読んでも同じ判定になることです。

営業に、この定義で渡ってくるなら受けますね、と聞いて、はいと言われたら合格。言葉を濁されたら、まだ条件が足りていません。

それから、定義書には施行日と次回見直し日を必ず入れておきます。期限が書かれていない定義は、誰も直さないまま静かに古びていくからです。

しきい値は、過去の受注から逆算する

加点の配点をどう決めるかで手が止まりがちです。ここは感覚ではなく、過去の実績から逆算するのが早い。

直近半年の受注顧客を20〜30社ぶんリストにして、商談化する前に何をしていたかを一件ずつ見ていきます。共通する行動が、そのまま加点候補です。

たとえば受注顧客の多くが、初回訪問から商談化までに料金ページを平均3回見ていた。一方で失注した層は平均1回だった。

そういう差が見えたら、料金ページの再訪は強い信号だと判断できます。

ただし20〜30社の観察で統計的な差を証明することはできません。ここで欲しいのは証明ではなく、営業と一緒に検討できる仮説のほうです。

これはあくまで仮の数字ですが、やり方は同じです。行動の重みづけをもう少し踏み込んで設計する話は、行動データで精度を上げるリードスコアリングにまとめています。

ここで一点、正確に線を引いておきます。ウェブ解析ツールで見えるのは、サイト上の匿名の行動までです。

匿名の行動を個人や企業に紐づけて管理するのは、CRMやMAツールの仕事。Strideのようなプライバシーファーストの解析ツールは、行動という材料を正しく測る層であって、リードそのものを管理する層ではありません。

役割を混ぜないほうが、設計はすっきりします。

引き継ぎは、双方向の約束にする

定義ができたら、次は運用の約束です。ここで多いつまずきが、マーケ側の条件だけを決めて終わってしまうこと。

それだと、渡したあとに何が起きたかわからない状態が続きます。片側だけの約束は、約束とは呼べません。

引き継ぎは、両部門が同じ紙に署名する形にします。目安は次のような内容です。

項目 マーケの約束 営業の約束
引き渡し 定義を満たしたら即時通知 営業時間内15分以内に一次接触
対応 直近の閲覧履歴を添付 3営業日で3回までアプローチ
判定 月次で定義を見直す 5営業日以内にSQL可否を返す
差し戻し 24時間以内に再ナーチャへ 理由コードを必ず付ける

数字は自社の商材に合わせて変えてください。重要なのは、双方に締め切りがあることです。

通知の届け方も、あわせて決めておきます。CRMに行が増えるだけでは気づかれないので、担当者が普段開いている画面に流れてくる形にします。

初回接触までの時間は、それ自体が成果を左右します。理由と縮め方はスピード・トゥ・リード|初回接触までの時間を縮めるで詳しく扱っています。

差し戻しの理由コードが、いちばん効く

引き継ぎ設計で意外と効くのが、差し戻しの仕組みです。営業が受けられないと判断したとき、理由を選択式で返してもらう。

自由記述にすると書かれません。選択肢は5つ前後に絞ります。

理由コードは、たとえばこう置きます。予算なし、時期尚早、決裁権なし、対象外、連絡不通。

これが月に何十件も溜まると、定義のどこが甘いのかが数字で見えてきます。

時期尚早が半分を占めるなら、行動条件が弱すぎる。決裁権なしが多いなら、属性条件に役職が抜けています。

理由コードは犯人探しの道具ではありません。定義を直すための材料です。

その前提を最初に宣言しておかないと、営業側が差し戻しをためらうようになります。返しやすい空気をつくるところまでが設計です。

渡したあとを追跡しないと、基準は永久に直らない

MQLの件数だけを追っていると、質の議論は水掛け論のままです。追うべきは、MQLがその後どうなったかという通過率。

具体的には、MQLから商談化した割合と、そこから受注した割合を、流入元や条件ごとに分けて見ます。分けないと、平均が全部を隠してしまいます。

実在のデータではありませんが、仮に今月のMQLが200件あったとして計算してみましょう。獲得元で3つに分けると、次のような姿になったとします。

獲得元 MQL数 商談化率 受注率(対MQL)
資料DL広告 120件 15.0% 1.7%
オーガニック検索 50件 40.0% 12.0%
問い合わせ 30件 70.0% 30.0%
合計 200件 29.5% 8.5%

全体で見れば商談化29.5%、受注8.5%。数字だけ眺めれば、悪くないという感想で終わります。

ところが件数の6割を占める広告経由を取り出すと、商談化は15.0%まで落ちます。受注に至っては120件から2件で、全体17件のうちの1割強でしかありません。

つまり、この月に営業が準備した59件の商談のうち、かなりの部分がほとんど受注につながらない経路に消えていたことになる。分解して初めて、件数の6割が受注の1割しか生んでいないという構図が見えてきます。

この状態でMQL件数の目標だけを上げると、何が起きるか。想像がつきますよね。

見るときの注意点も一つ。商談化にも受注にも時間がかかるので、今月のMQLと今月の受注を並べても対応していません。

MQLが発生した月ごとに束ねて、その集団が3か月後にどうなったかを追いかけます。手間は増えますが、これをやらないと施策の評価がまるごと数か月ずれます。

目標は件数から通過率へ移していく

追跡が回り始めたら、マーケ側の評価指標を少しずつ動かします。MQL件数だけを目標にしていると、質の悪い数を作るほうが合理的になってしまうからです。

移し先は、商談化したMQLの数、あるいはMQL経由の受注金額。営業と同じ方向を向く数字にします。

一気に全部を置き換える必要はありません。件数と通過率を併記し、四半期ごとに重みを移していくくらいがちょうどいい。

そして、なぜその行動が信号として効くのかが腑に落ちないときは、集計から一度離れます。実際に受注した一社の訪問履歴を最初から最後まで読むと、条件式を眺めていても出てこない発見があるものです。

一人の行動を時系列で読む進め方は、N1分析とは|一人の行動から改善のヒントを得るに整理しています。

Strideは匿名の訪問者の行動履歴をセッションをまたいで時系列で追えるので、問い合わせに至った人がその前にどのページをどの順番で見ていたかをさかのぼれます。ただし見えるのはあくまで匿名の行動までで、それが誰でどの会社なのかはCRM側の情報と突き合わせて解釈する必要があります。

AIを入れるなら、判断手順を先に紙に書く

引き継ぎの運用は、通知、確認、記録、差し戻しといった定型作業の連続です。だからAIエージェントを入れたくなる領域でもあります。

ただ、順番を間違えると効果は出ません。ツールを足すのが先ではないからです。

まず、人間のトップパフォーマーの判断手順を明文化する。ベテラン営業が、渡ってきたリードのどこを見て、何を根拠に優先順位を決めているのかを聞き出します。

それを箇条書きで書き出すところが出発点です。

書き出せない判断は、エージェントにも写せません。逆に言えば、書き出す作業そのものが引き継ぎ設計の質を上げます。

そのうえで、AIをチャット画面の中に閉じ込めず、CRMやチャットツール、データ基盤をまたぐイベント駆動の処理として組みます。新しいMQLが立ったら、直近の行動履歴を要約して担当者のチャットに流す、といった形です。

人間の承認を残す場所を決める

全部を自動にすると、どこで間違えたのかがわからなくなります。承認を残す場所は、先に決めておきます。

判断基準はシンプルで、間違えたときに取り返しがつくかどうか。取り返しがつかない側には、必ず人を挟みます。

工程 自動化の可否 理由
行動データの集約と要約 自動でよい 間違えても読み直せる
MQL判定と通知 自動でよい 差し戻しで戻せる
顧客への初回メール送信 人間が承認 取り消せない
定義そのものの変更 人間が決定 全件に影響する

導入するときは、いきなり本番に出しません。しばらくはシャドーモード、つまりAIの判定を記録するだけで実際の運用には反映しない期間を置きます。

その間、人間の判定とどれだけ一致したかを数えます。ずれた事例を10件も読めば、条件の抜けが見つかります。

評価するのは、AIの出力がもっともらしいかどうかではありません。MQLから商談化した率が上がったかという、最初に決めた通過率で測ります。

もう一つ、AIの使いどころとして地味に効くのが分析そのものの依頼です。StrideはMCPに対応していて、Claudeのような対話型AIから、先月の問い合わせ経由のユーザーが直前に見ていたページを教えて、といった質問を自然言語で投げられます。

毎回ダッシュボードを触らなくても、定義の見直し会議の場で疑問をその場で潰せる。細かいことですが、見直しが続くかどうかを分けるのはこの手の摩擦です。

最初の30日で、どこから手をつけるか

全部を同時に始めると、たいてい途中で止まります。高頻度で、繰り返し起きて、遅れるほど損をする業務から順に入れるのが定石です。

引き継ぎで言えば、その条件に当てはまるのは差し戻しの記録と初回接触の速度。この2つが最初です。

差し戻しの記録は、翌月の見直しで使う材料そのものになります。初回接触の速度のほうは、定義を変えなくても今週から縮められる数少ないレバーです。

順番はこう置きます。

  1. 最初の1週間で、営業と2時間の会議を1回。渡してよい条件を口頭で挙げてもらい、その場で条件式に書き換える
  2. 2週目に、差し戻しの理由コード5つを決めて運用を開始する。この時点で定義が完璧である必要はない
  3. 3週目に、MQLから商談化までの通過率を獲得元別に出せる状態にする
  4. 4週目に、初回接触までの時間を計測し、遅れている経路を1つだけ直す

1か月では成果は出ません。出るのは、翌月から議論の土台になる数字です。

そこから先は、月に一度の見直し会議で定義を更新していくだけ。定義書にバージョン番号と次回見直し日を書いておいたのは、このためです。

つまずきやすい3つの落とし穴

最後に、実際によく見かける失敗を挙げておきます。どれも、真面目にやっているチームほど踏みやすいものです。

  • 定義を完璧にしてから運用しようとして、半年たっても始まらない
  • スコアの項目を20個以上に増やし、誰も理由を説明できなくなる
  • 差し戻しの理由コードを集めたのに、定義の見直しに使わないまま放置する

3つ目がいちばんもったいない。データは溜まっているのに、決める場がないだけで止まります。

引き継ぎ設計の本質は、賢い基準を作ることではありません。基準を毎月直せる状態を作ることです。

言葉で共有していたものを条件式にして、渡したあとを追いかけて、月に一度直す。それだけで、リードの質という言葉は、感情の話から数字の話に変わっていきます。

Strideで、あなたのサイトの導線を可視化しませんか?

Cookieレスで、離脱ポイントとコンバージョンが数分でわかります。

無料で始める