レベニューオペレーションとは何か：予測可能な成長のための運用システム

会社にレベニューオペレーションが必要だという最初のサインは、通常ダッシュボードの欠如ではありません。

もっとこんな形で現れます。マーケティングはリード数が増えたと言い、営業はリードの質が下がったと言い、カスタマーサクセスは新規顧客がプロダクトでは支えられない約束を携えてやってくると言い、財務は予測が現実と一致しなくなったと言う。

どのチームも懸命に働いています。どのチームもそれなりに妥当な真実を持っています。問題は、収益システムに単一の運用オーナーがいないことです。

レベニューオペレーション、通常RevOpsと略されるこの機能は、初回接触から更新までの収益運用システム全体を設計、統治、測定、改善します。マーケティング、営業、カスタマーサクセス、財務、データ、システムをつなぎ、会社がいくつもの分断されたモーションではなく、1つの測定可能な収益モーションを運用できるようにします。

Gartnerはレベニューオペレーションを、機能を横断して顧客エンゲージメントを統合し、事業全体で人、プロセス、テクノロジーを統合するエンドツーエンドのモデルだと説明しています。それが正しい出発点です。RevOpsはレポーティングチームではありません。CRM管理チームでもありません。セールスオペレーションの新しい肩書きでもありません。それは、収益を運用し、点検し、予測し、改善しやすくする運用レイヤーです。

レベニューオペレーションの定義

レベニューオペレーションは、顧客ライフサイクル全体にわたる収益成長を支えるプロセス、データ、システム、指標、運用リズムに責任を持つ、部門横断的な専門分野です。

実務的に言えば、RevOpsは結合組織を所有します。

• リードがどのようにシステムに入るか
• リードがどのように見極められ、ルーティングされ、受け入れられるか
• 商談がどのように作成され点検されるか
• 予測がどのように構築され信頼されるか
• 受注したディールがどのようにオンボーディングへ移行するか
• 更新と拡大のシグナルがどのように計画へフィードバックされるか
• 経営陣が収益パフォーマンスの単一の姿をどう見るか

この範囲こそが、RevOpsを機能特化型の運用チームと区別するものです。セールスオペレーションは営業実行を改善します。マーケティングオペレーションはキャンペーン実行を改善します。CSオペレーションはリテンション実行を改善します。RevOpsは、それらのチームが共有する収益システムを改善します。この境界線は、GTMオペレーション vs レベニューオペレーションではより曖昧で、両者はしばしば重なり合います。

創業者1人、営業担当者1人、シンプルなファネルを持つ会社にとっては、この区別はまだ重要ではないかもしれません。創業者はシステムを頭の中に保持できます。マーケティング、営業、カスタマーサクセス、財務のすべてが同じ顧客データ、引き継ぎ、予測インプット、ダッシュボードに依存するようになると、そのシステムには運用オーナーが必要になります。

RevOpsが存在する理由

RevOpsが存在するのは、収益に関する業務がチームの境界を越える一方で、ほとんどの会社がチーム別のサイロで組織されているからです。

マーケティングは需要創出を所有しますが、その需要が有用かどうかを証明する営業のコンバージョン業務は所有していません。営業はパイプラインを所有しますが、そのパイプラインを生んだキャンペーンデータやライフサイクルの定義は所有していません。カスタマーサクセスはリテンションを所有しますが、営業段階で設定された顧客の期待を引き継ぎます。財務は計画を所有しますが、不完全だったり古かったり一貫性がなかったりするかもしれないCRMからの予測インプットに依存します。

その結果、予測可能な摩擦が生まれます。

あるリードはマーケティングオートメーションプラットフォーム上では見極め済みとされていますが、営業は同意しません。あるディールはコミット段階にありますが、クローズ日はすでに3回変更されています。ある顧客は、導入担当が本来のユースケースを一度も受け取らなかったために解約します。取締役会向けレポートは1つのパイプライン数値を示していますが、営業予測は別の数値を示しています。

これらの失敗のどれも、きれいに1つのチームに属してはいません。それらはチームとチームの間に存在します。だからこそ、それらは解消されずに残り続けるのです。

Harvard Business Reviewは、マーケティングと営業の不整合のコストについて書いており、そのギャップが企業に年間1兆ドル超のコストをもたらしていると推計しています。RevOpsはそのギャップに対する1つの答えです。共有の収益システムに、定義を標準化し、引き継ぎを徹底し、データレイヤーを維持する権限を持つオーナーを与えることです。

RevOpsに関する重要な事実

重要な事実：レベニューオペレーション

