RevOps設計でMQLを商談につなぐ連携の手順
マーケ・営業・カスタマーサクセスを共有データと統一プロセスでつなぐRevOpsの考え方を、MQLの定義、引き継ぎ情報、SLA、レビュー運用の観点から手順と判断基準に整理します。
公開 2026年10月1日
結論：ツール統合の前に「引き継ぐ情報の型」を決める
RevOpsの出発点は、ツールの統合ではなく引き継ぐ情報の型を決めることです。MQLが商談にならない原因の多くは、リード数ではなく、営業が受け取る情報の粒度と手順が揃っていないことにあります。共有データ・統一プロセス・共通KPIの3点を先に文書化し、そのうえでCRMや自動化の設定を合わせる順序が実務的です。
この記事では、MQL定義の合わせ方、引き継ぎ項目の標準化、SLAの置き方、レビューの回し方を手順として整理します。明日から自社のCRM設定と会議体に落とせる粒度で書きます。
※本記事は2026年10月時点の情報をもとに作成しています。
RevOps（収益運用）とは
RevOps（収益運用）とは、マーケティング・営業・カスタマーサクセスが共有データと統一プロセスで動くための運用設計の考え方です。CRMを中心に、データ品質管理、自動化、予測、営業エンゲージメント、見積から請求までの流れを同じ基準でつなぎます。
重要なのは、RevOpsが「部門をまたぐ業務の取り決め」であり、特定の製品カテゴリの名称ではない点です。ツールはその取り決めを再現する手段にすぎません。
マーケティング部長の立場では、RevOpsは次の3つに具体化されます。
- 定義の統一：MQL・SQL・商談の線引きを文書で合わせる
- 受け渡しの標準化：営業に渡す情報の項目と形式を固定する
- 計測の統一：同じ指標を同じ分母で見る
用語の整理は MQLと営業の引き継ぎSLA もあわせて確認してください。
設計の第1層：共有データの定義を揃える
最初に揃えるのは、リード・コンタクト・アカウント・商談の4オブジェクトの関係です。ここが曖昧なまま自動化を足すと、同じ企業が別レコードで増え、分母が部門ごとにずれます。
判断の目安を表にします。
| 論点 | 揃っている状態 | 崩れている兆候 |
|---|---|---|
| 名寄せ | 企業ドメイン基準で統合されている | 同一社名が表記違いで複数存在する |
| 所有者 | 各レコードに責任者が1人設定されている | 未割当のまま滞留するレコードがある |
| ステージ | 遷移条件が文章で定義されている | 担当者の感覚でステージが前後する |
| 発生源 | 初回接点と直近接点を分けて保持 | 最新の流入元で上書きされる |
データ品質は自動化の前提条件です。品質ルールを決めずに通知やスコアリングを足すと、誤った対象に処理が走ります。
設計の第2層：MQLの定義と引き継ぎ項目
MQLは「スコアの合計点」ではなく「営業が次の行動を決められる状態」として定義します。点数だけで渡すと、営業側は背景を再取得する必要が生まれ、着手が遅れます。
引き継ぎ時に最低限そろえる項目を整理します。
| 区分 | 項目 | 形式の例 |
|---|---|---|
| 企業属性 | 業種・従業員規模・既存システム | 選択式 |
| 役割 | 役職・検討での立場 | 選択式 |
| 課題 | 解決したい業務上の論点 | 自由記述（本人の言葉） |
| 時期 | 検討・導入の想定時期 | 選択式 |
| 文脈 | 閲覧資料・質問内容・回答済みの論点 | 要約テキスト |
「文脈」の欄があるかどうかで、営業の初回接触の設計が変わります。何をすでに説明済みかが分かれば、同じ説明の繰り返しを避けられます。
項目は増やしすぎないことが原則です。入力されない欄は品質を下げるため、埋まらない項目は四半期ごとに削ります。
設計の第3層：SLAとレビューの運用
SLAは「何時間以内に何をするか」と「満たせなかった場合にどう戻すか」をセットで書きます。片方だけでは形骸化します。
以下は運用の雛形です。数値は自社の体制に合わせて設定してください。
| 取り決め | 内容 | 不履行時の扱い |
|---|---|---|
| 初回接触 | 引き継ぎから一定時間内に着手 | 未着手ならプール戻し |
| 受領判定 | 定義外なら理由コードを付けて差し戻し | 理由コードを毎月集計 |
| ステージ更新 | 接触後に必ず結果を記録 | 未記録は商談数に含めない |
| レビュー | 月次で差し戻し理由を共有 | 定義文の改訂で対応 |
レビューで見るのは個別案件ではなく、差し戻し理由の分布です。理由が「情報不足」に偏るなら引き継ぎ項目の問題、「時期尚早」に偏るならMQL定義の問題と切り分けられます。
指標の見方は CPLとROIの考え方 も参考になります。
よくある失敗のパターン
失敗は仕組みではなく順序に起因することが大半です。代表的な型を挙げます。
ツール統合から着手する 定義を決めずに連携だけ組むと、ずれた定義が自動で増幅されます。先に定義文を1ページにまとめます。
スコアだけで渡す 点数は営業にとって行動の根拠になりません。課題の記述と検討時期を必ず添えます。
差し戻しの受け皿がない 差し戻されたリードが宙に浮き、再接触されません。戻し先のキューと再育成の条件を決めます。
イベント後のフォローが滞る 展示会やウェビナーは件数が一度に増え、手作業では順番待ちが発生します。対応の優先順位を事前に決めておきます。詳しくは ウェビナー後72時間の設計 を参照してください。
定義を改訂しない 製品や市場が変われば定義も変わります。改訂の時期を決め、改訂履歴を残します。
この進め方が向いていないケース
RevOps的な標準化が適さない状況もあります。無理に導入すると運用負荷だけが残ります。
- 月間の商談数が少なく、全件を営業が目視で確認できる段階
- 製品が検証段階で、ターゲットと提供価値が頻繁に変わる
- 営業組織が単一担当で、引き継ぎという工程自体が存在しない
- CRMが実質的に運用されておらず、記録が個人のファイルに分散している
最後の条件に当てはまる場合は、標準化より先にCRMへの記録を定着させる段階です。記録がない状態で定義を増やしても、守られない取り決めが積み上がります。
また、商流が代理店中心で自社が最終顧客と接点を持たない場合も、この手順はそのままでは適用しにくい構造です。
よくある質問
MQLの定義は誰が決めるべきですか。
マーケティングと営業の合議で決め、文書として残します。片方が決めた定義は運用で守られにくくなります。四半期ごとの見直しを前提に、暫定版から始めて構いません。
スコアリングは不要ということですか。
不要ではなく、単独で判断材料にしないという整理です。スコアは優先順位づけに使い、引き継ぎ時には課題・時期・役割の記述を併記します。
ツールは何から入れるべきですか。
定義と手順を文書化したあと、まずCRMのステージとレコード構造を合わせます。自動化や通知はその後です。順序を逆にすると設定のやり直しが発生します。
カスタマーサクセスまで含める必要はありますか。
既存顧客からの拡販や解約予兆を扱うなら含めます。扱わない段階であれば、まずマーケティングと営業の2部門で設計し、後から拡張する形でも成立します。
差し戻しが多いときはどこを直しますか。
理由コードの分布を見ます。情報不足が多ければ引き継ぎ項目、時期尚早が多ければMQLの閾値、対象外が多ければターゲット定義を見直します。
まとめ
RevOpsは、部門をまたぐ取り決めを先に決め、それをツールで再現する順序の設計です。共有データの定義、MQLと引き継ぎ項目の標準化、SLAとレビューの運用という3層で考えると、着手点が明確になります。
差し戻し理由の集計は、定義が現実に合っているかを確認する手がかりになります。月次で分布を見て、定義文を改訂していく運用を続けてください。
UniAgentは、Webサイト上で登録資料を根拠に説明とヒアリングを行い、その文脈を担当者へ引き継ぐAIです。関連する整理は ナレッジ記事一覧 にまとめています。