RevOpsを採用すべきタイミング: 収益システムにオーナーが必要な兆候

ほとんどの企業は、痛みがすでに高くついた状態になってからRevOpsを採用します。

マーケティングとセールスがリードの質について言い争っています。フォーキャストの会議は古い商談で溢れています。カスタマーサクセスは不完全な受注後の引き継ぎ情報を受け取っています。財務はCRMの外で収益レポートを作り直しています。会社はついに「RevOps担当の誰か」が必要だと判断します。

その採用は助けにはなりますが、その頃にはシステムはすでに乱れています。

RevOpsを採用するより良いタイミングは、収益の動き方が非公式な連携だけでは回らないほどクロスファンクショナルになったときです。

RevOpsは、すべての企業が最初に必要とするオペレーション採用ではありません。収益システムが共有されすぎて、単一の部門だけでは解決できなくなったときに必要になる採用です。

Forresterの収益オペレーション責任モデルは、RevOpsを成長エンジン全体の連携という観点で捉えています。それこそがこの採用の目的です。レポート担当者をもう一人増やすことではなく、共有システムにオーナーを与えることです。

押さえておくべき運用上の事実

• 収益の問題がチームの境界を越えるとき(ライフサイクル、信頼できる情報源、ルーティング、引き継ぎ、フォーキャスト、既存顧客の拡張、レポートへの信頼など)にRevOpsを採用してください。
• 早すぎる採用は、権限のない肩書だけを生みかねません。遅すぎる採用は、後始末という負債を生みます。
• 最初のRevOps採用者は、ダッシュボードへの責任だけでなく、共有オペレーティングシステムに対する権限を持つべきです。
• 痛みが単一の部門内に留まっている場合は、Sales Ops、Marketing Ops、CS Opsのほうが最初の採用として適していることがあります。

端的な答え

収益の問題がもはや一つのチームだけのものではなくなったときに、RevOpsを採用してください。

セールスプロセスの問題はSales Opsで対応できます。キャンペーンの運用はMarketing Opsで対応できます。オンボーディングプロセスはCS Opsで対応できます。RevOpsが必要になるのは、問題がチーム間にまたがるとき、つまりライフサイクルの定義、引き継ぎ、信頼できる情報源、フォーキャストへの信頼、アトリビューション、収益のケイデンスに関わるときです。

役割の違いについては、RevOps対Sales OpsとRevOps対Marketing Ops対Sales Opsをご覧ください。

採用判断テスト

このポジションを募集する前に、このテストを使ってください。

役割はシステムの痛みに合わせるべきです。肩書が立派に聞こえるという理由でRevOpsを採用しないでください。会社が共有の収益オペレーティングオーナーを必要としているという理由で採用してください。

強い採用シグナル

以下のうちいくつかが当てはまるなら、RevOpsを採用する準備ができています。

• マーケティングとセールスが、何をもって「有望」とするかで意見が一致しない。
• リードルーティングのルールが不明確、または古くなっている。
• 営業担当者がリードスコアリングを信用していない。
• マネージャーが商談ステージのデータを信用していない。
• 財務がフォーキャストや収益レポートのためにシャドースプレッドシートを使っている。
• カスタマーサクセスが不完全な引き継ぎ情報を受け取っている。
• キャンペーンのROIを収益と明確に結び付けられない。
• CRMのフィールドがガバナンスなしに追加されている。
• 一つのチームのツール選定が、別のチームに影響を及ぼしている。
• 収益に関する会議のほとんどがデータの突き合わせに費やされている。

これらは「ダッシュボードをもっと増やす」だけでは解決しない問題です。これらは運用上のオーナーシップの問題です。

ステージ別ガイド

企業規模は複雑さほど重要ではありません。40名のエンタープライズSaaS企業のほうが、シンプルなセルフサーブモーションを持つ200名の企業よりも、RevOpsを早く必要とすることがあります。

真のシグナルとして運用の複雑さを見てください。

トリガー1: リードの引き継ぎで収益が漏れている

最初によくあるトリガーは、リードの引き継ぎの失敗です。

マーケティングがリードを作成します。セールスは一貫してフォローアップしません。SDRは構造化された理由なしにリードを却下します。ルーティングルールがテリトリーやセグメント戦略と合っていません。キャンペーンレポートはボリュームを示しますが、パイプラインレポートはほとんど動きを示しません。