• Gartnerは、RevOpsを機能を横断して顧客エンゲージメントを統合し、人、プロセス、テクノロジーを統合するエンドツーエンドのモデルと定義しています。
• Forresterは、レベニューオペレーションをマーケティング、営業、パートナー、カスタマーサクセスの運用上の責任を横断するアライメントを中心に位置づけています。
• HBRは、営業とマーケティングの不整合が企業に年間1兆ドル超のコストをもたらしていると推計しています。
• Salesforceの調査は、営業担当者が実際の販売活動に費やす時間はわずか28%だと報告しており、これがRevOpsチームがプロセスの摩擦、CRMの衛生管理、ワークフローの質に重点を置く理由の一つです。

この数字自体も重要ですが、運用上の意味合いの方がより重要です。企業がRevOpsに向かうのは、収益の複雑さが非公式な連携の範囲を超えて成長するからです。

RevOpsの運用レイヤー

RevOpsを理解する有用な方法は、それを6つの運用レイヤーに分解することです。

RevOpsが弱いと、これらのレイヤーは散らばったままになります。マーケティングはある定義を所有し、営業は別の定義を所有し、財務は両者を照合するためのスプレッドシートを作り、カスタマーサクセスは更新リスクを別のツールで管理します。

RevOpsが強いと、これらのレイヤーは共有の運用システムになります。リードマネジメントのプロセスはリードルーティングの自動化にきれいにつながります。セールスパイプラインは明確なステージから構築されます。フォーキャストの基礎は人々が信頼するデータに依存します。マーケティングと営業のアライメントは、繰り返される交渉ではなく1つのシステムになります。

RevOpsが担うもの

RevOpsは、複数の収益チームが依存する運用資産を所有すべきです。

定義。 ライフサイクルステージ、MQL、SQL、商談、受注、解約、拡大、ソース由来のパイプライン、影響を受けたパイプライン、予測カテゴリーには、1つの共有された定義が必要です。それがなければ、あらゆるレポートが議論の的になります。

ワークフロー。 RevOpsは、レコード、タスク、説明責任をチーム間で移動させるワークフローを設計します。これには、リードルーティング、割り当てのSLA、商談ステージの移動、受注後の引き継ぎ、更新アラート、エスカレーション経路が含まれます。

ダッシュボード。 RevOpsは共有レポーティングレイヤーを所有すべきです。これは、各チームが自分の機能別ダッシュボードを失うという意味ではありません。経営陣が信頼できる共有ビューから収益に関する意思決定を行うという意味です。

データ品質。 フィールドの完全性、重複、古いレコード、エンリッチメント、インテグレーションの健全性は、単なる管理上のクリーンアップ業務ではありません。それらは収益インフラです。

システムガバナンス。 RevOpsは、収益システムがどのようにつながるか、どのチームがフィールド、自動化、スコアリングルール、レポートロジックを変更できるかを決定します。

運用リズム。 週次のパイプラインレビュー、月次のファネルレビュー、四半期の計画、予測点検、リテンションレビューには、それぞれ明確な目的、データパケット、所有者、意思決定のアウトプットが必要です。

RevOpsが担わないもの

RevOpsは、あらゆる商業上の意思決定の戦略オーナーになろうとすると失敗します。

RevOpsはマーケティングリーダーシップを置き換えません。CMOやマーケティングリーダーは、ポジショニング、チャネル、キャンペーン、需要戦略を引き続き所有します。

RevOpsは営業リーダーシップを置き換えません。営業担当VPは、クォータの実行、コーチング、採用、テリトリー戦略、商談管理を引き続き所有します。

RevOpsはカスタマーサクセスリーダーシップを置き換えません。CSは、オンボーディングの質、定着、更新の会話、拡大戦略を引き続き所有します。

RevOpsは財務を置き換えません。財務は、会社の計画、収益認識、予算、財務レポートを引き続き所有します。

RevOpsは、共有システムを信頼できるものにすることで、これらの機能を運用しやすくします。それは戦略を実行可能にするものであり、単独で戦略を発明するものではありません。

会社がRevOpsを必要とするとき

RevOpsの必要性は、連携コストが成長の質を下げ始めたときに現れます。

次のうちいくつかが当てはまる場合、おそらくRevOpsのオーナーが必要です。

• マーケティングと営業が毎月リードの質について意見が合わない。
• 営業リーダーがCRMのパイプラインデータを信頼していない。
• CRMの予測が信頼できないため、財務が別の予測を維持している。
• カスタマーサクセスが、あまりに多くの顧客が不完全な引き継ぎメモとともにやってくると言っている。
• キャンペーンアトリビューションが、行動よりも議論の対象になっている。
• リードルーティングのルールが古い、または不明確である。
• マネージャーが予測の電話で意思決定ではなくデータのクリーンアップに時間を費やしている。
• ある機能でのツールの意思決定が、別の機能のレポートを壊してしまう。
• 会社は人員を増やしているのに、収益プロセスの質は悪化している。

