RevOps（Revenue Operations）とは「Marketing・Sales・Service の3部門が共通のデータ・プロセス・テクノロジーで動く」組織設計だ。しかし多くの組織では今日も「Marketing が渡したリードを Sales が無視する」「Sales が受注した顧客の情報が CS に届かない」「どこで失注しているかが誰にも見えていない」という分断が起きている。本章ではLifecycle Stage の自動遷移設計・リードルーティング・MQL → SQL ハンドオフ・CS へのハンドオフ・RevOps 指標と統合レポートを設計から実装まで解説する。
RevOps が解決しようとしている問題は「部門間の壁がビジネス成長を阻む」という構造的な課題だ。Marketing は「リードを渡した」と言い、Sales は「使えるリードが来ない」と言い、CS は「どんな顧客を受け取ったのか知らされない」と言う。この分断の根本原因はデータ・プロセス・ゴール設定がバラバラなことにある。
| 条件 | 具体的な内容 | Operations Hub での実現方法 |
|---|---|---|
| ① 共通の定義 | MQL・SQL・SAL の定義が Marketing/Sales/CS で一致している。「MQL は何点以上のリードか」を全員が同じ基準で理解している | リードスコアの計算 WF と MQL 昇格条件を HubSpot に実装し、全員が同じロジックを参照できる状態にする |
| ② 自動化されたハンドオフ | MQL になったらすぐ Sales に通知・受注したら CS に顧客情報が渡る。手動メールやスプレッドシートに頼らない | Lifecycle Stage 遷移 WF・ハンドオフ通知 WF・タスク自動作成 WF で人が忘れても動くプロセスを構築する |
| ③ 共通の指標 | Marketing は「MQL 数」Sales は「受注数」CS は「チャーン率」と別々に追うのではなく、ファネル全体の転換率を全部門が共有している | カスタムレポートで「リード→MQL→SQL→受注→12ヶ月継続率」の全ファネルを1ダッシュボードで可視化する |
Lifecycle Stage（ライフサイクルステージ）は HubSpot の最重要プロパティの一つだ。Subscriber → Lead → MQL → SQL → Opportunity → Customer → Evangelist という8段階で、コンタクトが「今どの段階にいるか」を表す。これが自動的に動いていない組織では、全員が古い Stage を見て意思決定しているという問題が起きる。
よくある設計ミスは「スコアが下がったら MQL → Lead に自動降格させる」WF を作ることだ。これをやるとSales が追っているリードがある日突然 Lead に戻るという混乱が起きる。Lifecycle Stage は原則として「一方向（昇格のみ）」に設計する。スコアの低下は別の「再ナーチャリング対象リスト」で管理し、Stage 自体は下げない。
MQL 判定の精度はリードスコアリングの設計で決まる。スコアが低すぎると Sales に大量の使えないリードが届き「Marketing のリードは使えない」という不信感が生まれる。スコアが高すぎると有望なリードを取りこぼす。適切なスコア設計が Marketing と Sales の信頼関係の基盤になる。
ハンドオフ（引き継ぎ）は RevOps で最もトラブルが起きやすいポイントだ。「渡した・渡されていない」という認識のズレ、引き継ぎに必要な情報が伝わっていない、タイムラグが長すぎてリードが冷める——これらをワークフローで自動化して「人が忘れても、情報が漏れても、プロセスは止まらない」設計にする。
MQL 昇格から24時間以内に Sales がコンタクトしなかった場合に自動でエスカレーションする WF を作る。具体的には「MQL になってから25時間後に、hs_sales_email_last_replied が空欄なら、Sales マネージャーに警告タスクを作成する」。SLA 違反を人が気づくのを待つのではなく、仕組みが自動で追いかける設計が RevOps の基本だ。
RevOps のレポートは「部門ごとの数字の羅列」ではなく、「リードが生まれてから顧客として継続するまでの全ファネルを1本の流れで可視化する」ものでなければならない。Marketing は MQL 数だけ、Sales は受注数だけを追っていると、ファネルのどこで詰まっているかが見えない。
HubSpot の「カスタムレポート」でファネルのステージ別転換率を可視化する。レポートビルダーで「コンタクト」オブジェクトを選択し、「Lifecycle Stage 別のコンタクト数の推移」グラフを作成。さらに Data Studio（第4章）で作成したデータセットをレポートのデータソースに追加することで、HubSpot 外部のデータ（Snowflake の請求データ・BigQuery の製品利用データ）と組み合わせた統合ファネルレポートが作れる。
| レポート種別 | 設定方法 | 更新頻度 | 主な閲覧者 |
|---|---|---|---|
| ファネル転換率レポート | カスタムレポート → ファネルチャート → Stage 別コンタクト数 | 週次更新 | Marketing / Sales / CS リーダー・RevOps |
| パイプライン予測レポート | 取引レポート → ステージ別金額・クローズ予定日 | 毎日自動更新 | Sales リーダー・CFO・CEO |
| MQL SLA 遵守率レポート | カスタムプロパティ（mql_date・first_contact_date）を使った計算列 | 週次 | Sales マネージャー・RevOps |
| チャーン & NRR レポート | Data Studio でCS チケット + HubSpot 顧客データ + 請求データを結合 | 月次 | CS リーダー・CFO・経営陣 |
| アトリビューションレポート | HubSpot のマルチタッチ Attribution レポート + カスタムレポート | 月次 | Marketing リーダー・CMO |
RevOps が成熟した組織では「週次の Revenue Review ミーティングで、全員が同じ HubSpot ダッシュボードを見ながら議論する」という運用が定着している。Marketing・Sales・CS それぞれが自分のツールでバラバラのレポートを持ち寄るのではなく、1つの共通ダッシュボードが唯一の真実（Single Source of Truth）になることが RevOps の到達点だ。そのダッシュボードを HubSpot と Data Studio で構築することが、本章の設計の目的でもある。
MQL の定義が部門間で一致していなければ、どんな自動化も意味をなさない。まず Marketing と Sales が「何点でMQL か」を合意し、その基準を HubSpot に実装する。合意なき自動化は自動化された混乱を生むだけだ。
スコア低下による自動降格は混乱の元。Stage は原則として昇格のみ。降格は手動・例外処理として管理する。MQL 昇格条件はシンプルに「スコア閾値＋エンゲージメント条件」の2要素で設計し、複雑にしすぎない。
単純なラウンドロビンから始めてよいが、成長とともに Enterprise/Mid-Market/SMB の分類・地域別・業種別の分岐が必要になる。ルーティングロジックはカスタムコードアクション（第3章）で実装することで複雑な条件にも対応できる。
何を渡すか（情報セット）・いつまでに対応するか（SLA）・守られなかったらどうなるか（エスカレーション）の3点を WF で自動化する。人の善意に依存するハンドオフは必ず失敗する。仕組みが追いかける設計にする。
「MQL 数が増えた」だけでは不十分。MQL → SQL 転換率・SQL → 受注転換率・サイクルタイム・チャーン率を同じダッシュボードで可視化して初めて「ファネルのどこに問題があるか」が見える。
ツールや指標がバラバラなまま議論すると「うちの数字ではそうじゃない」という水掛け論になる。HubSpot の統合ダッシュボードを Single Source of Truth として全部門が合意することが、RevOps 組織成熟の到達点だ。