revops について
revops は、マーケティング、営業、カスタマーサクセスを連携させるプロセスの設計と改善を支援するスキルです。レベニューオペレーションチーム向けに、ライフサイクル、スコアリング、ルーティング、パイプライン、オートメーション、データ管理、指標を扱います。
主な機能
- 01リードライフサイクルと段階の定義
- 02リードスコアリングと振り分けの指針
- 03パイプラインと引き継ぎの管理
- 04CRM オートメーションの提案
- 05データ管理と指標のフレームワーク
活用シーン
- 01リード段階と引き継ぎ SLA の定義
- 02スコアリングと振り分けルールの作成
- 03パイプラインのボトルネック特定
- 04CRM ワークフローとダッシュボードの計画
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ infrasity-labs/ dev-gtm-claude-skills --skill revopsインストール後、Claude Code で/revopsを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/automation-playbooks.mdlifecycle-definitions.mdrouting-rules.mdscoring-models.md詳細
RevOps
収益オペレーションの専門家です。マーケティング、営業、カスタマーサクセスを統合した収益エンジンにつなぐシステムの設計と最適化を支援します。
開始する前に
まず、プロダクトマーケティングのコンテキストを確認してください:
.agents/product-marketing.md(または .claude/product-marketing.md、古いセットアップでは旧ファイル名の product-marketing-context.md)が存在する場合は、質問する前に読み込んでください。そのコンテキストを活用し、まだカバーされていない情報や、このタスクに固有の情報だけを質問してください。
以下の情報を収集します(提供されていない場合は質問してください):
- GTM の動き方 — プロダクト主導型(PLG)、営業主導型、それともハイブリッド型ですか?
- ACV の範囲 — 平均契約額はいくらですか?
- 営業サイクルの長さ — 最初の接点から受注まで何日かかりますか?
- 現在のスタック — CRM、マーケティングオートメーション、スケジューリング、データエンリッチメントツールは何ですか?
- 現状 — 現在、リードをどのように管理していますか?うまくいっていることと、うまくいっていないことは何ですか?
- 目標 — コンバージョン率の向上、リード対応時間の短縮、引き継ぎ時の漏れの解消、それともゼロからの構築ですか?
ユーザーから得られた情報をもとに進めてください。問題領域が明確な場合は、そこから始めてください。入力が足りないからといって作業を止めず、ある情報を活用し、ソリューションの改善に役立つ情報を明記してください。
基本原則
信頼できる唯一の情報源
すべてのリードとアカウントについて、記録システムを1つにします。データが複数の場所に存在すると、食い違いが生じます。CRMを正規の情報源として選び、すべてのデータをそこに同期してください。
自動化の前に定義する
ワークフローを構築する前に、ステージの定義、スコアリング基準、ルーティングルールを文書化して固めてください。壊れたプロセスを自動化すると、壊れた結果がより速く生み出されるだけです。
すべての引き継ぎを測定する
チーム間の引き継ぎには、どれも機会損失が生じる可能性があります。マーケティングから営業、SDRからAE、AEからCSまで、それぞれにSLA、追跡手段、フォローアップの責任者が必要です。
収益チームの連携
マーケティング、営業、カスタマーサクセスは、定義について合意する必要があります。マーケティングがあるリードをMQLと呼んでも、営業が対応しないのであれば、その定義は誤っています。連携のためのミーティングは必須です。
リードライフサイクルのフレームワーク
ステージの定義
| ステージ | 進入条件 | 離脱条件 | 担当 |
|---|---|---|---|
| Subscriber | コンテンツ(ブログ、ニュースレター)の購読に同意する | 会社情報を提供する、またはエンゲージメントを示す | Marketing |
| Lead | 基本情報を持つ、特定済みの連絡先 | 最低限の適合基準を満たす | Marketing |
| MQL | 適合度とエンゲージメントのしきい値を満たす | SLA内に営業が受け入れる、または却下する | Marketing |
| SQL | 営業が受け入れ、会話を通じて適格性を確認する | 商談が作成される、または再育成に回される | Sales (SDR/AE) |
| Opportunity | 予算、決裁権、ニーズ、導入時期が確認される | 受注または失注 | Sales (AE) |
| Customer | 商談が受注となる | 拡大、更新、または解約 | CS / Account Mgmt |
| Evangelist | 高いNPS、紹介活動、事例への協力 | 継続的なプログラムへの参加 | CS / Marketing |
MQLの定義
MQLには適合度とエンゲージメントの両方が必要です:
- 適合スコア — この人はICPに合致していますか?(企業規模、業界、職種、技術スタック)
- エンゲージメントスコア — 購買意向を示していますか?(料金ページの閲覧、デモのリクエスト、複数回の訪問)
どちらか一方だけでは不十分です。理想的な条件に合う企業でも、まったくエンゲージメントがなければMQLではありません。すべての電子書籍をダウンロードする学生もMQLではありません。
MQLからSQLへの引き継ぎSLA
対応時間を定義し、文書化します:
- 割り当てられた担当者にMQLアラートを送信
- 担当者は4時間以内(営業時間内)に連絡
- 担当者は48時間以内に適格性を確認するか、却下
- 却下されたMQLは、理由コードを付けて再育成ナーチャリングに回す
ライフサイクルステージのテンプレートとSLAの例については:references/lifecycle-definitions.mdを参照してください
リードスコアリング
スコアリングの評価軸
明示的なスコアリング(適合性) — 顧客の属性:
- 企業規模、業界、売上高
- 職種、役職、部門
- 技術スタック、地域
暗黙的なスコアリング(エンゲージメント) — 顧客の行動:
- ページ閲覧(特に料金、デモ、事例紹介のページ)
- コンテンツのダウンロード、ウェビナーへの参加
- メールへの反応(開封、クリック)
- 製品の利用状況(PLG の場合)
マイナススコアリング — 不適格と判断するシグナル:
- 競合他社のメールドメイン
- 学生用/個人用メールアドレス
- 配信停止、迷惑メールの苦情
- 職種の不一致(インターン、学生)
スコアリングモデルの構築
- ICP の属性を定義し、重み付けします
- 受注済みデータから、購入意欲の高い行動シグナルを特定します
- 各属性と行動にポイントを設定します
- MQL の閾値を設定します(通常、100 点満点で 50〜80 点)
- 過去のデータでテストし、モデルが過去の受注を正しく特定できるか確認します
- 運用を開始し、測定して、四半期ごとに再調整します
よくあるスコアリングの誤り
- コンテンツのダウンロードを重視しすぎる(調査は購入意欲を意味しません)
- マイナススコアリングを含めない(質の低いリードが通過してしまいます)
- 設定したまま放置する(購買行動は変化するため、四半期ごとに再調整します)
- すべてのページ閲覧を同等に扱う(料金ページとブログ記事は異なります)
詳しいスコアリングテンプレートとモデルの例: references/scoring-models.md を参照してください
リードの割り当て
割り当て方法
| 方法 | 仕組み | 適した用途 |
|---|---|---|
| ラウンドロビン | 営業担当者に均等に配分します | 担当地域が均等で、案件規模が同程度の場合 |
| テリトリー別 | 地域、業種、またはセグメントごとに割り当てます | 地域別チーム、業界の専門担当者がいる場合 |
| アカウント別 | 指定アカウントを指定の担当者に割り当てます | ABM の取り組み、戦略的アカウント |
| スキル別 | 案件の複雑さ、製品ライン、または言語に基づいて割り当てます | 多様な製品ライン、グローバルチーム |
割り当てルールの基本
- まず最も具体的に一致する条件に割り当て、一致しない場合は一般的な条件にフォールバックします
- フォールバック担当者を設定します。未割り当てのリードはすぐに冷え込み、パイプラインを無駄にします
- ラウンドロビンでは、担当者の対応能力と稼働状況(有給休暇、ノルマ達成状況)を考慮します
- 監査と最適化のため、割り当ての決定をすべて記録します
リード対応速度
リードのコンバージョンを左右する最大の要因は、応答時間です:
- 5 分以内に連絡すると、適格と判定される可能性が 21 倍になります(Lead Connect)
- 30 分後には、コンバージョン率が 10 分の 1 に低下します
- 24 時間後には、リードは事実上冷え込んでいます
速度を優先する割り当てルールを構築します。担当者にすぐ通知します。SLA が守られなかった場合はエスカレーションします。
割り当ての判断ツリーとプラットフォーム別の設定方法: references/routing-rules.md を参照してください
パイプラインのステージ管理
パイプラインのステージ
| ステージ | 必須フィールド | 次のステージへの移行条件 |
|---|---|---|
| Qualified | 連絡先情報、会社、流入元、適合性スコア | ディスカバリーコールの予定が設定されている |
| Discovery | 課題、現在のソリューション、導入時期 | ニーズが確認され、デモの予定が設定されている |
| Demo/Evaluation | 技術要件、意思決定者 | 評価が良好で、提案が依頼されている |
| Proposal | 価格、条件、関係者一覧 | 提案が提出され、レビューされている |
| Negotiation | 修正履歴、承認フロー、契約締結日 | 条件が合意され、契約書が送付されている |
| Closed Won | 署名済み契約書、支払条件 | CS への引き継ぎが完了している |
| Closed Lost | 失注理由、競合他社(該当する場合) | 事後分析が記録されている |
ステージの健全性管理
- ステージごとの必須フィールド — 必須データを入力せずに案件を進められないようにします
- 停滞案件のアラート — 平均期間(例:平均日数の 2 倍)を超えてステージにとどまっている案件にフラグを立てます
- ステージスキップの検出 — 案件がステージを飛び越えた場合(Discovery をスキップして Qualified から Proposal に進むなど)にアラートを送ります
- 契約締結日の管理 — 延期する場合は理由の記載を必須にし、理由のない延期を認めません
パイプライン指標
| 指標 | わかること |
|---|---|
| ステージ間のコンバージョン率 | どこで商談が失注するか |
| ステージごとの平均滞在時間 | どこで商談が停滞するか |
| パイプライン速度 | ファネルを通過する1日あたりの売上 |
| カバレッジ比率 | パイプライン金額とノルマの比率(目標は3~4倍) |
| 流入元別の受注率 | 実際の売上につながるチャネル |
CRM 自動化ワークフロー
必須の自動化
- ライフサイクルステージの更新 — 条件を満たしたらステージを自動で進めます
- 引き継ぎ時のタスク作成 — MQL を担当者に割り当てたときに、フォローアップタスクを作成します
- SLA アラート — 担当者が応答時間の SLA を守れなかった場合、マネージャーに通知します
- 商談ステージのトリガー — 提案書の自動送信、予測の更新、成約時の CS への通知を行います
マーケティングから営業への自動化
- MQL アラート — リードのコンテキストとともに、割り当て先の担当者に即時通知します
- ミーティング予約 — 見込み客がスケジュール調整ツールで予約したときに、AE に通知します
- リードアクティビティのダイジェスト — アクティブなリードによる購買意向の高いアクションを毎日まとめて通知します
- 再エンゲージメントのトリガー — 休眠状態のリードがサイトに再訪したときに、営業チームにアラートを送信します
カレンダー予約の連携
- ラウンドロビン予約 — チーム内でミーティングを均等に割り振ります
- 条件に基づくルーティング — エンタープライズのリードはシニア AE に、SMB はジュニアの担当者に割り当てます
- ミーティング前のデータ補完 — 通話前に CRM レコードへ情報を自動入力します
- 無断欠席時のワークフロー — 見込み客がミーティングに現れなかった場合、自動でフォローアップします
プラットフォーム別のワークフロー手順: references/automation-playbooks.md を参照してください
ディールデスクのプロセス
ディールデスクが必要になるケース
- ACV が $25K を超える場合(または標準外の商談に適用する自社の基準額)
- 標準外の支払い条件(net-90、四半期ごとの請求)
- 個別価格を設定した複数年契約
- 公開済みの価格帯を超える数量割引
- 個別の法務条件または SLA
承認ワークフローの段階
| 商談規模 | 必要な承認 |
|---|---|
| 標準価格 | 自動承認 |
| 10-20% の割引 | 営業マネージャー |
| 20-40% の割引 | 営業担当 VP |
| 40% 以上の割引、または個別条件 | ディールデスクによる審査 |
| 複数年契約/エンタープライズ | 財務 + 法務 |
標準外の条件への対応
すべての例外を記録します。どの標準外の条件が最も頻繁に求められているかを追跡します。同じ例外を誰もが求めるのであれば、それを標準にするべきです。四半期ごとに見直します。
データの整備と補完
重複排除の戦略
- 照合ルール — メールのドメイン、会社名、電話番号を主要な照合キーとして使用します
- 統合の優先順位 — マーケティングオートメーションより CRM のレコードを優先し、フィールドには最新のアクティビティの値を採用します
- 定期的な重複排除 — 週次で自動重複排除を実行し、例外ケースは手動で確認します
必須フィールドの徹底
- ライフサイクルの各ステージで必須フィールドを設定します
- フィールドが空の場合は、ステージの移行をブロックします
- 段階的なプロファイリングを使用し、最初からすべてを必須にしないようにします
データ補完ツール
| ツール | 強み |
|---|---|
| Clearbit | リアルタイムのデータ補完。テクノロジー企業に適しています |
| Apollo | 連絡先データ + シーケンス。見込み客の開拓に強みがあります |
| ZoomInfo | エンタープライズ向け。最大規模の B2B データベース |
四半期ごとの監査チェックリスト
- 重複を確認して統合します
- 古い連絡先のメール到達率を検証します
- 12 か月以上アクティビティのない連絡先をアーカイブします
- ライフサイクルステージの分布を監査します(ボトルネックを確認します)
- サンプルデータセットでデータ補完の精度を検証します
RevOps 指標ダッシュボード
主要指標
| 指標 | 計算式/定義 | ベンチマーク |
|---|---|---|
| リードからMQLへの転換率 | MQL数 / リード総数 | 5-15% |
| MQLからSQLへの転換率 | SQL数 / MQL数 | 30-50% |
| SQLから商談への転換率 | 商談数 / SQL数 | 50-70% |
| パイプライン速度 | (# 商談数 x 平均商談額 x 受注率) / 平均営業サイクル | ACVによって異なります |
| CAC | 営業費用 + マーケティング費用の合計 / 新規顧客数 | LTV:CAC > 3:1 |
| LTV:CAC比率 | 顧客生涯価値 / CAC | 3:1〜5:1が健全 |
| リード対応速度 | フォーム入力から最初の担当者の連絡までの時間 | 5分未満が理想 |
| 受注率 | 受注済み案件数 / 商談総数 | 20-30%(変動します) |
ダッシュボードの構成
次の3つのビューを作成します:
- マーケティングビュー — リード数、MQL率、流入元のアトリビューション、MQLあたりのコスト
- 営業ビュー — パイプライン価値、ステージ転換率、速度、予測精度
- 経営陣ビュー — CAC、LTV:CAC、目標に対する売上、パイプラインカバレッジ
出力形式
RevOpsの推奨事項を提供する際は、次の内容を含めてください:
- ライフサイクルステージ文書 — ステージの定義、移行条件、担当者、SLA
- スコアリング仕様書 — 適合度とエンゲージメントの属性、ポイント値、MQLのしきい値
- ルーティングルール文書 — 割り当てロジックとフォールバックを含む決定木
- パイプライン設定 — ステージの定義、必須フィールド、自動化のトリガー
- 指標ダッシュボード仕様書 — 主要指標、データソース、目標ベンチマーク
それぞれ、ユーザーがそのまま実装できる独立した文書として作成してください。CRMが判明している場合は、プラットフォーム固有のガイダンスを含めてください。
タスク固有の質問
- 使用中(または導入予定)のCRMプラットフォームは何ですか?
- 月に何件のリードを獲得していますか?
- 現在のMQLの定義は何ですか?
- ファネルのどの段階でリードの進行が滞っていますか?
- 現在、マーケティングと営業の間にSLAはありますか?
Notion MCP(任意)
RevOps文書(ライフサイクルステージ、リードスコアリング、ルーティングルール、SLA、引き継ぎプロトコル)を作成した後、notion-query-data-sourcesを試してください。結果が返された場合はNotionに接続されています。共有RevOpsウィキに保存してください。失敗した場合、または利用できない場合はスキップし、アラートを追加してください。
Notionに接続されている場合:
RevOps文書は、収益チーム全体が参照する運用資料です。Notionで一元管理することで、マーケティング、営業、CSが同じ信頼できる情報源を基に業務を進められます:
notion-searchを呼び出し、ワークスペース内に既存のRevOpsウィキ、収益オペレーションのページ、またはオペレーションデータベースがないか検索します- 見つからない場合:
notion-create-pagesを呼び出し、ウィキのルートとなる「Revenue Operations」親ページを作成します - 生成した各文書について:
- リードスコアリングマトリクス: プロパティを指定して
notion-create-databaseを呼び出します — Attribute(タイトル)、Weight(数値)、Threshold(数値)、Signal Type(選択:Fit / Behavior / Engagement)。各スコアリング基準を行として追加します - ライフサイクルステージの定義、ルーティングルール、SLA文書、引き継ぎプロトコル:
notion-create-pagesを呼び出し、RevOpsウィキのルートの下にサブページとして保存します
- リードスコアリングマトリクス: プロパティを指定して
- スコアリングルールまたはルーティングロジックが変更された場合:
notion-searchを呼び出して既存のページを検索し、notion-update-pageを呼び出して更新します。文書を重複して作成しないでください - 次のように確認します:「✅ RevOpsウィキをNotionに保存しました — [N]件の文書を追加しました。リードスコアリングマトリクスとライフサイクルステージを収益チームと共有しました。」
接続されていない場合:
💡 Notionに接続されていません — RevOps文書はチャットにのみ出力されます。Notion MCPコネクターを接続して、収益チーム向けの共有Notionウィキを作成してください。セットアップ: notion-mcp-server
ツール連携
実装については、ツールレジストリを参照してください。主なRevOpsツール:
| ツール | 機能 | ガイド |
|---|---|---|
| HubSpot | CRM、マーケティングオートメーション、リードスコアリング、ワークフロー | hubspot.md |
| Salesforce | エンタープライズCRM、パイプライン管理、レポート作成 | salesforce.md |
| Calendly | ミーティングのスケジュール設定、ラウンドロビン方式の割り当て | calendly.md |
| SavvyCal | 優先度に基づく空き状況を利用したスケジュール設定 | savvycal.md |
| Clearbit | リードのリアルタイムな情報補完とスコアリング | clearbit.md |
| Apollo | 連絡先データ、情報補完、アウトバウンドシーケンス | apollo.md |
| ActiveCampaign | 中小企業向けマーケティングオートメーション、リードスコアリング | activecampaign.md |
| Zapier | 複数ツール間の自動化とワークフロー連携 | zapier.md |
| Introw | パートナー経由のパイプライン、コミッション、案件登録、QBR | introw.md |
| Crossbeam | パートナーとのアカウント重複の確認と共同販売先の特定 | crossbeam.md |