RevOpsを入れる前に揃えるべき営業データの最低ライン

この記事で整理すること

RevOpsを導入する前に最低限そろえるべき営業データを、ステージ定義、Lead Source、Owner、SQL/MQL、必須項目、会議運用に分けて整理します。ダッシュボードを作る前に、営業組織が同じ意味で使える項目と判断基準を持つことが目的です。

よくある現場の始まり方

経営会議で「営業データを見える化したい」と決まり、最初にダッシュボード作成が始まることがあります。しかし、元データを見ると、ステージの意味は担当者ごとに違い、Lead Sourceは自由入力で、Close予定日は過去日のまま残っている。これでは、きれいなグラフを作っても、営業責任者はどの案件に介入すべきか判断できません。

RevOps導入前の読者が最初に見るべきなのは、BI画面ではなく、営業会議で実際に使う項目です。会議で質問されない項目は入力されず、入力されない項目は分析できません。

編集部の見立て

RevOps導入で最初に失敗しやすいのは、ツールやダッシュボードを先に決めてしまうことです。営業現場で同じ意味で入力されていないデータは、BIに流しても判断材料にはなりません。最初に整えるべきなのは、分析基盤ではなく、会議で使う項目の定義、入力タイミング、レビュー責任です。

RevOps はダッシュボード作成担当ではない

RevOps という言葉が広がるにつれ、営業データを整えてダッシュボードを作る役割だと捉えられることがあります。しかし、本来の RevOps は単なるレポート作成ではありません。マーケティング、インサイドセールス、フィールドセールス、CS、経営管理をつなぎ、売上が再現性を持って生まれる状態を設計する役割です。

そのため、RevOps を入れる前に必要なのは高機能な BI ツールではなく、営業活動を記録するための最低限の共通言語です。どの状態をリードと呼ぶのか。どの条件を満たしたら商談と呼ぶのか。商談ステージは何を意味するのか。失注理由はどの粒度で記録するのか。これらが曖昧なまま RevOps を導入しても、見える化されるのは混乱だけです。

最初に揃えるべきはステージ定義

営業データの中で最も重要なのは、商談ステージの定義です。ステージは単なる進捗ラベルではありません。顧客の意思決定がどこまで進んでいるかを表すものです。にもかかわらず、多くの組織では「初回商談」「提案中」「見積提出」「クロージング」といった営業側の作業状態でステージを作っています。

営業側の作業状態だけでステージを管理すると、Forecast の精度が上がりません。提案書を出したからといって、顧客が導入に前向きとは限らないためです。重要なのは、顧客側で課題が明確になっているか、意思決定者が関与しているか、予算や時期が確認されているか、比較検討の基準が見えているかといった条件です。

ステージ定義には、進める条件と戻す条件を入れるべきです。たとえば「提案」ステージに進める条件は、顧客課題、導入目的、関係者、意思決定時期が確認されていること。逆に、これらが確認できていない案件は提案資料を作っていても前段階に残します。このルールがあるだけで、案件レビューの会話は大きく変わります。

Lead Source は後から直せない

次に重要なのは Lead Source です。どの施策から生まれた接点なのかが曖昧だと、マーケティング投資や営業優先順位を判断できません。展示会、ウェビナー、紹介、広告、自然検索、既存顧客からの拡張など、入口の情報は後から推測しにくいデータです。

Lead Source でよくある失敗は、営業担当が商談化したタイミングで自由入力してしまうことです。自由入力では表記ゆれが起きます。「ウェビナー」「Webinar」「セミナー」「イベント」が別々の値として残り、集計時に手作業で直すことになります。RevOps を入れる前に、入力値は選択式にし、誰がどのタイミングで設定するかを決めるべきです。

また、初回接点と商談化のきっかけを分けることも重要です。最初は記事閲覧で接点を持ち、その後ウェビナー参加を経て商談化するケースがあります。このとき、初回接点だけを見ると記事が評価され、商談化のきっかけだけを見るとウェビナーが評価されます。どちらも正しい情報です。目的に応じて見られるよう、最低限のデータ構造を決めておく必要があります。

Owner 変更ルールがないと案件責任がぼやける

営業データで見落とされがちなのが Owner の管理です。誰がそのリードや商談の責任者なのかが曖昧になると、対応漏れや二重対応が起きます。特にインサイドセールスから AE へ引き継ぐ組織、または地域や業界で担当が変わる組織では、Owner 変更ルールが重要です。

Owner を変更する条件は明文化するべきです。たとえば、商談化条件を満たしたら IS から AE に変更する。既存顧客の追加相談であれば CS と AE のどちらが一次対応するかを決める。休職や異動時の引き継ぎはマネージャーが承認する。これらが決まっていないと、SFA 上の担当者と実際に動いている担当者がずれます。

Owner の履歴も重要です。現在の担当者だけでなく、過去に誰が対応していたかが分かると、案件停滞の原因や引き継ぎ品質を分析できます。RevOps は、単に今の状態を集計するだけでなく、状態がどう変化したかを見られるように設計する必要があります。