この時点で、問題はマーケティングの質やセールスの規律だけではありません。引き継ぎのシステムそのものです。

RevOpsは以下を定義できます。

• MQLとSQLの基準
• リード割り当てルール
• 受諾・却下のワークフロー
• SLAとエスカレーションの経路
• ソースから商談までのレポーティング
• 月次のリード品質レビュー

リードから商談への流れが繰り返し議論の的になっているなら、その会社はおそらくRevOpsのオーナーシップを必要としています。

トリガー2: フォーキャストへの信頼が崩れている

2つ目のトリガーは、フォーキャストへの不信です。

セールスはフォーキャストが現実的だと言います。財務はそこに割引を掛けます。CEOは別の見方を求めます。マネージャーはフォーキャストの会議のほとんどを、クローズ予定日やステージ名の整理に費やします。パイプラインは書類上は十分にありますが、数字が実際にクローズしません。

これは、より良いスプレッドシートで解決できることはほとんどありません。フォーキャストの質は、ステージ定義、クローズ予定日の衛生状態、コミット基準、マネージャーによる点検、CRMのデータ品質に左右されます。

CIO DiveがまとめたGartnerの調査によると、フォーキャストの精度に高い自信を持つ営業リーダーおよび営業担当者は半数にも満たないことがわかりました。RevOpsは、フォーキャストの質を単なるセールスの判断の問題としてではなく、システムの問題として扱うことで役立ちます。

トリガー3: カスタマーサクセスが不完全な情報を引き継いでいる

カスタマーサクセスが「これが約束されていたとは知らなかった」と繰り返し口にするなら、その会社にはより強固な受注後の運用ガバナンスが必要です。

受注(クローズドウォン)は収益の終わりではありません。オンボーディング、活用、更新、拡張の始まりです。RevOpsは、セールスが売り込んだ顧客の背景情報が、CSが活用できる構造化されたデータになるようにするべきです。

これには以下が含まれます。

• ユースケース
• 成功基準
• ステークホルダー
• 契約範囲
• 約束した内容
• 導入リスク
• 更新日
• 拡大シグナル

これはセールス・CSアラインメントとRevOpsとカスタマーサクセスに直接つながります。

トリガー4: 財務が収益データを信用していない

財務の不信は深刻なシグナルです。

財務がパイプライン、受注、アトリビューション、フォーキャストの数字を収益システムの外で作り直しているなら、その会社は信頼できる情報源の問題を抱えています。その問題は会社の成長とともに悪化していきます。

RevOpsは財務に取って代わるものではありません。財務は計画と財務報告を所有します。RevOpsは、その計画を点検可能にするオペレーティングデータとプロセスを所有します。

パートナーシップのモデルについてはRevOpsと財務をご覧ください。

採用が早すぎる場合

早すぎる採用は別の問題を生みます。会社がまだ十分に学習していない段階でのプロセスのオーバーヘッドです。

以下に当てはまるなら、早すぎるかもしれません。

• 創業者一人がセールスの大部分をいまだに担っている。
• マーケティングがまだ本当の獲得チャネルになっていない。
• CRMに意味のあるレコードが数百件にも満たない。
• セールスプロセスが毎月変わっている。
• 経営陣がガバナンスよりもまだ発見的な検証を必要としている。

その場合は、軽量な収益オペレーションフレームワークを使いつつ、過剰に作り込まないようにしてください。

最初の運用オーナーは、Sales Opsのジェネラリスト、マーケティングオペレーションの契約者、あるいは創業者のオペレーターでも構いません。目標は、不要なガバナンスを生み出さずにシステムを可視化された状態に保つことです。

採用が遅すぎる場合

採用が遅すぎるケースのほうがより一般的です。

遅すぎるシグナルには以下が含まれます。

• フォーキャストの外れが営業担当者の判断のせいにされているが、実際にはステージ定義が弱い。
• リードをめぐる対立が毎月起きている。
• 後始末なしにはソースから収益までのパフォーマンスを誰も説明できない。
• CSのチャーン分析が資格基準にまでたどり着かない。
• 収益部門のリーダーがもはやオペレーティングデータを信用していない。

この段階では、最初のRevOps採用者はシステムを改善する前に、何カ月もかけて過去の混乱を解きほぐすことになります。

