RevOpsチーム構成: 一元型、埋め込み型、ハイブリッド型モデルの比較

同じ「RevOps」という職種名が、3つのまったく異なるものを意味することがあります。

ある会社では、RevOpsはHubSpotを維持し、リードをルーティングし、週次レポートを作成する一人のオペレーターです。別の会社では、RevOpsはCROの下にある一元化された部門で、セールスオプス、マーケティングオプス、CSオプス、アナリティクス、システムがすべてその中に含まれます。第三の会社では、RevOpsはガバナンス機能であり、オペレーションの専門家はマーケティング、営業、カスタマーサクセスに埋め込まれたままです。

3つとも機能し得ます。3つとも失敗し得ます。

適切なRevOpsチーム構成は、運用上の複雑さ、つまり収益チームの数、営業モーション、ライフサイクルステージ、システム、セグメント、意思決定権限によって決まります。構成は収益システムに従うべきであり、その逆ではありません。

機能の定義についてはRevenue Operationsとは何かを、オペレーティングモデルについてはRevenue Operationsフレームワークを参照してください。

ForresterのRevOps組織設計に関する調査は、Revenue Operationsがマーケティング、営業、顧客エンゲージメントの取り組みを一つの整合した目的のもとに結集できると指摘しています。この広い範囲だからこそ、構成が重要になります。チームがRevOpsと名付けられていても、共有の運用レイヤーに対する権限がなければ失敗し得ます。

ForresterのRevOps神話分析も、成功する構成は分散型から完全な一元型まで幅があると指摘しています。これが重要なのは、普遍的な組織図が存在しないからです。構成は会社の運用上の複雑さに合わせる必要があります。

押さえておくべき運用の要点

• RevOpsチーム構成は、モーション、セグメント、システム、ライフサイクルステージ、意思決定権限といった運用上の複雑さに従うべきです。
• 一元型チームは共有の基準を守ります。埋め込み型チームは機能上の文脈を守ります。ハイブリッド型チームには明確なRACIが必要です。
• RevOpsの最初の採用者は、通常、ダッシュボードのオーナーだけでなく、部門横断的な判断力を持つビルダーであるべきです。
• チーム構成は、依頼件数、レポーティングの対立、システムの複雑さ、引き継ぎリスクが変化したときに見直すべきです。

RevOpsチームが実際に所有するもの

構成を選ぶ前に、その使命を定義してください。

RevOpsチームは通常、6つの領域を所有します。

• 収益ライフサイクル全体のプロセスガバナンス
• 収益データの定義と品質
• システム管理またはシステムガバナンス
• レポーティングとアナリティクス
• 運用リズム
• 部門横断的な課題解決

これは、RevOpsがすべての意思決定を下すという意味ではありません。RevOpsが、それらの意思決定を可能にするオペレーティングシステムを所有するという意味です。

例えば、マーケティングはキャンペーン戦略を所有します。営業は商談の実行を所有します。カスタマーサクセスはオンボーディングと継続を所有します。RevOpsは、これらのチームが同じシステムから働けるようにする、共有のライフサイクル定義、CRMフィールド、引き継ぎ要件、ダッシュボード、エスカレーションパスを所有します。

モデル1: 一元型RevOps

一元型モデルでは、一つのRevOpsチームがマーケティング、営業、カスタマーサクセス、ファイナンス、経営陣に対応します。トレードオフのより深い比較については、一元型RevOps対埋め込み型RevOpsを参照してください。

この構成には通常、RevOps責任者またはRevOpsディレクターに加え、会社の成長に伴ってCRM、アナリティクス、マーケティングオプス、セールスオプス、カスタマーサクセスオプスの専門家が含まれます。

最適な状況: 標準化、単一のソース・オブ・トゥルース、強力なシステムガバナンスを必要とする会社。

強み:

• 共有の定義を徹底しやすい。
• ツール選定が分断されにくい。
• ダッシュボードを一つのソースから統治できる。
• 部門横断的な優先順位のバランスを取りやすい。
• CRO、COO、CEOに報告するなら、RevOpsは中立的な使命を持てる。

リスク:

• チームがボトルネックになり得る。
• 各部門は、RevOpsが日々の実態から遠いと感じるかもしれない。
• チケットの対応がキャパシティを消費し得る。
• 専門家は、営業、マーケティング、CSの業務に近くない場合、文脈を見失うことがある。

