Revenue Operationsフレームワーク: フルファネルのオペレーティングシステムを設計する方法

RevOpsが失敗するのは、企業がそれをレポーティングチームとして扱うときです。

このパターンはよくあります。企業が優秀なオペレーターを採用し、CRMへのアクセスを与え、より良いダッシュボードを求めます。ダッシュボードは一四半期は改善します。しかし、同じ問題が戻ってきます。リードの定義が揺らぎ、営業ステージが一貫性なく使われ、予測会議は後始末のセッションに変わり、カスタマーサクセスは依然として不完全な引き継ぎを受け取ります。

問題はレポーティングのスキルではありません。問題はフレームワークの設計です。

有用なRevenue Operationsフレームワークは、戦略、ファネルアーキテクチャ、プロセス、データ、システム、指標、リズム、説明責任にわたって、会社がどのように収益を運用するかを定義します。それは、バラバラな症状を追いかける代わりに、収益システム全体を監査する方法をリーダーに与えます。

この記事はRevenue Operationsとは何かの上に構築されています。要約すると、RevOpsはマーケティング、営業、カスタマーサクセス、ファイナンス、データ、システムにまたがるオペレーティングレイヤーです。もし自社がこの取り組みをGTMモーション設計として捉えているなら、GTMオペレーション対Revenue Operationsが両者の重なりを説明しています。以下のフレームワークは、その定義を実用的なモデルに変えるものです。

Forresterのオペレーティングモデルに関する調査も別の角度から同じ点を指摘しています。Revenue Operationsに必要なのはオペレーティングモデルであり、単なる新しいチーム名やレポーティング構造ではありません。

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

• RevOpsフレームワークは、戦略、ライフサイクル、プロセス、データ、システム、指標、リズム、説明責任にわたって、会社がどのように収益を運用するかを定義すべきです。
• レイヤーは順番に構築してください。ダッシュボードと自動化は、ステージの定義、プロセスルール、データガバナンスの後に続くべきです。
• このフレームワークは、獲得、営業、カスタマーサクセス、更新、拡大をカバーすべきです。
• このフレームワークを監査ツールとして使ってください。ツール、レポート、組織再編を修正策として選ぶ前に、どのレイヤーが弱いかを見つけてください。

6層のRevOpsフレームワーク

ほとんどのRevOpsの問題は、これらのレイヤーを順不同で構築することから生まれます。ステージの定義より前に構築されたダッシュボードは、混乱を解決するのではなく露呈させます。SLAルールより前に追加された自動化は、壊れた引き継ぎを加速させます。ガバナンスを伴わずに追加されたCRMフィールドは、もう一つの一貫性のないデータポイントになります。

このフレームワークは順序を強制します。戦略はファネル設計に情報を与えます。ファネル設計はプロセスに情報を与えます。プロセスはデータモデルを定義します。データは指標を信頼できるものにします。指標はリズムに反映されます。リズムは説明責任を生み出します。

フレームワークを監査として使う方法

このフレームワークは、白紙の設計演習としてではなく、現在のオペレーティングシステムに対して使われるときに最も有用です。

最近の収益パスを一つ選び、6つのレイヤーすべてを通して確認してください。例えば、インバウンドのデモ依頼を5件、アウトバウンドの商談を5件、受注案件を5件、更新リスクのある顧客を5件選んでください。各記録について、同じ問いを立ててください。

この監査により、フレームワークは具体的になります。リードがICPに合致しているのに適切な担当者に届かないなら、弱いレイヤーはプロセスとSLAです。受注顧客が成功基準のないままオンボーディングに達するなら、弱いレイヤーはデータと引き継ぎ設計です。リーダーが問題を見ていたのに誰も意思決定をしなかったなら、弱いレイヤーはリズムです。

診断スコアカード

次のRevOpsプロジェクトを選ぶ前に、シンプルなスコアカードを使ってください。