遅い採用が高くつくのは、崩れた定義のすべてがレポート、ダッシュボード、ワークフロー、チームの習慣に埋め込まれてしまうからです。

どのタイプの採用が必要か

すべてのRevOps採用が同じ問題を解決するわけではありません。

オペレーティングモデルを設計できる人が必要なら、ダッシュボードアナリストだけを採用しないでください。CRMのクリーンアップが必要なら、戦略リーダーだけを採用しないでください。採用をボトルネックに合わせてください。

「導入前・導入後」テスト

有効なテストは、採用から6カ月後に何が目に見えて変わっているべきかを言葉にしてみることです。

答えが「ダッシュボードが良くなる」だけなら、その役割はおそらくスコープが小さすぎます。ダッシュボードは重要ですが、それはより明確な定義、より良いフィールド、より強固な引き継ぎ、そして点検を促すケイデンスの結果にすぎません。

実際のRevOpsの導入前・導入後は、次のようになるかもしれません。

このテストは、採用の判断をビジネスの変化に結び付けます。また、最初の採用者が単なる受け身のサービスデスクになってしまうことを防ぎます。

採用タイミングのチェックリスト

会社が今すぐ採用すべきか待つべきか迷っているときは、このチェックリストを使ってください。

• 少なくとも3人の収益部門のリーダーが同じデータに依存していますか?
• 引き継ぎのミスが、測定可能なパイプラインの喪失、遅延、チャーンリスク、手戻りを生んでいますか?
• 会議が決定ではなく定義の議論を繰り返していますか?
• システムの変更が、誰も所有していない下流への影響を生んでいますか?
• 手作業のレポーティングが、計画やマネジメントの意思決定を遅らせるほどの時間を取っていますか?
• 一人のクロスファンクショナルなオーナーがいれば、複数のチームにまたがる摩擦が減るでしょうか?

ほとんどの答えが「はい」なら、待つことのコストのほうが採用のコストより高くなる可能性が高いです。

痛みを感じているのが一つのチームだけなら、まずはそのチーム内の運用ギャップを解決してください。それはSales Ops、Marketing Ops、CRM管理者、あるいは契約者を意味するかもしれません。RevOpsは、共有された運用オーナーシップが制約になったときに登場するべきです。

待つことのコスト

待つことが常に間違っているわけではありません。しかし、痛みがすでにクロスファンクショナルになっているなら、待つことにはコストが伴います。

採用の問いは、RevOpsが役に立つかどうかだけではありません。会社がすでに、無駄になったマネジメントの時間、失われたコンバージョン、遅れたフォーキャストの意思決定、顧客引き継ぎの手戻りという形で、弱い運用オーナーシップの代償を払っているかどうかです。

採用前の30日間の検証

経営陣が迷っているなら、職種名について議論する代わりに、30日間の検証を実施してください。

パートタイムでも構わないので一人のオーナーを割り当て、次の4つのアウトプットを出してもらいます。

1. リードから更新までのライフサイクルマップ
2. 繰り返し発生している引き継ぎまたはレポーティングの対立トップ5のリスト
3. リード、商談、受注案件、更新リスクのある顧客にまたがるレコード監査
4. ビジネスへの影響を見積もった優先順位付きのRevOpsロードマップ

この短期プロジェクトで、どの部門も所有していないクロスファンクショナルな混乱が明らかになれば、RevOpsを採用する根拠はより強固になります。もし見つかった内容が主にセールス、マーケティング、CSの内部に留まるものであれば、まずはより狭い範囲のオペレーション職を採用または割り当ててください。

今採用するか、待つか、役割を絞るか

この判断テーブルを使ってください。

最悪の選択は、クロスファンクショナルな成果を期待しながら、ダッシュボードだけの権限でRevOpsを採用することです。それは双方に失望を生みます。

職務記述書に何を書くべきか

多くのRevOpsの職務記述書は範囲が広すぎます。システム管理、ビジネスインテリジェンス、報酬設計、フォーキャスト、GTM戦略、キャンペーン運用、データエンジニアリング、イネーブルメント、経営層向けレポーティングを、一つの役割に詰め込んで求めています。

それは時間をかけて発展する「機能」としてのRevOpsを描写しているかもしれません。しかし、最初の一人の採用を描写するものであってはなりません。

より整理された職務記述書には、以下を含めるべきです。

