B2Bレベニュースタックの歴史：CRMからオーケストレーションへ

自分のレベニュースタックを設計する人はいません。誰もがそれを受け継ぐのです。あなたが入社する前からあったCRM、誰かが急いで選んだマーケティングプラットフォーム、厳しい四半期の後に購入したセールスエンゲージメントツール、解約が取締役会の議題になった年に追加されたカスタマーサクセスシステム。それぞれの購入は、その時点では理にかなっていました。しかしそれらが一緒になって、ほとんどのレベニューチームが暮らしている、断片化した調整困難な環境を生み出しました。

なぜここに至ったのかが重要なのは、現在の問題の形――損失を伴う引き継ぎ、矛盾するデータ、誰も行動を起こさないシグナル――が、業界がおよそ30年にわたって下してきた決定に直接由来するからです。その弧を辿ってみると、レベニューオーケストレーションは、単なるもう一つの製品カテゴリーというより、当然の次の章のように見えてきます。

CRM時代(1990年代後半から2000年代)

第一幕は記憶についてでした。CRM以前、顧客情報は営業担当者の頭の中、手帳、デスクトップのスプレッドシートに存在していました。担当者が退職すれば、その関係も一緒に去っていきました。CRMは、会社にアカウント、コンタクト、案件の組織的記録を与えることで、本物の危機を解決しました。

これは基礎的な進歩でした。しかしCRMは、行動のシステムとしてではなく、記録のシステムとして構築されました。それは「このアカウントについて何を知っているか」に答えましたが、「次に何が起きるべきか」については何も語りませんでした。それは、営業担当者が事後にしぶしぶ更新するデータベースでした。案件がどこにあるかを教えてくれましたが、それを動かすことは何もしませんでした。その隙間が、その後20年間のスタックの形を規定することになります。

ポイントソリューションの爆発(2010年代)

Go-to-Marketがより洗練されるにつれ、各職能は自分たちのモーションのために作られたソフトウェアを求めるようになり、ベンダーは喜んでそれに応えました。リードのナーチャリングとスコアリングのためのマーケティングオートメーション。アウトバウンドシーケンスを実行するためのセールスエンゲージメント。通話を記録・分析するための会話インテリジェンス。見積もりを処理するCPQと請求ツール。ヘルスを追跡し解約と戦うためのカスタマーサクセスプラットフォーム。市場にいるアカウントを見つけるためのインテントデータとエンリッチメントデータ。

それぞれが自分の仕事において優れていました。カテゴリーのリーダーたちは、自分たちが仕えた職能を本当に改善しました。しかし累積的な結果は、それぞれが独自のデータモデル、独自の「アカウント」の定義、独自のワークフローを持つ、何十ものシステムでした。マーケティングプラットフォームのリードは、CRMの商談にきれいにマッピングされず、それはCSプラットフォームのアカウントにもマッピングされませんでした。統合は恒久的な予算項目になりました。

これが、今日多くのチームが感じている断片化を生み出した時期であり、なぜレベニュースタックが断片化しているのかで掘り下げています。ツールが増えることは、能力の向上を意味すると同時に、調整のオーバーヘッドの増大も意味しました。

統合の時代(2010年代後半)

広がりすぎたスタックに直面し、企業は二つのことを試みました。統合ミドルウェア、つまりシステム間でデータを運ぶコネクタと同期です。そして、データウェアハウスとBIダッシュボードで、すべてを一つのレポートビューに集約することです。

どちらも助けにはなりました。しかしどちらも根本的な問題を解決しませんでした。統合は、サイロを解消することなくサイロ間でデータを移動させました。ダッシュボードは断片化を可視化し、初めてファネル全体を見られるようになりましたが、見ることは行動することではありません。リーダーは、案件がどこで停滞しているかを正確に示す美しいダッシュボードを見つめながら、その瞬間に何も行動を起こせないままでいることがありました。スタックは問題を報告することには非常に優れるようになりましたが、それを解決することはできないままでした。

人力による回避策も規模に耐えられませんでした。チームはRevOpsの人員を増やし、機能横断的な会議を増やし、ツールが調整できないものを補うための「アラインメント」の儀式を増やしました。そのアプローチは限界にぶつかりました。なぜアラインメントは失敗したのかで論じている通りです。

オーケストレーションの時代(現在)

二つのことが収束しました。断片化の痛みは無視できないほど高くつくようになりました。そしてAIは、人間のチームがどうやっても及ばない規模で、シグナルを解釈し、意図を予測し、行動を推奨できるほど優れたものになりました。

オーケストレーションとは、すべてを一つの巨大なモノリスに統合しようとするのをやめ、代わりにスタックの上に調整レイヤーを追加するときに構築されるものです。それはCRMやCSプラットフォームを置き換えません。それらすべてを横断して耳を傾け、シグナルを統合し、次善のアクションを適切な人物やワークフローへ押し出します。記録のシステムは、ついにその上に行動のシステムを得るのです。

だからこそ、これは破壊のための破壊ではなく、進歩として読めるのです。各段階が前の段階の限界を解決してきました。

1. CRMは失われた組織的記憶を解決しましたが、行動できませんでした。
2. ポイントソリューションは職能ごとの深さを解決しましたが、断片化を生みました。
3. 統合はデータの移動を解決しましたが、調整は解決しませんでした。
4. オーケストレーションは調整を解決し、システムの山を一つのレベニューモーションに変えます。

この役割のためにAIネイティブに構築されたプラットフォーム――Revnewoもその一つです――は、オーケストレーションを、スタックにもう一つ後付けされたサイロとしてではなく、スタックに常に欠けていたレイヤーとして扱います。

主なポイント

• スタックはCRM、ポイントソリューション、統合、そして現在のオーケストレーションという4つの幕を経て進化しました。
• CRMは企業に記憶を与えましたが、行動を与えることはありませんでした。
• ポイントソリューションは各職能の深さを買いましたが、その代償として断片化を招きました。
• 統合とダッシュボードは混乱を可視化しましたが、リアルタイムで何も調整できませんでした。
• オーケストレーションは既存のツールの上に位置し、それらが決して持ち得なかった調整レイヤーを追加します。

あなたの現在のスタックは、30年分の妥当な局所的意思決定が積み重なったものです。オーケストレーションは、それらを合算する層です。もしこれに心当たりがあるなら、次の問いは、すでに持っているツールの上に調整レイヤーを置くとどう見えるか、ということです。