マーケットプレイスコセル：ハイパースケーラーとの混乱のない販売

AWS、Azure、Google Cloudのマーケットプレイスを通じた販売は、ほとんどのB2Bソフトウェア企業にとって「あればいいもの」から「取締役会レベルの優先事項」へと変わりました。その理由には十分な裏付けがあります。バイヤーはコミット済みのクラウド支出に対して購入できます。調達は劇的に速くなります。ハイパースケーラーのフィールドセールスは、あなたのチームが何四半期もかけてようやくたどり着けるような部屋へあなたを招き入れてくれます。マーケットプレイスコセル――あなたの担当者とクラウドプロバイダーのアカウントチームが一つの案件を共に手がけること――は、現在B2Bにおいて最も強力なモーションの一つです。

同時に、最も混乱しやすいものの一つでもあります。コセルプログラムは広範囲かつ官僚的です。案件登録、コセルリクエスト、マーケットプレイス取引は、それぞれ独自のルールを持つ異なるコンソールに存在します。あなたの担当者はそのプロセスを理解しておらず、クラウドセラーのインセンティブは不透明で、その全体が生み出すデータはあなたのCRMと決して一致しません。アライアンスやRevOpsのリーダーにとっての問いは、マーケットプレイスコセルをやるかどうかではありません。運用上のオーバーヘッドがその利点を食い潰さないように、どう運営するかです。

それでも取り組む価値がある理由

その混乱に踏み込む前に、このモーションがなぜ労力に見合うのかを明確にしておく価値があります。

コミット済み支出が予算を解放します。エンタープライズはクラウドプロバイダーに数百万ドルを事前コミットしており、マーケットプレイスでの購入はそのコミットメントを消化します。バイヤーはすでに割り当て済みのお金を使っているため、調達の摩擦は崩れ落ち、他の何ものにもできない形でサイクルが短縮されます。

クラウドのフィールドチームは、あなたにはないリーチを持っています。ハイパースケーラーのアカウントチームは、地球上で最大級のエンタープライズの中に、常設の経営層との関係を持って存在しています。彼らの営業担当者があなたの製品をコセルするとき、あなたはあなたの担当者が一からゼロベースで築くのに1年かかるようなアクセスを受け継ぐことになります。

プライベートオファーが取引をきれいにします。カスタム価格設定、交渉済みの条件、標準化された契約書類。実際のクローズは、従来のエンタープライズ契約よりもシンプルです。

その価値は本物であり構造的です。それを食い潰すのは、あなたがそうさせてしまった場合の運用上の抵抗です。

混乱はどこから来るのか

四つの要因が繰り返し現れます。

プロセスの不透明性。プログラムは実際に複雑です。登録のしきい値、コセルの適格性ルール、インセンティブの階層、掲載要件。ほとんどの担当者はそれらを学ぶことがなく、そのため案件は登録されないか、誤って登録され、コセルの恩恵はひそかに消えていきます。

データの断片化。登録はパートナーポータルに存在します。コセルのステータスは、あなたが見ることのできないハイパースケーラーのCRMに存在します。取引はマーケットプレイスのコンソールに存在します。そのどれも自動的にはあなたのCRMに流れ込まないため、アライアンスチームの誰かが毎週手作業で全体像をつなぎ合わせています。これはなぜパートナー起点のレベニューはほとんどのCRMで見えなくなるのかの深刻な事例です。マーケットプレイスは、あなたの記録システムがネイティブには見ることのできない、丸ごと一つのレベニューチャネルなのです。

インセンティブの不一致。クラウドセラーには彼ら自身のノルマ、彼ら自身の優先順位、そして今四半期どのベンダーを推すべきかについての彼ら自身の考えがあります。あなたの担当者はクラウドチームがその案件を主導してくれると思い込み、クラウドチームはあなたの担当者がそうすると思い込みます。両者が待ち、案件は停滞します。

アトリビューションの混乱。クラウドセラーが関与したマーケットプレイス経由の案件がクローズしたとき、誰がそれをソースしたのでしょうか。あなたの担当者か、クラウドチームか、それともマーケットプレイス自体か。これは単一のCRMフィールドでは答えられない複数当事者の問いであり、コセルアトリビューション問題そのものの事例です。