• その人が支援する収益の動き
• その人が引き継ぐことになる主な運用上の問題
• その人が統治するシステム
• その人が改善する引き継ぎ
• その人が評価される指標
• その人が持つ意思決定権
• 最初の90日間で期待されるアウトプット

たとえば、本当の問題がリードの漏れなら、そう書いてください。本当の問題がフォーキャストへの信頼なら、そう書いてください。本当の問題がCRMガバナンスなら、そう書いてください。最も優秀な候補者は、洗練された一般的なRevOpsの責任リストではなく、本当の運用上の問題を求めています。

職務記述書には、RevOpsが所有しないものも書くべきです。クォータ、パイプライン創出、受注率、リテンション、拡張戦略は、引き続き収益部門のリーダーが所有します。RevOpsは、それらの成果を可視化しガバナンス可能にするオペレーティングシステムを所有します。

ビジネスケース

RevOpsのビジネスケースは、通常「レポートを作る人を採用する」ではありません。

それは以下のようなものです。

• パイプラインの漏れを減らす。
• フォーキャストへの信頼を高める。
• 収益に関する会議を短縮する。
• リードの受諾率を改善する。
• 手作業のレポーティングを減らす。
• 受注後の引き継ぎの質を改善する。
• 収益データを計画に使えるようにする。

最も強いビジネスケースは、RevOpsの仕事をいくつかの測定可能な漏れに結び付けます。たとえば、SLAを超えて放置されたリード、クローズ予定日が古いままの商談、オンボーディングデータが欠けている受注案件、手作業での突き合わせが必要なパイプラインレポートなどです。

アーリーステージのチームにとって、一つの強いビジネスケースはマネージャーの時間です。すべての収益に関する会議で、本題に入る前にリーダーがレポートを突き合わせる必要があるなら、会社は弱い運用設計を補うために上級人材にお金を払っていることになります。RevOpsの採用は、証拠を作り直すのではなく意思決定を点検できるほどシステムを明確にすることで、その繰り返される作業を取り除くべきです。

6カ月後の成功の姿

良い最初の6カ月は、全面的な作り直しではありません。収益チームの回り方を変える、少数の高い信頼を得られる改善です。

強いシグナルには以下が含まれます。

• リードから更新までの、合意されたライフサイクルマップが一つある
• 明確な意思決定権を持つ、簡潔なRevOps憲章がある
• ガバナンスを経ないフィールドやワークフローの変更が減っている
• データをめぐる議論が少ない、よりクリーンなフォーキャストの会議
• 手作業のクリーンアップを求めずにリーダーが使えるダッシュボード
• 文書化された受注後の引き継ぎ
• 依頼のバックログではなく、優先順位付けされたロードマップ

最も重要な変化は信頼です。リーダーたちは戦略について意見が分かれ続けるかもしれませんが、数字が何を意味するかについて言い争うのはやめるはずです。

だからこそRevOpsの採用タイミングが重要なのです。繰り返し可能なプロセスが何もない段階で採用すれば、その役割はオーバーヘッドを生みます。オペレーティングシステムがすでに信頼を失った後で採用すれば、その役割は修復モードから始まります。最良のタイミングは、複雑さが本物になり、痛みがチームをまたぎ、経営陣が一人のオーナーにシステムを直す権限を与える準備ができたときです。

よくある質問

最初のRevOps採用者は技術系であるべきですか?

CRMやデータフローを理解できる程度のシステムへの精通は必要ですが、最初の採用者はまずオペレーターであるべきです。プロセス設計、意思決定権、クロスファンクショナルな信頼のほうが、純粋な管理スキルよりも重要です。

Sales OpsはRevOpsになれますか?

権限が拡大するのであれば、なれます。その人は、単なる新しい肩書ではなく、マーケティング、セールス、CS、財務、システムにまたがる権限を必要とします。

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

通常はCRO、COO、CEO、またはその他のクロスファンクショナルなリーダーです。セールスやマーケティングだけに報告する体制は、中立性を弱めます。

待つことのリスクは何ですか?

待てば待つほど、崩れた定義、シャドースプレッドシート、手作業の回避策、レポートへの不信が、通常の運用行動として定着していきます。

さらに詳しく

• 初めてのRevOps採用
• RevOpsチーム体制
• RevOps憲章
• リードルーティングの自動化