RevOps vs セールスオペレーション：それぞれが担うものと両方が必要になるとき

成長中の会社が、最も優秀なセールスオペレーションのリーダーをRevOpsという肩書きに昇格させました。しかし他は何も変わりませんでした。

同じ人物が引き続きSalesforceのフィールド、パイプラインレポート、テリトリールール、クォータ支援、週次の予測準備を担当しています。マーケティングは相変わらずキャンペーンアトリビューションを別々に管理しています。カスタマーサクセスは相変わらず不完全な引き継ぎメモを受け取っています。財務は相変わらず予測をスプレッドシートで組み直しています。

肩書きは変わりました。ミッションは変わりませんでした。

これがRevOpsとセールスオペレーションの議論で最もよくある混乱の元です。違いは役職の高さではありません。運用範囲の違いです。

セールスオペレーションは営業チームの実行力を改善します。レベニューオペレーションは、マーケティング、営業、カスタマーサクセス、財務、データ、システムを横断する収益システム全体を改善します。

どちらの機能も価値を持ち得ます。問題は、会社がどちらの運用課題を解決する必要があるかです。

端的な答え

セールスオペレーションは、営業チームがより効果的に販売できるよう支援する機能です。パイプラインの健全性、テリトリー、クォータ、担当者の生産性、営業プロセス、ツール、コンプ支援、予測準備に重点を置きます。

RevOpsは、収益の運用システム全体を統治する機能です。マーケティング、営業、カスタマーサクセス、財務、データ、システムを、共有の定義、ライフサイクルステージ、引き継ぎ、ダッシュボード、運用リズムでつなぎます。

主な課題が営業実行であれば、セールスオペレーションが必要かもしれません。主な課題が部門横断的な収益の摩擦であれば、RevOpsが必要です。

より広い定義についてはレベニューオペレーションとは何かから始めてください。運用モデルについてはレベニューオペレーションフレームワークを使ってください。よく耳にする用語がセールスオペレーションではなくGTMオペレーションである場合は、GTMオペレーション vs レベニューオペレーションを参照してください。

重要な運用上の事実

• セールスオペレーションは営業実行を改善します。テリトリー、クォータ、パイプラインの健全性、営業プロセス、ツール、担当者の生産性です。
• RevOpsは共有の収益システムを改善します。ライフサイクル、引き継ぎ、正式なデータ源、予測ガバナンス、顧客の収益、部門横断的な運用リズムです。
• 営業実行の課題と部門横断的な収益の摩擦が同時に存在する場合、会社は両方を必要とするかもしれません。
• セールスオペレーションをRevOpsに改称しても、ミッション、範囲、意思決定権が拡張されない限りRevOpsにはなりません。

セールスオペレーションが担うもの

セールスオペレーションは営業リーダーと営業チームに最も近い立場にあります。

典型的なセールスオペレーションの責務は次のとおりです。

• 営業プロセス設計
• 営業レコードのCRM衛生管理
• テリトリーとアカウントの割り当て
• クォータ計画の支援
• パイプラインレポート
• 予測のロールアップ
• 営業コンプの支援
• 営業ツールの管理
• 担当者の生産性分析
• ディールデスクまたは承認ワークフローの支援

主な顧客は営業組織です。営業担当者が自分のアカウントを見つけられない、自分のクォータを把握していない、パイプラインステージを信頼していない、システム更新に時間をかけすぎている場合、セールスオペレーションはその運用上の摩擦を解消するチームです。

その業務は本物です。セールスオペレーションが弱い会社では、すぐにそれを実感します。テリトリーが不明確、ステージの使い方が一貫しない、パイプラインが乱雑、見積もり承認が遅い、そしてマネージャーが予測の電話で担当者にクローズ日の更新を頼んでばかりいる、といった状態です。

セールスオペレーションはRevOpsより劣った存在ではありません。より狭いミッションを持つ専門機能です。

そのニーズは管理サポート以上のものです。Salesforceの調査によると、営業担当者が実際の販売活動に費やす時間はわずか28%だと報告されています。セールスオペレーションが存在する理由の一つは、担当者の生産性が個人の仕事の習慣や手作業のシステムに任せておくには重要すぎるからです。