各レイヤーを1から5でスコアリングしてください。最も低いレイヤーが、通常繰り返される痛みを説明します。

例えば、指標が4点でファネルアーキテクチャが2点なら、ダッシュボードの再構築から始めないでください。そのダッシュボードは、おそらく不明瞭なステージの挙動を報告しているだけです。プロセスが2点、データが2点なら、まだ自動化しないでください。自動化は、質の悪い記録をより速く動かすだけです。

修正の優先順位の付け方

RevOpsチームはしばしば、ダッシュボードの依頼、フィールドのクリーンアップ、ルーティングの修正、アトリビューションをめぐる対立、予測への不満、ツールの変更といった長いバックログを引き継ぎます。このフレームワークは、システムへの影響でそのバックログを順位付けする助けになります。

次の条件のうち少なくとも2つを満たす作業を優先してください。

• 複数の収益機能に影響する。
• リーダーが週次または月次で下す意思決定を変える。
• 予測、パイプライン、引き継ぎ、更新への信頼を改善する。
• 繰り返しの手作業のクリーンアップをなくす。
• 悪いデータがシステムに入るのを防ぐ。
• 顧客に見える摩擦を減らす。

見た目だけのもの、一人のマネージャーにしか当てはまらないもの、一度きりしか役に立たないものは優先度を下げてください。単発の取締役会向けデータ抽出は緊急かもしれませんが、統治されたレポーティングモデルの一部にならない限り、フレームワークの改善にはなりません。

レイヤー1: 収益戦略

収益戦略は、最初の運用上の問いに答えます。成長はどこから生まれるべきか、という問いです。

RevOpsは戦略を単独で所有しません。CEO、CRO、CMO、VP営業、CSリーダー、ファイナンスリーダーが戦略上の判断を下します。RevOpsはその判断を運用上の要件に変換します。

戦略レイヤーは次を定義すべきです。

• ICPと非ICPの境界
• ターゲットセグメントと優先アカウント
• インバウンド、アウトバウンド、パートナー、拡大、プロダクト主導などの営業モーションのミックス
• 平均契約額の帯
• セグメントまたはモーション別の成長目標
• チーム別のキャパシティの前提
• 継続と拡大の期待値

このレイヤーがなければ、RevOpsは受動的になります。リードをルーティングし、ダッシュボードを構築し、フィールドを維持することはできますが、それらのシステムが現在の成長モデルを支えているかどうかを判断できません。

例: 会社がSMBインバウンドからミッドマーケットアウトバウンドに移行する場合、RevOpsはアカウントフィールド、リードスコアリング、ルーティング、パイプラインステージ、予測点検、オンボーディング引き継ぎデータを変更しなければなりません。戦略がシステム要件に翻訳されなければ、古いファネルが新しい戦略の下でも動き続けます。

マッキンゼーのB2B成長に関する調査は、統合されたデータ、高度なアナリティクス、商業チーム間の運用上の連携を、より強いB2Bパフォーマーを分ける要素の一部として指摘しています。RevOpsは、その連携が運用上の作業になる場所です。

レイヤー2: ファネルアーキテクチャ

ファネルアーキテクチャは、最初の接点から更新までの収益のライフサイクルを定義します。

このレイヤーは、RevOpsがステージを文書化し、あいまいさを取り除く場所です。優れたファネルアーキテクチャには次が含まれます。

• ステージ名
• ステージの定義
• 参入基準
• 退出基準
• 主なオーナー
• 必須フィールド
• SLAまたはタイミングルール
• 次のシステムアクション

シンプルな獲得ファネルは、訪問者からリード、MQL、SQL、商談、受注、オンボード完了、アクティブ顧客、更新、拡大へと進むかもしれません。より複雑な会社は、モーションやセグメントで分割するかもしれません。いずれにせよ、規律は同じです。単に有用に聞こえるという理由だけで存在するステージはあってはいけません。