一元型RevOpsは、標準化を正当化するのに十分な複雑さがあり、RevOpsが単なる依頼対応窓口になることを防ぐのに十分な経営陣の支援がある場合に最もうまく機能します。

モデル2: 埋め込み型RevOps

埋め込み型モデルでは、オペレーションの専門家が支援先の部門の中に配置されます。マーケティングオプスはマーケティングに報告します。セールスオプスは営業に報告します。CSオプスはカスタマーサクセスに報告します。

このモデルは、会社が正式にRevOpsを設立する前によく見られます。

最適な状況: スピード、機能上の文脈、そして各部門が手厚い運用サポートを必要とする初期段階のチーム。

強み:

• オペレーターが支援先のチームの近くにとどまる。
• 依頼への対応が速い。
• 機能上のニュアンスを理解しやすい。
• リーダーは自分たちの運用キャパシティを直接所有していると感じる。

リスク:

• 定義が分断される。
• ツールが乱立する。
• ダッシュボードの数値が一致しなくなる。
• 部門横断的な引き継ぎに中立的なオーナーがいない。
• 各オプス担当者が自分のリーダーの指標のために最適化してしまう。

埋め込み型オプスは、強力なガバナンスがある場合には機能し得ます。ガバナンスがなければ、しばしばRevOpsが解決すべきまさにその問題、つまり各チームが独自バージョンのファネルを運用する状態を生み出します。

モデル3: ハイブリッド型RevOps

ハイブリッドモデルは、中央のガバナンスと機能的な近さを組み合わせます。

中央のRevOpsリーダーが収益オペレーティングモデル、データガバナンス、システム基準、ダッシュボード、部門横断的なリズムを所有します。機能別のオプスパートナーはマーケティング、営業、CSの近くに配置されますが、共有のRevOps基準に従います。

最適な状況: 標準化と機能的なスピードの両方を必要とするミッドマーケット企業。

強み:

• 共有の定義が守られる。
• 各部門は引き続き手厚い支援を受けられる。
• 専門家が文脈を保てる。
• 部門横断的な意思決定にオーナーがいる。
• 一つの中央窓口よりもモデルが拡張しやすい。

リスク:

• 意思決定権限があいまいになり得る。
• 各部門のリーダーがガバナンスを迂回することがある。
• 中央のRevOpsが権限を持たない助言役になり得る。
• 憲章が弱いと、埋め込まれたパートナーが漂流し得る。

ハイブリッドは、明文化された憲章があって初めて機能します。誰がフィールドの変更、ダッシュボードの定義、ライフサイクルの変更、システム連携、引き継ぎルールを承認するのかを明記すべきです。

成長段階別のチーム構成

会社の成長段階は目安に過ぎません。複雑なエンタープライズ営業、パートナー、更新を抱える90人の会社は、シンプルなプロダクト主導モーションを持つ200人の会社よりも早くRevOpsを必要とするかもしれません。

真のシグナルとして、運用上の複雑さを使ってください。

報告ラインの選択肢

RevOpsがどこに報告するかは、その機能がどう認識されるかを左右します。

最もクリーンな報告ラインは通常CRO、COO、CEOです。誤った答えは常に特定の役員というわけではありません。誤った答えは、RevOpsが部門横断的なシステムを統治すると期待されながらも、一つの部門に属するものと見なされている、いかなる報告ラインです。

RevOpsの中核となる役割

RevOpsリード。 オペレーティングモデル、優先順位、ガバナンス、部門横断的な連携を所有します。この人物は、戦略をプロセスおよびシステム要件に翻訳できる必要があります。

CRMまたはシステムのオーナー。 中核となる収益プラットフォーム、フィールド、自動化、権限、連携、変更管理を維持します。

収益アナリスト。 レポーティングロジック、ダッシュボードの質、ファネル分析、予測サポート、パフォーマンス診断を所有します。

マーケティングオプスパートナー。 キャンペーンオペレーション、リードソースガバナンス、スコアリングのインプット、マーケティングオートメーション、アトリビューションの衛生管理を所有します。

セールスオプスパートナー。 営業プロセス、テリトリールール、クォータサポート、パイプラインの衛生管理、営業ツール、担当者の生産性分析を所有します。

CSオプスパートナー。 オンボーディングワークフロー、更新データ、顧客ヘルスのインプット、拡大トリガー、契約後のレポーティングを所有します。