RevOpsが担うもの

RevOpsは、営業が依存しているものの単独では制御できない共有システムを担います。

典型的なRevOpsの責務は次のとおりです。

• ファネル全体のライフサイクル定義
• リードソース、ライフサイクル、アトリビューションのガバナンス
• マーケティングと営業の引き継ぎルール
• 営業とCSの引き継ぎルール
• 部門横断的なSLA
• 収益データモデル
• CRM、マーケティングオートメーション、CS、請求、BIの整合
• 共有ダッシュボード
• 予測とパイプラインのガバナンス
• 収益の運用リズム
• システムの変更管理

主な顧客は収益リーダーシップチームと収益システムそのものです。RevOpsは、マーケティング、営業、カスタマーサクセス、財務が同じ正式なデータ源から運用されているかどうかを問います。

Forresterはレベニューオペレーションを、B2B組織が成長エンジン全体で運用上の責任を整合させるのを助ける能力だと説明しています。これが重要な違いです。RevOpsは単なる営業支援機能ではありません。部門横断的な運用能力です。

並列比較

問題がチームの境界を越えたときに、この違いが明確になります。

担当者が商談ステージを更新していない場合、セールスオペレーションがプロセスとマネージャーの点検を修正できます。マーケティングと営業が何を商談とすべきかで意見が合わない場合、RevOpsがライフサイクルの定義、引き継ぎルール、レポートビューを修正する必要があります。

セールスオペレーションで十分な場合

会社がまだ営業主導で、運用の複雑さが低い場合、セールスオペレーションで十分なことがあります。

次に当てはまる場合、通常はセールスオペレーションのままで問題ありません。

• マーケティングが創業者主導、またはリード数が中程度である。
• 営業がパイプライン創出の大半を直接担っている。
• カスタマーサクセスへの引き継ぎがシンプルである。
• ファネルのステージ数が少なく、主要な営業モーションが1つである。
• 財務が大がかりな照合なしに営業の予測インプットを信頼できる。
• ツールがシンプルで、大半が営業所有である。

この段階では、直近の課題は担当者の実行力であることが多いです。担当者は正しいアカウントに取り組んでいるか。ステージは明確か。パイプラインは最新か。テリトリーは公平か。クォータは理解しやすいか。セールスクォータとクォータ達成率は、まず営業の運用課題です。

肩書きが流行しているというだけの理由でRevOps部門を作らないでください。会社にまだ部門横断的な収益の複雑さがないなら、強力なセールスオペレーション機能の方がすっきりしたモデルかもしれません。

RevOpsが必要になるとき

RevOpsが必要になるのは、成長が機能間の連携に依存するようになったときです。

よくあるきっかけは次のとおりです。

• マーケティングと営業がリードの質について意見が合わない。
• リードルーティングのルールが複数の場所で管理されている。
• パイプライン量は十分なのに予測が外れる。
• カスタマーサクセスがフィットの悪い、または十分に見極められていない顧客を引き継がれる。
• 財務がCRMの収益データを信頼していない。
• キャンペーンアトリビューションが受注レポートと照合できない。
• ある機能でのツール変更が、別の機能のレポートを壊してしまう。
• リーダーたちが運用上の意思決定よりも数字の議論に多くの時間を費やしている。

リード分配戦略はよい例です。営業は担当者への公平な割り当てを最も気にするかもしれません。マーケティングはキャンペーンのフォローアップの速さを気にするかもしれません。財務はチャネル別ROIを気にするかもしれません。RevOpsは、この3つの懸念すべてが可視化され統治されるようシステムを設計する必要があります。

Smarketingと RevOpsアライメントについても同じことが言えます。アライメントは各チームがそれぞれ自分のローカルなダッシュボードだけを所有していては定着しません。RevOpsが共有の定義とプロセス管理を所有することで定着します。

Harvard Business Reviewは、営業とマーケティングの不整合が企業に年間1兆ドル超のコストをもたらしていると推計しています。RevOpsモデルは、会議を1つ増やすことでこの問題を解決するのではありません。定義、引き継ぎ、データの所有権を運用上のものにすることで解決します。