リードの受け入れについては、これはリード管理対CRMに直接つながります。CRMは記録を保存します。リード管理は、その記録がどう動くべきかを定義します。RevOpsは、この二つが一致するようにします。

ファネルアーキテクチャの最良のテストは、新しいマネージャーが10件の記録を点検し、それぞれの記録がなぜ現在のステージにあるのかを正確に理解できるかどうかです。そうでないなら、そのアーキテクチャは曖昧すぎます。

レイヤー3: プロセスとSLA設計

プロセスはファネルステージを実際の作業に変えます。

RevOpsは、チーム間で収益を移動させる主要なワークフローを文書化すべきです。

• リードのキャプチャとエンリッチメント
• リードの割り当てと受け入れ
• MQLからSQLへの引き継ぎ
• 商談の作成
• パイプライン点検
• 見積もりまたは提案の承認
• 受注後の引き継ぎ
• オンボーディングキックオフ
• 更新リスクのエスカレーション
• 拡大トリガーのルーティング

各ワークフローにはSLAが必要です。SLAは複雑である必要はありません。誰が、いつまでに、どのデータをもとに行動し、行動しなかった場合どうなるかに答えるだけで十分です。

リード割り当てSLAは良い例です。担当者に割り当てられたリードは、担当者が会議に出ていた、あるいはルーティングルールが不明確だったという理由で放置されるべきではありません。プロセスは、割り当てのタイミング、受け入れ基準、エスカレーション、再割り当てを定義すべきです。

プロセス設計はまた、販売後の引き継ぎ負債を防ぎます。営業からCSへの移行が、担当者が丁寧なSlackメッセージを書くことに依存しているなら、忙しい時期にその引き継ぎは劣化します。構造化された営業・CS間の引き継ぎまたは受注ワークフローは、必要な顧客の文脈を避けられないものにすべきです。

レイヤー4: データモデルとシステムガバナンス

データガバナンスは、多くのRevOpsチームが信頼を得るか失うかの分かれ目です。

収益システムには、次に関する明確なルールが必要です。

• ステージ別の必須フィールド
• フィールドの定義
• 各フィールドをどのシステムが所有するか
• どの役割が重要なフィールドを編集できるか
• 重複がどう処理されるか
• エンリッチメントデータがどう受け入れられるか
• 連携エラーがどう監視されるか
• システムの変更がどう依頼され承認されるか

これはそれ自体のための官僚主義ではありません。これは、予測、アトリビューション、ルーティング、レポーティングのレイヤーを静かな劣化から守るものです。

ForresterのRevOpsテクノロジー連携に関する調査は、RevOpsに移行するB2B組織が、マーケティング、営業、カスタマーサクセスのテクノロジー間で持続的な連携を必要としていると論じています。それはまさにこのレイヤーが扱うものです。CRM、マーケティングオートメーションプラットフォーム、カスタマーサクセスツール、請求システム、エンリッチメントプロバイダー、BIレイヤーが、それぞれ独立して顧客の真実を定義することはできません。

RevOpsは最低限、収益データディクショナリーを維持すべきです。それにはフィールド名、定義、所有システム、オーナー、必須となるステージ、許容される値、影響を受ける下流レポートを含めるべきです。

レイヤー5: 指標とレポーティング

指標は、リーダーに次に何を修正すべきかを伝えるべきです。

RevOpsの指標レイヤーは、3つのレポーティングビューを分離すべきです。

経営層向けダッシュボードは小さいままであるべきです。生成されたパイプライン、ステージ別のコンバージョン、パイプラインカバレッジ、予測精度、受注率、セールスサイクル、継続率、拡大、収益計画の差異があれば通常十分です。

RevOps作業用ダッシュボードはより深くてよいものです。ルーティングの失敗、リードのエイジング、SLA違反、フィールドの完全性、重複率、停滞した商談、ソース別のコンバージョン、引き継ぎの完全性を含めるべきです。

