なぜパートナー起点のレベニューはほとんどのCRMで見えなくなるのか

すべてのパートナーシップリーダーは、この経験をしたことがあるはずです。あるパートナーがその案件を持ち込んだことをあなたは知っています。あなたは紹介コールに参加していました。Slackのスレッドも見ました。それなのに案件がクローズし、四半期レポートが実行されると、そのレベニューは「営業ソース」あるいは「インバウンド」として現れます。あなたのプログラムの貢献は、誤差の範囲として読み取られます。そのレベニューは本物です。ただ、誰もが信頼する一つのシステムの中には存在しないだけなのです。

これはより良いレポートフィルターでは解決できません。それはCRMがどう設計されたかにおける構造的な死角であり、あなたがアライアンスマネージャーであれ、パートナーの人員を正当化しようとするRevOpsリーダーであれ、なぜそのレベニューが見えないのかを理解することが、それを見えるようにするための第一歩です。修正はデータモデルの中にあります。

CRMは直接販売のために作られた

Salesforce、HubSpot、そしてそれらをモデルにしたすべてのCRMは、一つの創業時の前提を共有しています。それは、一つの案件には一人のオーナー、一つのアカウント、そしてリードからクローズまでの一本の直線的な経路がある、というものです。それは、あなたの担当者が見込み客を見つけ、それに取り組み、契約を結ぶ場合には問題ありません。しかしパートナーが現れた瞬間に破綻します。

パートナー起点の案件を追ってみましょう。パートナーはそのアカウントを特定し、温かい紹介を行い、バイヤーの痛みについてのコンテキストをもたらし、時には署名までずっとコセルします。CRMでは、そのほぼすべてがパートナーの活動として記録されません。その機会はあなたの担当者によって作成され、あなたの担当者によって所有され、システムから見る限り、あなたの担当者によってソースされたことになります。パートナーの役割は、その通話に参加していた人々の記憶の中にしか存在しません。

ツール側の問題がそれをさらに悪化させます。典型的な「パートナー」の表現は、商談における単一選択の参照フィールドです。それは一つのパートナーしか保持できません。役割、タイムスタンプ、二つ目のパートナーを表現できません。したがって、それを几帳面に記入する担当者でさえ、複数当事者のモーションを一つのドロップダウンの値に平坦化してしまっています。そしてほとんどの担当者は、それがコミッションに影響しないため、そもそもそれを記入しません。

アトリビューションは、間違ったタイミングで、間違った人々によって決められる

データモデルがパートナーの関与をそれが起きたときに捕捉できないため、アトリビューションは手作業の、事後的な行為になります。誰かが、通常は四半期末に、通常はコミッション明細を見ながら、ある案件がパートナーソースだったと判断しなければなりません。

これは内在する利益相反です。AEの支払いは、その案件が自己ソースであることに依存しています。アライアンスチームの人員確保の根拠は、それがパートナーソースであることに依存しています。両者は、正反対のインセンティブを持って同じ機会を見ており、CRMはそれを解決するための中立的な証拠を提供しません。そのフィールドをコントロールする者が物語をコントロールし、それは通常パートナーチームではありません。これは誰も語らないコセルアトリビューション問題の核心です。記録システムは、まさに議論されているものそのものを記録していないのです。

その結果は予測可能です。パートナーソースのレベニューは過小に数えられます。インセンティブがすべて一方向に傾いているからです。いったんその数字が小さく見えると、そのプログラムは任意のもの(なくてもよいもの)に見えてしまいます。

証拠は存在する。ただしCRMが見ていない場所に

もどかしいのは、パートナーの関与の証拠がほぼ常にどこかに存在していることです。紹介はメールかパートナーポータルの紹介フォームの中にあります。コセルの調整はSlack、Teams、あるいは共有の案件ルームの中にあります。マーケットプレイスの取引はAWS、Azure、Google Cloudのパートナーコンソールの中にあります。関係の履歴はパートナー自身のCRMの中にあり、あなたはそれをまったく見ることができません。

これらのどれも、自動的には商談レコードに供給されません。したがってCRMは、パートナーという次元全体が欠落した、自信満々で完全に見える全体像を提示します。データが不足しているわけではありません。パートナーのシグナルが生まれるシステムと、レベニューが数えられるシステムの間の接続が不足しているのです。そして、パートナーが本当に起点となったものと、単に触れただけのものを見分けるには、インフルエンス型とソース型のパートナーレベニューを意図的に分離する必要があり、単一のドロップダウンではそれは決してできません。

それを見えるようにするために必要なこと

データモデルの問題をスプレッドシートで解決することはできません。パートナーソースのレベニューを見えるようにするということは、システムが何を捕捉するかを変えることを意味します。おおよそ順に、四つのことがあります。

複数当事者の案件モデルを採用しましょう。功績は、ソース、インフルエンス、コセル、フルフィルメントのいずれであれ、それぞれタイムスタンプ付きの、明確な役割を持つ複数のパートナーとして表現できる必要があります。他のすべてはこれに依存しています。

パートナーのシグナルが生まれた場所で捕捉しましょう。担当者に記憶し後から埋めてもらうことをやめましょう。紹介の提出、マーケットプレイスの案件登録、コセルコールの招待を計測し、パートナーの関与をそれが起きた瞬間に記録しましょう。

四半期が始まる前にアトリビューションのルールを設定しましょう。何がソースとインフルエンスとして数えられるかを事前に決め、毎回同じように適用しましょう。コミッションのプレッシャーの下で交渉された完璧なルールよりも、一貫して適用される平凡なルールの方が優れています。

周辺システムを接続しましょう。パートナーのシグナルが存在する紹介フォーム、マーケットプレイス、コラボレーションツールは、レベニューの全体像へと流れ込む必要があります。それこそ、レベニューオーケストレーションが、手作業で更新される一つのフィールドを信頼する代わりに、スタック全体からのシグナルを統合することによって埋めようとしているギャップです。

目標は正確さです。財務がその数字を信頼し、経営層が信仰ではなく証拠に基づいてプログラムに予算をつけるのに十分なほどの正確さです。パートナーソースのレベニューが見え、擁護可能になれば、エコシステムへの投資についての議論全体が変わります。

主なポイント

• CRMは、一人の営業担当者、一つの案件、一本の経路のために作られました。構造的にパートナーソースの案件を表現できず、レポートレイヤーではそれを修正できません。
• 単一選択のパートナーフィールドは、複数当事者のモーションを一つの値に平坦化してしまい、コミッションに影響しないため、通常は空欄のままです。
• アトリビューションは、正反対のインセンティブを持つ人々によって事後的に決められます。パートナーチームがその議論に勝つことはめったにありません。
• 証拠は紹介フォーム、マーケットプレイスのコンソール、Slackのスレッドの中に存在しています。ただそれが商談レコードに到達することがないだけです。
• 複数当事者データモデル、発生源での捕捉、四半期前に合意されたルール。より多くの手作業レポーティングでは、そこにはたどり着けません。

パートナーソースのレベニューは見えないままである必要はありません。それが生まれた場所で捕捉され、数えられる場所に接続されるべきです。Revnewoのようなレベニューオーケストレーションプラットフォームが、そうした散在するパートナーシグナルをどうまとめるかを見てみたいなら、それはあなたのエコシステムが実際にどれだけの価値を持つかを証明するための、妥当な次の一歩です。