セールスオペレーションとRevOpsの連携方法

成熟したモデルでは、セールスオペレーションは消えません。RevOpsの内部、あるいはその隣に位置する専門レーンになります。

RevOpsが部門横断的な標準を設定します。

• ライフサイクルの定義
• 収益データモデル
• 正式なデータ源
• 共有ダッシュボード
• 引き継ぎルール
• システムガバナンス
• 運用リズム

セールスオペレーションが営業実行の詳細を推進します。

• テリトリールール
• 営業プロセスの規律
• クォータ支援
• 担当者の生産性分析
• ディールデスクのプロセス
• 営業ツールの定着
• 営業予測のインプット

この関係がうまく機能するのは、意思決定権が明確な場合です。RevOpsはあらゆる営業ワークフローをマイクロマネジメントすべきではありません。セールスオペレーションはガバナンスなしに共有の収益フィールドを変更すべきではありません。

セールスオペレーションがRevOpsの一部になるときに変わること

最大の変化は組織図ではありません。最適化の対象です。

セールスオペレーションはしばしば営業チームのために最適化します。より整ったパイプライン、より高い担当者の生産性、より明確なクォータ、より強固な予測インプット、より一貫した営業プロセスです。RevOpsはそれらの目標を維持しつつ、その周りに部門横断的なシステムを加えます。

つまり、RevOpsに異動するセールスオペレーションのリーダーは、問いの立て方を変える必要があります。

この変化は居心地が悪く感じられることがあります。セールスオペレーションは通常、営業リーダーへの対応の速さで評価されます。RevOpsは、ローカルな営業の要望が共有レポート、アトリビューション、契約後の引き継ぎの質を損なう可能性があるため、より頻繁にノーと言わなければなりません。

たとえば、営業マネージャーが「口頭コミット」という新しい商談ステージを求めるかもしれません。セールスオペレーションはマネージャーに可視性が必要だという理由でそれを追加するかもしれません。RevOpsは、どのような根拠があれば商談がそのステージに移るのか、それが予測カテゴリーに影響するのか、財務はそれをどう解釈すべきか、契約が成立した後にカスタマーサクセスが必要とする下流のフィールドがあるかを問うべきです。そのステージは結局追加されるかもしれませんが、その意思決定は統治されています。

実務における意思決定権

ローカルな営業実行と共有の収益ガバナンスが分離されているとき、これらの機能はうまく連携します。

これにより、セールスオペレーションは営業担当者に近い立場を保ちながら、RevOpsはマーケティング、財務、カスタマーサクセスも依存するシステムを守ることができます。

セールスオペレーションからRevOpsへの移行パス

多くの会社はゼロからRevOpsを採用するのではなく、セールスオペレーションから進化させます。

移行は段階的に進めるべきです。

肩書きはミッションが変わったときにのみ変えるべきです。チームがまだ営業だけに仕えているなら、セールスオペレーションと呼び、それを卓越したものにしてください。チームが共有の収益の定義、システム、引き継ぎ、運用リズムを統治しているなら、RevOpsという肩書きは正当に得られたものです。

両方の機能が共存すべきとき

営業実行に深さが必要で、収益システムにも部門横断的なガバナンスが必要な場合、セールスオペレーションとRevOpsは共存すべきです。

これはミッドマーケット企業でよく見られます。RevOpsが共有モデルを設定し、セールスオペレーションが日々の営業エンジンを動かし続けます。

健全な共存とは、次のような状態です。

• 営業のフィールド、ステージ、テリトリー、予測ルールが影響を受けるとき、セールスオペレーションがRevOpsガバナンスのレビューに参加する。
• RevOpsはすべての小さな営業ワークフローの変更を承認するわけではないが、共有データに影響する変更はレビューする。
• 営業リーダーは、どの要望がセールスオペレーションに、どの要望がRevOpsの承認を必要とするかを把握している。
• 財務は個人的なスプレッドシートのロジックからではなく、RevOpsから予測の定義を受け取る。
• CSは受注後の引き継ぎルールが任意ではなく統治されているため、それを信頼できる。