ここでパイプライン対予測が重要になります。パイプラインは潜在的な収益の在庫です。予測はある期間における期待される収益の結果です。RevOpsには両方が必要ですが、それぞれ異なる運用上の問いに答えます。

CIO Diveが要約したガートナーの調査によれば、予測精度に高い自信を持つ営業リーダーと営業担当者は半数に満たないことが示されています。これは単に営業の判断の問題ではありません。通常はデータモデル、ステージの規律、点検のリズムの問題です。

レイヤー6: リズムと説明責任

リズムはミーティングと同じではありません。

ミーティングはカレンダー上のイベントです。リズムは、インプット、オーナー、アウトプット、フォローアップを持つ、繰り返し可能な意思決定システムです。

RevOpsは、中核となる収益のリズムを定義する手助けをすべきです。

すべてのリズムには意思決定のオーナーが必要です。そうでなければ、ミーティングは運用上の変化を伴わない議論になってしまいます。

最も強いRevOpsチームは、ミーティングの目的に厳格です。予測レビューはCRMフィールドを整理する場ではありません。月次のファネルレビューは一人の担当者の停滞した商談を点検する場ではありません。システムガバナンスは会社の戦略を再議論する場ではありません。

実装の順序

RevOpsの基盤が弱い場合、次の順序で修正してください。

第一に、ライフサイクルを定義する。 リードから更新までのステージについて合意してください。参入基準と退出基準を書いてください。重複した、あるいは曖昧なステージを取り除いてください。ステージの定義を可視化してください。

第二に、引き継ぎを徹底する。 最も摩擦の大きい引き継ぎを選び、オーナーシップ、SLA、必須フィールド、エスカレーションを定義してください。通常これは、リードの割り当て、MQLからSQL、商談の作成、受注からオンボーディングを意味します。

第三に、レポーティングレイヤーをクリーンにする。 合意された定義から、最小限の有用な共有ダッシュボードを構築してください。20個のグラフから始めないでください。週次・月次の意思決定を左右する指標から始めてください。

第四に、システムの変更を統治する。 重要なフィールドをロックし、ソース・オブ・トゥルースを文書化し、変更依頼プロセスを作ってください。ほとんどのデータの劣化は、善意のローカルな変更から始まります。

第五に、リズムを改善する。 ミーティングを意思決定を中心に再構築してください。繰り返し行われるすべての収益ミーティングには、オーナー、データパケット、意思決定の種類、フォローアップログが必要です。

実用最小限のRevOpsフレームワーク

このフレームワークを使い始めるのに、エンタープライズ級のオペレーティングモデルは必要ありません。60人規模のB2B企業なら、数週間でより軽量なバージョンを適用できます。

実用最小限のバージョンには6つのアーティファクトがあります。

これで、ほとんどの運用上のギャップを明らかにするのに十分です。ライフサイクルマップが不明瞭なら、ダッシュボードから始めないでください。引き継ぎテーブルにオーナーが欠けているなら、自動化から始めないでください。必須フィールドが膨れ上がっているなら、担当者にさらなる更新を求める前にキャプチャプロセスを修正してください。

有用な最初の試みは、実際の記録から構築できます。最近のリードを10件、商談を10件、受注案件を5件、解約または更新リスクのある顧客を5件抽出してください。それぞれについて、ステージ、オーナー、必須データ、次のアクション、レポーティングソースが明白かどうかを問うてください。答えが「いいえ」であるところで、フレームワークには改善が必要です。

この記録ベースの監査は、フレームワークを誠実に保ちます。リーダーは何時間もプロセス図について議論できますが、実際の記録は、オペレーティングモデルが実際にどこで壊れているかを示します。欠落したフィールド、不明確なオーナー、停滞したステージ、記憶に依存する引き継ぎです。

その発見を使って、収益リスクで修正の優先順位をつけてください。

例: フレームワークを適用する

