なぜほとんどのセールスプレイは現場で死ぬのか、そしてそれを救う方法

すべてのセールスプレイは楽観的に生まれます。レベニューリーダーがあるパターンに気づき、RevOpsとイネーブルメントがそれを軸に整ったプレイを構築し、QBRでお披露目されてうなずく顔が並び、誰もがそれこそチームが必要としているものだと同意します。6週間後、採用率はほぼゼロです。レップは静かに、いつも通りのやり方に戻っています。そのプレイは公式には死んでおらず、イネーブルメントのライブラリの中にまだ座っていますが、収益が生み出される現場では、それは一度も生きたことがありませんでした。

これは非常によくあることで、ほとんど法則に近いものです。ほとんどのプレイは現場で死にますが、それはアイデアが悪かったからではありません。それらは、プレイがどう設計されたかと、レップの実際の火曜日がどう見えるかとの間にある、予測可能な一連のギャップから死んでいきます。そのギャップを閉じれば、行動を変えるプレイブックが手に入ります。放置すれば、ただのフォルダが残ります。

死因その1：プレイが瞬間に届かない

最も一般的な殺し屋はタイミングです。あるプレイは、特定のトリガーが発生する1つの特定の瞬間にのみ有用です。典型的なセットアップでは、プレイはドキュメントの中に座っており、そのプレイが存在することを覚えていて、この案件がそのトリガーに達したことに気づき、それを見つけて実行しに行くことは、完全にレップに委ねられています。本物の購買の瞬間とプレイの発動との間に、3つの独立した失敗ポイントがあります。

40件の案件をやりくりするレップにとって、この3つは絶えず失敗します。その瞬間は認識されないまま過ぎ去り、プレイは引き出しの中に留まり、機会は漏れていきます。弱いトリガー、あるいはトリガーのないプレイは、到着した時点ですでに死んでいます。だからこそ高コンバージョンのプレイの解剖学はトリガーから始まります。その瞬間に届くために人間の記憶に依存するプレイは、ほとんどの場合その瞬間を逃します。

救済策。トリガーをシステムが検知できるシグナルに接続し、その瞬間が訪れたときにプレイをレップの目の前に置くことです。それが、シグナルを次善のアクションに変えることと、誰かが覚えていることを願うこととの違いです。

死因その2：本物の案件を生き延びられない

2つ目の殺し屋は硬直性です。多くのプレイは、案件がその通りに振る舞うことを前提とした、きれいで線形なシーケンスとして書かれています。しかし案件はそうは振る舞いません。新しいステークホルダーが現れ、買い手が沈黙し、競合が招き入れられ、チャンピオンが組織再編に巻き込まれます。案件がスクリプトから逸脱した瞬間、それはほぼ即座に起きますが、レップは「このプレイはここでは当てはまらない」と判断し、それを手放してしまいます。

硬直したプレイは理想的なケースでしか機能せず、理想的なケースはほとんど起こりません。修正策はプレイをより曖昧にすることではありません。曖昧なプレイは別の意味で役に立たないからです。案件が横道にそれるよくあるパターンに対する定義された対応を伴う、分岐する設計にすることです。買い手の行動に適応するプレイブックは現場を生き延び、静的なスクリプトは生き延びません。導くのに十分な構造と、曲がるのに十分な柔軟性です。

死因その3：機能しているかどうか誰にもわからない

3つ目の殺し屋は不可視性です。あるプレイがローンチされたとき、ほとんどのチームは、それが実際に実行されているかどうか、そして実行されているならコンバージョンしているかどうかを見る手段を持っていません。それがなければ、次のようなことが起きます。

• 良いプレイは、それが機能するという証拠がないために放棄され、レップはそれを信頼しません。
• 悪いプレイは、それが失敗していることを示すものが何もないため、永遠に生き続けます。
• コーチングのループが存在しません。誰が何を実行したかの記録がなければ、マネージャーは「そのプレイを実行したか」と尋ねることができません。

測定できないプレイは、改善することも擁護することもできないプレイです。これは、静的なドキュメントと動的オーケストレーションを分けるのと同じ計測のギャップです。プレイが実行されているのを見ることができないなら、あなたは当て推量をしているにすぎません。

救済策。すべてのプレイを計測し、発火率、完了率、コンバージョン率を見られるようにすることです。そして意見ではなくエビデンスに基づいて、負け組を殺し、勝ち組に倍賭けします。

死因その4：レップのインセンティブと戦う

最も静かな殺し屋です。あるプレイは完璧に設計されていても、それを実行することがレップの数字達成に役立たない、あるいは積極的にレップを遅らせるために死ぬことがあります。もしマルチスレッド化のプレイがサイクルに2週間を追加し、レップがスピードで報酬を得ているなら、彼らは毎回それをスキップするでしょう。あるプレイが、引き継ぎポイントでよく起きるように、主にレップを犠牲にして下流のチームの目標に奉仕するものであれば、それがどれだけ優れていても実行されません。

レップは合理的です。彼らは報酬を得られるものを最適化し、それと戦うプレイは負けます。あるプレイをローンチする前に、率直な質問をしてください。これを実行することはレップの役に立つのか、それとも会社だけの役に立つのか。答えが会社だけであれば、そのプレイはすでに死につつあります。レップが何かを得られるように再設計するか、プレイと数字が同じ方向を向くようにインセンティブを変えてください。

短い診断

あるプレイが死につつあるとき、あるいはローンチする前に、これに照らして確認してください。

1. 本物の検知可能なトリガーがあるか。もしレップの記憶に依存しているなら、配信方法を修正する。
2. 逸脱を生き延びられるか。理想的なケースでしか機能しないなら、分岐を追加する。
3. それを測定できるか。実行とコンバージョンを見られないなら、計測する。
4. それはレップが勝つのを助けるか。もしそれがレップの報酬と戦うなら、プレイか報酬を再設計する。
5. それはレップが作業している場所に届けられているか。誰も開かないドキュメントの中に住んでいるなら、それをワークフローの中に持ち込む。

死んだプレイのほとんどは、これらのうち2つか3つを同時に満たせずにいます。それらを修正すれば、静かに死んでいたであろうプレイが、収益を動かし始めます。

主なポイント

• プレイはタイミングによって死ぬ。それらはその瞬間に届くためにレップの記憶に依存し、それを逃す。
• プレイは硬直性によって死ぬ。線形なスクリプトは案件が逸脱した瞬間に壊れるため、分岐を組み込む。
• プレイは不可視性によって死ぬ。あるプレイを測定できなければ、それを信頼することも、改善することも、コーチングすることもできない。
• プレイはレップの数字と戦うときに死ぬ。その戦いには1つの結末しかない。
• それらを救うということは、本物のトリガー、分岐、計測、整合したインセンティブ、そしてレップのワークフロー内での配信を意味する。

プレイを救うことは、良いアイデアと確実な実行の間のギャップを閉じることに尽きます。それこそ、ライブラリではなく現場に生きる再現可能なGTMプレイブックの目的です。レベニューオーケストレーションは、プレイを生かし続ける方法です。正しいプレイを、正しい瞬間に、正しいレップの目の前に。