SQL / MQL の境界を決める

マーケティングと営業の連携で必ず論点になるのが MQL と SQL の定義です。MQL はマーケティング上有望と判断されたリード、SQL は営業が対応すべきと判断したリードとして扱われることが多いですが、実際の条件は会社によって異なります。

問題は、MQL の数だけを追うと質が落ちやすいことです。資料ダウンロード、ウェビナー参加、メール開封などの行動点数だけで MQL にすると、営業が対応しても商談につながらないリードが増えます。逆に SQL の条件を厳しくしすぎると、早期接点を逃します。

最初は複雑なスコアリングよりも、シンプルな条件で十分です。企業規模、業種、役職、行動、課題の明確さ、導入時期のいずれを重視するかを決めます。そして、営業が対応した結果をマーケティングに戻す仕組みを作ります。SQL 化後に商談化しなかった理由を記録しなければ、MQL 条件は改善されません。

必須項目を増やしすぎない

データを整えようとすると、入力項目を増やしたくなります。業種、部署、役職、課題、予算、時期、競合、利用ツール、決裁者、導入範囲。どれも重要に見えます。しかし、必須項目が多すぎると現場は入力を後回しにします。結果として、形式的に埋められた低品質なデータが増えます。

最初に必須にすべき項目は、営業判断に直結するものだけです。商談名、会社名、Owner、ステージ、次回アクション日、導入目的、想定金額、Close予定日、失注理由。この程度から始め、運用が回ってから追加します。RevOps の目的は、完璧なデータベースを作ることではなく、売上判断に使えるデータを安定して集めることです。

項目を増やすときは、必ず「誰が、いつ、何の判断に使うのか」を確認します。使う人がいない項目は増やさない。入力タイミングが決まっていない項目は増やさない。判断に使われない項目は任意にする。この原則を守るだけで、SFA は現場に嫌われにくくなります。

データ品質は会議体で決まる

営業データは、入力ルールだけでは良くなりません。会議で使われて初めて品質が上がります。マネージャーが案件レビューでステージ定義を確認し、次回アクションが空欄ならその場で直し、失注理由が粗ければ深掘りする。こうした運用がなければ、現場は入力の重要性を感じません。

特に Forecast 会議では、ステージと金額とClose予定日を厳しく見るべきです。根拠のない金額、過去日のままのClose予定日、顧客の意思決定が進んでいないのに高い確度で登録された案件は、売上予測を歪めます。RevOps は会議体に入り、どのデータが判断に使われ、どのデータが使われていないかを観察する必要があります。

データ品質の改善は、現場を責める活動ではありません。入力しづらい項目、意味が伝わっていない定義、会議で使われない情報を減らす活動です。現場にとって意味のあるデータだけが残れば、入力負荷は下がり、活用度は上がります。

最低限の営業データ項目表

項目	入力するタイミング	入力責任者	会議での使い方
ステージ	顧客側の判断状況が変わった日	AE / マネージャー	Forecastと停滞確認
次回アクション日	商談後24時間以内	AE	案件レビューで停滞を見抜く
Lead Source	初回接点が発生した時点	Marketing / IS	施策評価と優先順位判断
Owner	対応責任が変わった時点	IS / AE / マネージャー	対応漏れと引き継ぎ確認
Close予定日	顧客側の手続き日程が見えた時点	AE	売上予測と支援優先度判断
失注理由	失注確定時	AE + マネージャー	次の商談改善と施策見直し

この表のポイントは、項目名だけでなく、入力タイミング、責任者、会議での使い方をセットにすることです。使い方が言えない項目は、必須化しても現場に定着しません。最初はこの程度に絞り、会議で使われるようになってから項目を増やします。

RevOps 導入前の最低チェックリスト

RevOps を本格的に置く前に、まず商談ステージの定義を一枚にまとめます。各ステージの目的、進める条件、戻す条件、必要な入力項目を明文化します。次に、Lead Source の選択肢を整理し、初回接点と商談化きっかけを分けるかどうかを決めます。

さらに、Owner 変更ルール、MQL / SQL 定義、失注理由の分類、次回アクション日の運用を決めます。これらが揃っていれば、RevOps はダッシュボード作成からではなく、売上プロセスの改善から入れます。

最後に重要なのは、小さく始めることです。最初から全データを完璧にしようとすると、設計だけで時間が過ぎます。まずは案件レビューと Forecast に必要な項目に絞り、毎週使いながら直す。RevOps は一度の設計で完成するものではなく、売上運営を学習させ続ける仕組みです。

編集・監修について

この記事は営業実務ラボ編集部が企画、執筆、編集しています。制作過程で生成AIを構成案作成、草案整理、表現確認に利用する場合がありますが、公開前に編集部が事実関係、出典、表現を確認しています。外部専門家による個別監修が入る場合は、記事内で監修者名または監修有無を明記します。