これらの問題は必ずしも完全なRevOpsチームを必要とするわけではありません。最初のステップは、共有の収益プロセスに1人の明確なオーナーを割り当てることかもしれません。しかし、この問題を無視すると、通常は将来のあらゆる採用の生産性が下がっていきます。

RevOps成熟度の5段階

ほとんどの会社は、RevOpsが全くない状態から成熟した運用システムへと、1四半期で移行するわけではありません。この機能は通常、5つの段階を経て進化します。

よくある間違いは段階を飛ばすことです。ステージの定義が弱い会社は、予測的なフォーキャストから始めるべきではありません。引き継ぎSLAのない会社は、受け入れルールが明確になる前にルーティングを自動化すべきではありません。

次に何を構築すべきかを決める前に、RevOps成熟度モデルを使って会社がどこに位置するかを診断してください。

会社の段階別のRevOps運用モデル

RevOpsは会社の成長とともに姿を変えるべきです。30人規模の会社は、複数のプロダクト、地域、更新モーションを持つ500人規模の会社と同じ運用モデルを必要としません。

この段階別の視点はRevOpsを実務的なものに保ちます。目標は組織図上で機能を成熟しているように見せることではありません。目標は、収益システムが今必要としている連携の量に、運用上の規律を合わせることです。

過剰に作り込まずにRevOpsを始める方法

RevOpsの最初の一歩は、システムを点検しやすくするものであるべきです。あらゆる小さな変更に対して重い承認プロセスを作るべきではありません。

次の4つの動きから始めてください。

実際のレコードからライフサイクルをマッピングする。 最近のリード、商談、受注したディール、解約した顧客、拡大商談を集めてください。各レコードについて、今誰がそれを所有しているか、どのステージにあるか、そのステージを裏付ける根拠は何か、次に何が起きるべきかを問うてください。実際のレコードは、ワークショップの図よりも早く混乱を明らかにします。

共有の定義を書く。 リード、MQL、SQL、商談、コミット、受注、オンボード済み、更新リスク、解約、拡大を定義してください。それぞれの定義は短く保ってください。マネージャーが点検の際にそれを使えないなら、十分に明確ではありません。

最もリスクの高い引き継ぎを選ぶ。 ほとんどの会社は、リードの割り当て、MQLからSQLへ、商談の作成、または受注からオンボーディングへの引き継ぎから始めるべきです。すべてのワークフローを書き直す前に、1つの引き継ぎを深く修正してください。

1つの信頼できる運用ビューを作る。 リーダーが実際に使う小さなダッシュボードを作ってください。ステージ転換率、SLA未達、パイプラインカバレッジ、予測の質、引き継ぎの完全性、必須フィールドの完全性です。誰も行動に移さない40枚のチャートのダッシュボードよりも、信頼できる10指標のビューの方が優れています。

ここでRevOpsの最初の90日間のプレイブックが役に立ちます。RevOpsは、巨大なロードマップを公開することではなく、目に見える痛みを運用上の変化に変えることで信頼を得ます。

RevOpsが日々の業務で変えること

優れたRevOpsは、小さな運用上の行動の中に見て取れます。

その価値は抽象的なアライメントではありません。避けられる議論が減り、診断が速くなり、引き継ぎがクリーンになり、計画への確信度が高まることです。

良い最初の四半期のRevOpsの成果

現実的な最初の四半期は、全面的な作り直しではなく、いくつかの高い信頼性を持つ資産を生み出すべきです。

最初の四半期の終わりまでに、新しいRevOpsオーナーは次を示せるべきです。

• リードから更新までの1つのライフサイクルマップ。
• 合意された定義の短いリスト。
• 所有者、SLA、必須フィールド、例外経路を備えた引き継ぎ表。
• 主要な収益指標のための正式なデータ源のマップ。
• 収益リスクに紐づいた優先順位付けされたRevOpsロードマップ。
• リーダーがデータの照合に費やす時間が減った、よりクリーンな運用レビュー。

最初の四半期が新しいレポートしか生み出さないなら、そのミッションは狭すぎます。レポートは有用ですが、本当のテストは、会社が収益に関する業務をチーム間でどう動かすかを変えられたかどうかです。

RevOpsがReworkの収益ライブラリをどうつなぐか

RevOpsが有用なのは、通常は別々のプレイブックに文書化されている業務をつなぐからです。