ほとんどの会社は、この6つすべてを一度に採用するわけではありません。最初の採用は最大のボトルネックに合わせるべきです。CRMが信頼されていないなら、ダッシュボードアナリストだけを採用してはいけません。引き継ぎが壊れているなら、Salesforce管理者だけを採用してはいけません。経営陣に収益オペレーティングモデルが欠けているなら、単にレポートするだけでなくシステムを設計できるオペレーターを採用してください。

意思決定権限とRACI

RevOpsには責任だけでなく権限が必要です。

RACIマトリクスは、誰が作業を行い、誰が説明責任を負い、誰が相談を受け、誰が報告を受けるかを分離するため有用です。意思決定の比重が大きい業務では、RACI対RASCI対DACIの違いも重要になります。RevOpsはしばしば、タスクの所有と意思決定の所有の両方を必要とします。

この表そのものより、習慣化することの方が重要です。繰り返し発生するすべてのRevOpsの意思決定には、一人の説明責任者がいるべきです。

構成が崩れないようにする方法

運用ルールが非公式のままだと、構成は崩れます。

一元型RevOpsチームには、単なるチケット対応窓口にならないよう、受付ルールが必要です。どの依頼が緊急か、どれが月次ガバナンスレビューに含まれるべきか、どれが共有データの質を損なうため却下されるべきかを定義してください。

埋め込み型モデルには基準が必要です。マーケティングオプス、セールスオプス、CSオプスは自分たちのチームの近くに配置されてよいですが、ライフサイクルステータス、ソース、予測カテゴリー、顧客引き継ぎフィールドについて別々の定義を作るべきではありません。

ハイブリッドモデルには憲章が必要です。機能別パートナーは、いつローカルに行動してよいか、いつ変更に中央の承認が必要かを知る必要があります。それがなければ、ハイブリッドは両モデルの最悪の部分を併せ持つことになります。中央のRevOpsは基準について責められる一方、埋め込まれたチームは静かにシステムを変更してしまいます。

ほとんどのミッドマーケットチームにとって、実践的なルールはシンプルです。定義、データモデル、システムガバナンス、経営層向けレポーティングは一元化してください。ワークフローの詳細は、それを日々使う部門の近くにとどめてください。

実践的なミッドマーケット構成

150人規模のB2B企業は、しばしば大きな部門ではなく、小さなハイブリッドチームを必要とします。

構成は次のようになり得ます。

• CROまたはCOOに報告するRevOps責任者
• CRMまたはシステムのオーナー
• 収益アナリスト
• マーケティングオプスパートナー（フルタイムまたは兼任）
• セールスオプスパートナー（フルタイムまたは兼任）
• CSオプスのカバー（更新が複雑になるまでは多くの場合パートタイム）

これにより、会社は定義とダッシュボードを守るのに十分な中央のガバナンスを持ちながら、実務を行うチームの近くに機能的なワークフローの知見をとどめられます。RevOps責任者は運用ロードマップを所有すべきです。システムオーナーはデータの質とワークフローの信頼性を守るべきです。アナリストはパフォーマンスを可視化すべきです。機能別パートナーは、そのモデルがプロセス文書の中だけでなく、実際のチームの行動の中で機能することを確認すべきです。

その構成でもまだ重すぎると感じるなら、まずはRevOpsリードとシステムに強いアナリスト1名から始めてください。依頼件数、レポーティングの需要、引き継ぎの複雑さがそれを正当化する段階になったら、機能別パートナーを追加してください。

依頼受付モデル

すべての依頼がサイドチャネルを通じてRevOpsに届くと、チーム構成は崩れます。

サポートタスクと運用上の変更を分離する受付モデルを使ってください。

これにより、チームが単なる依頼対応窓口になることを防ぎながら、緊急の作業は動き続けられます。一元型チームには、すべての依頼が一箇所に集まるため、これが必要です。ハイブリッドチームには、埋め込まれたパートナーがそうでなければ共有基準を迂回してしまい得るため、これが必要です。

チーム規模別のオペレーティングモデル

組織図よりも運用リズムの方が重要です。

小規模なチームには徹底したフォーカスが必要です。一人の人間が、すべてのダッシュボード、CRMの依頼、予測の課題、引き継ぎの問題、経営層向け分析の依頼を同じ質で所有することはできません。憲章は最も価値の高い業務を明示し、そのための時間を守るべきです。

構成の見直しが必要な兆候

同じ運用上の問題が繰り返される場合、RevOps構成を見直してください。