機能する運用モデル

ハイパースケーラーの官僚制度を修正することはできません。しかしできるのは、彼らのシステムとあなたのシステムの間に薄い運用レイヤーを構築することです。四つの実践がその大部分を担います。

早期かつ体系的に登録しましょう。登録こそ、マーケットプレイスの恩恵が勝ち取られるか失われるかの分かれ目であり、終盤で慌てて行うのではなく、案件の早い段階で行われる必要があります。それをあなたの営業プロセスの中でトリガーされるステップにしましょう。案件が適切なステージに到達したら、担当者にはその機会からあらかじめ入力されたフィールドとともに登録を促す通知が届きます。担当者の記憶はプロセスではありません。

マーケットプレイスの状態をあなたのCRMに同期させましょう。これはリストの中で他の何よりも重要です。コセルのステータスとマーケットプレイスの取引データをあなたの記録システムに戻し、担当者が自分の商談についてクラウド側のステータスを見られるようにしましょう。それができるようになれば、調整のギャップのほとんどは自然に解消します。

案件ごとに所有権を合意しましょう。それぞれのコセルについて、誰が何を主導するのか、あなたの担当者かクラウドセラーかを明示的にしましょう。あいまいさは、あらゆるパートナーモーションを引き継ぎの場面で殺すのと同じように、これらの案件を途中で殺します。パートナーシップが引き継ぎで停滞する理由にあるすべては、担当者とクラウドセラーの関係にも当てはまります。

アトリビューションを事前に決めておきましょう。マーケットプレイスとクラウドセラーの関与がどのように功績付けされるかを案件の前に取り決め、接点が起きたときにそれを捕捉しましょう。マーケットプレイスの案件がクローズしたとき、あなたが欲しいのは議論ではなく記録です。

スケールさせる

一つのマーケットプレイス案件は、根性で管理できます。しかし三つのハイパースケーラーにまたがるポートフォリオはそうはいきません。ボリュームが増えるにつれ、手作業のオーバーヘッド(ポータルの確認、登録の督促、取引の照合、功績についての言い争い)が、実際に獲得できるマーケットプレイスレベニューの天井になります。

だからこそ、マーケットプレイスコセルは結局のところレベニューオーケストレーションの問題になります。このモーションがスケールするのは、マーケットプレイスコンソール、パートナーポータル、クラウドのCRM、そしてあなた自身の記録システムの間の接続が自動化されている場合だけです。登録がトリガーされ、ステータスが同期され、アトリビューションが毎回誰かがつなぎ合わせることなく捕捉される、というようにです。すべてのマーケットプレイス案件をオーダーメイドのプロジェクトとして扱う企業は、アライアンスチームが個人的に対応できる範囲でマーケットプレイスレベニューに上限を設けてしまいます。それをオーケストレーションする企業は、ハイパースケーラーのマーケットプレイスを本物のチャネルへと変えます。

主なポイント

• その利点は構造的です。コミット済み支出、クラウドのフィールドリーチ、そしてプライベートオファーを通じたよりクリーンな取引です。
• 混乱は四つの場所から来ます。不透明なプロセス、あなたが見えないコンソールに分散したデータ、クラウドセラーとのインセンティブの不一致、そして複数当事者アトリビューションです。
• 登録を営業プロセスの中でトリガーされるステップにしましょう。担当者の記憶に任せないでください。
• コセルとマーケットプレイスのステータスをあなたのCRMに取り込むことは、他のどの単一の修正よりも効果があります。
• 数件の案件を超えたら、ハイパースケーラーのシステムとあなたのシステムの間の配管が自動化されていなければ、このモーションはスケールしません。

マーケットプレイスコセルは、それぞれの案件を手作業で管理するのではなく、ハイパースケーラーの断片化したシステムの上に一つの一貫したレイヤーを構築する企業に報います。AWS、Azure、Google Cloudにまたがってスケールしようとしているなら、Revnewoのようなプラットフォームは、マーケットプレイスのシグナルをレベニューの全体像の中に取り込み、三つの別々のモーションを運営せずに済むようにしてくれます。