リード量は多いが、パイプライン創出が弱い会社を想像してください。

最初、経営陣の会話はマーケティングと営業の対立のように聞こえます。マーケティングはキャンペーンがうまくいっていると言います。営業はリードの質が悪いと言います。RevOpsは、誰が正しいかを問うことから始めるべきではありません。フレームワークを適用すべきです。

収益戦略を見ると、会社はミッドマーケットアカウントへシフトしたのに、キャンペーンのミックスは依然として中小企業をターゲットにしているかもしれません。ファネルアーキテクチャを見ると、ICPが変わった後もMQL基準が一度も更新されていないかもしれません。プロセス設計を見ると、リードが必須の業種フィールドなしに担当者にルーティングされているかもしれません。データレイヤーを見ると、フォームによってソースの値が一貫していないかもしれません。指標を見ると、MQLの量は多いのに、2つのソースからのSQL受け入れ率が低いかもしれません。リズムを見ると、月次のファネルレビューが存在せず、そのパターンはデータには現れていたのに意思決定に変わったことがなかったかもしれません。

修正策は一つのダッシュボードではありません。修正策は一連の流れです。ICP適合ルールを更新し、ルーティングのインプットを変更し、却下理由を定義し、ソースレポーティングを再構築し、マーケティングと営業が同じデータから一つの運用上の意思決定を下す月次ファネルレビューを追加することです。

これが、このフレームワークが機能すべき姿です。不満を運用上の診断に変えるのです。

よくある過ち

ダッシュボードから始めてしまう。 ダッシュボードは目に見えるアウトプットを生むため魅力的です。しかし、ライフサイクル、フィールド、定義が間違っているなら、ダッシュボードは混乱をより魅力的に見せるだけです。

壊れたプロセスを自動化してしまう。 自動化は良いワークフローを徹底するべきであり、悪いワークフローを隠すべきではありません。何がSQLとみなされるかについて誰も合意していないなら、SQLをより速くルーティングしても質をめぐる対立は解決しません。

ガバナンスなしにフィールドを追加してしまう。 すべての新しいフィールドは維持コストを生みます。定義と完全性のルールを誰も所有していないなら、そのフィールドは信頼できないものになります。

ミーティングとリズムを混同してしまう。 ミーティングを増やしても運用上の規律は生まれません。優れたリズムは、より少ないミーティングでより明確な意思決定を行います。

RevOpsをチケット対応窓口にしてしまう。 RevOpsがレポート依頼とフィールド変更への対応だけに時間を費やすなら、システムを改善できません。プロアクティブなプロセスとデータの作業のためにキャパシティを確保してください。

FAQ

Revenue Operationsフレームワークとは何か

Revenue Operationsフレームワークは、収益システム全体を運用するための構造化されたモデルです。RevOpsが統治すべきレイヤー、つまり戦略、ファネルアーキテクチャ、プロセス、データ、システム、指標、リズム、説明責任を定義します。

RevOpsは最初に何を修正すべきか

まずライフサイクルの定義を修正してください。次に引き継ぎとSLAを修正してください。ダッシュボードと自動化は、記録が収益ライフサイクルをどう動くかについて会社が合意した後に来るべきです。

RevOpsフレームワークを誰が所有するか

RevOpsはオペレーティングフレームワークを所有しますが、経営陣は戦略を所有します。CRO、CEO、ファイナンスリーダー、マーケティングリーダー、営業リーダー、CSリーダーは、RevOpsが運用可能にする成長モデルについて合意しなければなりません。

フレームワークはどのくらいの頻度で見直すべきか

フレームワークは四半期ごとに、また会社がICP、セグメントの焦点、価格設定、営業モーション、カスタマーサクセスモデル、主要な収益ツールを変更するたびに見直してください。

関連記事

• Revenue Operationsとは何か
• RevOps指標
• RevOpsチーム構成
• 予測精度
• 連携の接着剤としてのRevOps