この2つの機能が絶えず衝突する場合、問題は通常人間関係ではなく、意思決定権が不明確なことです。

組織設計の選択肢

報告ラインは重要です。RevOpsが営業にのみ報告する場合、マーケティングとCSはそれを単に権限が広がったセールスオペレーションとみなすかもしれません。マーケティングにのみ報告する場合、営業はアトリビューションとライフサイクルの判断を信頼しないかもしれません。CRO、COO、CEOへの報告ラインがあれば、RevOpsが中立を保てる可能性が高まります。

会社の段階別の意思決定フレームワーク

後期段階の組織図を初期段階の会社にそのままコピーしないでください。構造は運用の複雑さに従うべきです。

よくある間違い

権限を拡張せずにセールスオペレーションをRevOpsに改称する。 これは実際の意思決定力を伴わない期待だけを生みます。その人物は部門横断的な成果に対して責任を問われながら、依然として営業システムしか制御できません。

あまりに早くすべてを中央集権化する。 小規模な会社には、フォーマルなRevOps構造ではなく、実務的なオペレーター1人が必要かもしれません。ガバナンスが早すぎると学習が遅くなります。

セールスオペレーションをガバナンスルールなしにRevOpsの外に置く。 これは、共有データフィールド、ダッシュボード、システム変更に明確な承認経路がある場合にのみ機能します。

RevOpsをあらゆる収益に関する意思決定の所有者として扱う。 RevOpsはシステムを統治します。機能リーダーは引き続き戦略とチームのパフォーマンスを所有します。

実務的な判断ルール

肩書きの議論が堂々巡りになったときは、次のルールを使ってください。

問題が営業チームの内部にあるなら、セールスオペレーションがおそらくそれを所有すべきです。問題がマーケティング、営業、カスタマーサクセス、財務、システムを横断するなら、RevOpsがそれを統治すべきです。

例:

• 2人のAE間のテリトリー紛争：セールスオペレーション。
• 商談に反映されないキャンペーンソース：RevOps。
• 担当者へのクォータクレジット：財務とともにセールスオペレーション。
• CRMに記録されていないMQLの却下理由：RevOps。
• 担当者の生産性ダッシュボード：セールスオペレーション。
• マーケティング、営業、財務が使うソースから収益へのダッシュボード：RevOps。

このルールは両機能を補完的に保ちます。セールスオペレーションは営業実行の深さを守ります。RevOpsは収益ライフサイクル全体でのシステムの一貫性を守ります。

FAQ

RevOpsは単なるセールスオペレーションの新しい呼び方ですか？

いいえ。セールスオペレーションは営業実行に重点を置きます。RevOpsは、マーケティング、営業、カスタマーサクセス、財務、データ、システムを含む収益ライフサイクル全体にわたる、より広いミッションを持ちます。

セールスオペレーションはRevOpsの傘下に入れますか？

はい。多くの成熟した企業では、セールスオペレーションはRevOps内の専門機能です。RevOpsが共有の運用モデルを所有し、セールスオペレーションが営業特有の実行の詳細を所有します。

小規模な会社にRevOpsは必要ですか？

小規模な会社には収益の所有権は必要ですが、必ずしもRevOps部門は必要ありません。マーケティング、営業、CS、財務の連携が複雑になりすぎるまでは、オペレーションのジェネラリスト1人、またはセールスオペレーションのリーダーが基本をカバーできます。

セールスオペレーションとRevOps、どちらを先に採用すべきですか？

課題が主に営業プロセス、クォータ、テリトリー、CRMの衛生管理であれば、セールスオペレーションを採用してください。課題が部門横断的な引き継ぎ、ライフサイクルの定義、アトリビューション、予測への信頼、顧客への引き継ぎの質であれば、RevOpsを採用してください。

関連記事

• レベニューオペレーションとは何か
• レベニューオペレーションフレームワーク
• マーケティングとセールスのアライメント用語集
• パイプラインベロシティ
• 営業とCSのアライメント