リードマネジメントは需要がどのようにシステムに入るかを定義します。パイプラインマネジメントは潜在的な収益がどのように点検されるかを定義します。ディールクロージングは、コミットメントがどのように顧客になるかを定義します。ポストセールマネジメントは、顧客がどのように更新、拡大、または解約するかを定義します。マーケティングと営業のアライメントと営業とCSのアライメントは、それらのフェーズ間の引き継ぎを定義します。

RevOpsはそれらのライブラリを1つのシステムにします。

リードソースはファネルコンバージョンレポートに流れ込むべきです。見極めルールはルーティングとセールスキャパシティに影響を与えるべきです。営業の約束は顧客オンボーディングに反映されるべきです。解約理由はICPとキャンペーンターゲティングに情報を与えるべきです。予測の未達は、単なるマネージャーの説明ではなく、プロセスレビューを引き起こすべきです。

これが、SaaS RevOpsフレームワークが獲得、コンバージョン、リテンション、拡大をまとめてカバーするときに最も強力になる理由です。RevOpsは1つの段階を所有するチームではありません。すべての段階が使える形のデータと説明責任を次の段階へ渡せるようにするチームです。

実務的なRevOps診断

次回の運用レビューで次の問いを投げかけてください。

1. マーケティング、営業、CS、財務は同じライフサイクルステージを同じ言葉で説明できるか。
2. すべての引き継ぎに所有者、SLA、例外経路があるか。
3. CRMは、シャドースプレッドシートなしで予測を運用できるほど信頼されているか。
4. リーダーは手作業でのクリーンアップなしに、ソース別、セグメント別、ステージ別のコンバージョンを見られるか。
5. 受注したディールは、CSが必要とする情報を伴ってオンボーディングに届いているか。
6. 予測の電話は、リスクとアクションについてのものか、それとも古いデータの修正についてのものか。
7. ツールを横断した収益システムの変更を誰かが所有しているか。
8. ダッシュボードは意思決定に紐づいているか、それとも単なるレポート成果物にすぎないか。
9. 解約と拡大のシグナルはICPと見極めルールにフィードバックされているか。
10. RevOpsはシステムの改善にほとんどの時間を費やしているか、それともチケットへの対応に追われているか。

答えの多くが不明確であれば、その会社が必要としているのはより良いレポートだけではありません。より強力なレベニューオペレーションです。

Reworkのようなプラットフォームが果たす役割

RevOpsには、レコード、ワークフロー、所有権、活動データが一貫して統治できるシステムが必要です。ReworkのようなCRMやワークフロープラットフォームは、リードルーティング、ライフサイクルステータス、タスクの所有権、引き継ぎレコードを1か所で可視化することで、その基盤を支えられます。ツールそのものがRevOpsを作るわけではありません。運用ルールが先にあるべきです。それらが明確になって初めて、プラットフォームはそれを徹底できます。

FAQ

レベニューオペレーションを簡単に言うと何ですか？

レベニューオペレーションは、マーケティング、営業、カスタマーサクセス、財務、システムを横断して収益プロセス全体を機能させる機能です。共有の定義、ワークフロー、データ品質、ダッシュボード、運用リズムを所有します。

RevOpsはセールスオペレーションと同じですか？

いいえ。セールスオペレーションは営業実行を改善します。RevOpsは収益システム全体を改善します。セールスオペレーションはRevOpsの中に専門レーンとして位置づけられることもありますが、RevOpsはより広い部門横断的なミッションを持っています。

RevOpsは誰に報告すべきですか？

RevOpsは通常、CRO、COO、CEOのような部門横断的なリーダーの下で最もうまく機能します。営業だけ、あるいはマーケティングだけに報告する場合、他のチームがその意思決定やダッシュボードを信頼しなくなることがあります。

会社はいつRevOpsを採用すべきですか？

収益の引き継ぎ、CRMへの信頼、予測の質、アトリビューション、または契約後の引き継ぎがチームを横断して崩れ始めたら、RevOpsのオーナーを採用または任命してください。それは多くの場合、リーダーが完全なRevOps部門の準備ができたと感じるより前に起こります。

最初のRevOpsプロジェクトは何ですか？

ライフサイクルの定義と引き継ぎから始めてください。会社がリード、MQL、SQL、商談、受注、オンボーディング、更新、解約を一貫して定義できなければ、あらゆるダッシュボードと自動化がその混乱を引き継いでしまいます。

関連記事

• レベニューオペレーションフレームワーク
• RevOps vs セールスオペレーション
• RevOpsチーム構造
• RevOps指標
• アライメントの接着剤としてのRevOps