よくある兆候:

• チームが時間の大半をチケット対応に費やしている。
• 営業、マーケティング、CS、ファイナンスが依然として異なる定義を使っている。
• 経営陣が主要なレビューのたびに手作業のレポーティングを求める。
• 埋め込まれたオプスパートナーが、共有ダッシュボードを壊す変更を行う。
• 中央のRevOpsが日々のワークフローの詳細からあまりに遠い。
• 予測、アトリビューション、引き継ぎをめぐる対立が経営陣へのエスカレーションを繰り返す。
• システムの変更は速く出荷されるが、下流の後始末を生み出す。

これらの兆候はすべてが一元化を指し示すわけではありません。時にはより明確な憲章が解決策です。時には機能的な埋め込みです。時にはより強力なシステムオーナーです。適切な変更は、運用上の失敗がどこにあるかによって決まります。

よくある採用の過ち

アナリストが必要なのにオペレーターを採用しない、あるいはその逆をしてしまう。 アナリストは問題を見つけられます。オペレーターは、問題が繰り返されなくなるようワークフロー、意思決定権限、システムを再設計します。

プロセスオーナーが必要なのにSalesforce管理者を採用してしまう。 システムのスキルは価値がありますが、CRM管理者一人に収益オペレーティングモデルの定義を期待すべきではありません。

RevOpsの採用が遅すぎる。 予測が信頼されず、アトリビューションが政治的になり、CSの引き継ぎが壊れる頃には、対応はより難しくなります。システムが深刻に混乱する前の方が、RevOpsは安く済みます。RevOpsを採用すべきタイミングのシグナルは、通常その時点よりずっと前に現れます。

権限を伴わずにRevOpsへ責任だけを負わせる。 RevOpsがデータ品質に説明責任を負いながら、フィールドルールやシステムの変更管理を強制できないなら、その使命はパフォーマンスにすぎません。

成熟段階の組織図をそのまま真似てしまう。 小さな会社に、RevOps担当VP、4人のマネージャー、ガバナンス評議会は必要ありません。必要なのは、明確な所有、シンプルなライフサイクル、規律ある引き継ぎです。

モデルの選び方

次の場合は一元型RevOpsを選んでください。

• 複数のチームが同じ収益データに依存している。
• ダッシュボードの数値がしばしば一致しない。
• ツール選定により強いガバナンスが必要。
• 経営陣が収益運用の質に対して一人のオーナーを求めている。

次の場合は埋め込み型オプスを選んでください。

• 会社が初期段階である。
• 標準化よりも機能的なスピードが重要。
• ファネルがシンプルである。
• リーダーが非公式に連携を維持できる。

次の場合はハイブリッド型RevOpsを選んでください。

• 共有ガバナンスと機能上の文脈の両方が必要。
• マーケティング、営業、CSがそれぞれ意味のある運用ニーズを持つ。
• 会社に複数のモーションまたはセグメントがある。
• 中央のRevOpsだけではボトルネックになってしまう。

FAQ

RevOpsはどこに報告すべきか

RevOpsは通常、CRO、COO、CEOのような部門横断的なリーダーの下で最もうまく機能します。営業やマーケティングだけに報告すると、他のチームからの信頼が弱まる可能性があります。

最初のRevOps採用は何か

最初の採用は、プロセスを定義し、CRMの衛生管理を改善し、使えるレポーティングを構築し、マーケティング、営業、CS、ファイナンスにまたがって働ける実践的なRevOpsオペレーターであるべきです。ボトルネックが明らかに技術的なものでない限り、狭すぎる採用は避けてください。

一元型と埋め込み型のどちらのRevOpsが必要か

標準化と信頼が最大のニーズであるときは一元型RevOpsを使ってください。スピードと機能上の文脈がより重要なときは埋め込み型オプスを使ってください。会社が両方を必要とするときはハイブリッドを使ってください。

RevOpsは営業・CS連携をどう支えるか

RevOpsは、営業とCSが一つの顧客ライフサイクルを運用できるよう、受注後の引き継ぎ、必要な顧客の文脈、更新データ、エスカレーションパスを定義します。より広いオペレーティングモデルについては営業・CS連携を参照してください。

関連記事

• Revenue Operationsフレームワーク
• RevOps対セールスオプス
• マーケティング・営業連携
• SaaS成長ステージ
• 受注からオンボード完了までの引き継ぎプロセス