RevOps会議のアジェンダとは？営業・マーケ・CSが同じ数字で話す進め方
RevOps会議がうまくいかない組織では、営業、マーケ、CSがそれぞれ別の数字を持ち込み、会議が報告会で終わります。これではファネルの詰まりが見えても、誰が何を直すかが決まりません。
RevOps会議のアジェンダは、共有数字の確認、異常の特定、原因仮説、アクション決定の順で固定すると機能しやすくなります。本記事では、会議を改善の場にするための進め方を整理します。
本記事のポイント
- RevOps会議は数字の報告会ではなく、ファネルの詰まりを特定して責任者を決める場です。
- アジェンダは共有KPI、異常確認、原因仮説、アクション決定の順にすると会議がぶれにくくなります。
- 議事録より、誰がいつまでに何を直すかのアクションログを残す方が改善につながります。
この記事で扱うテーマ
関連キーワード
- RevOps 会議 アジェンダ
- RevOps 会議
- RevOps 定例
- 営業 マーケ CS 会議
- RevOps KPI 会議
このページで答える質問
- RevOps会議では何を話すべきですか？
- 営業とマーケはどの数字を共有すべきですか？
- 会議を報告会にしないにはどうすればいいですか？
- 会議後に何を残すべきですか？
最初に見るべき共有KPI
RevOps会議では、見る数字を増やしすぎると議論が拡散します。基本は、流入、商談化、受注、失注、継続に関わる数値のうち、部門をまたいで引き継がれるKPIに絞るべきです。
たとえば、MQL、商談化率、商談化までの速度、受注率、失注理由、CS引き継ぎ後の立ち上がりといった指標です。詳しいKPIの切り方は、RevOpsダッシュボード と揃えておくと会議が安定します。
会議アジェンダの基本順序
| 順序 | 話すこと | 長引きやすい罠 |
|---|---|---|
| 1 | 共有KPIの異常確認 | 全指標を読み上げるだけになる |
| 2 | 原因仮説の整理 | 部署ごとの言い分の応酬になる |
| 3 | 打ち手の優先順位付け | アイデア出しで終わる |
| 4 | 担当者と期限の確定 | 宿題が曖昧なまま終わる |
ポイントは、最初に全員が同じダッシュボードを見ていることです。数字の定義がズレた状態では、原因仮説に入れません。
報告会にしないための運用
RevOps会議が報告会になるのは、数字の背景説明に時間を使いすぎるからです。これを避けるには、数値確認を会議前に済ませ、会議では「異常値だけ」を扱う方が有効です。
- 通常値の共有は事前資料に寄せる。
- 異常なKPIだけを会議で扱う。
- 原因仮説は部門横断で1つずつ検証する。
- 最後に担当と期限を必ず確定する。
会議メモを長く残すより、アクションログを残す方が効果的です。会議後に何が変わるかが見えなければ、RevOps会議は定例化しても意味が薄くなります。
参加者を増やしすぎない方が意思決定は早い
RevOps会議に関係者を入れすぎると、情報共有は増えますが意思決定は遅くなります。基本は、数字の責任を持つ営業、マーケ、CSの代表者と、必要なら管理者だけに絞る方が進みやすくなります。
詳細共有が必要な内容は別途部門会議へ渡し、RevOps会議では「横断で決めるべき論点」に集中するのがコツです。参加人数を絞るだけでも、会議が報告会から改善会議に変わりやすくなります。
よくある質問
RevOps会議では何を話すべきですか？
共有KPIの異常、原因仮説、打ち手、担当と期限を話すべきです。
営業とマーケはどの数字を共有すべきですか？
MQL、商談化率、商談化速度、受注率、失注理由など、部門間で引き継がれるKPIを共有すべきです。
会議を報告会にしないにはどうすればいいですか？
通常値の共有は事前資料に寄せ、会議では異常値と改善アクションだけを扱うと効果的です。
会議後に何を残すべきですか？
長い議事録より、担当者、期限、検証項目を持つアクションログを残す方が改善に結びつきます。
