スケールする再現可能なGTMプレイブックの設計

すべてのレベニューリーダーは、いずれこの壁にぶつかります。最初の10件の取引が成約したのは、創業者や一人の非常に優れた担当者がそれをゴールまで引きずり込んだからです。次の100件も同じ道をたどるはずですが、そうはなりません。なぜならその道筋は一人の頭の中にしか存在していなかったからです。モーションが英雄的行為に頼っている限り、成長は雇える英雄の数と彼らが働ける時間数によって頭打ちになります。

再現可能なGTMプレイブックは、その暗黙の個人的な知識を、有能な担当者なら誰でも実行でき、マネージャーなら誰でもそれに照らしてコーチングできる共有システムへと変換します。うまく作られれば、レベニューは個性ではなくプロセスの品質の関数になります。ここでは、それぞれの部分に必要な戦術的な要素へのポインタとともに、しっかりと機能するプレイブックの作り方を説明します。

何かを書く前にモーションを選ぶ

一通のメールテンプレートを文書化する前に、そのプレイブックがどの種類のモーションを体系化しようとしているのかを決めましょう。ユーザーがセルフサーブで有料ティアに入るプロダクト主導モーションは、6桁のACVと12人の購買委員会を持つエンタープライズモーションとはほとんど似ていません。両方にまたがる普遍的なプレイブックを一つ書けば、誰も読まないほど一般的な文書ができあがります。

まだ選択肢を検討中なら、プロダクト主導対セールス主導対エコシステム主導のモーションの解説で、ACV、バイヤー、プロダクトの複雑さにモーションを合わせる方法を扱っています。そして、複数のモーションを同時に走らせたい誘惑に駆られているなら、まず複数のGTMモーションをいつ重ねるべきかを読んでください。重ね合わせは複雑さを増大させ、それを早い段階で行うことは、私たちがチームの停滞を目にしてきたよくある原因の一つです。

モーションは、下流のすべてを決定します。誰が最初の接触者になるか、サイクルがどれくらい続くか、どのシグナルが重要か、そして「クオリファイド」が何を意味するかさえも。

退出基準を持つステージ

スケールするプレイブックは、それぞれに明確な参入基準と退出基準を持つ一連のステージです。曖昧なステージ(「対応中です」)は、フォーキャストが死に絶える場所です。正確なステージは、誰もが共有できる言語を与え、パイプラインレビューを速く進めます。

各ステージについて、案件がここに存在するために何が真でなければならないか(エコノミックバイヤーが特定されている、痛みが定量化されている)、担当者がここにいる間の仕事は何か、そしてどのような観察可能な証拠があれば次に進む準備が整ったと言えるかを書き出しましょう。

成果を記述しましょう。「フォローアップを送る」は活動です。「バイヤーが予算とタイムラインを文書で確認した」は成果です。活動はインプットであり、再現可能なプレイブックはアウトプットによって統治されます。退出基準が客観的であれば、二人の担当者が同じ案件を見たときに同じ評価を下します。その一貫性こそが、4人ではなく40人の担当者を抱えるようになったときに、フォーキャストとコーチングを可能にするものです。

プレイのライブラリ

プレイブック設計における最大の間違いは、硬直した線形のスクリプトを書いて、案件がそれに従うことを期待することです。案件は分岐します。使えるプレイブックとは、目の前の状況に合わせて組み立てる、自己完結型のプレイのライブラリです。

優れたプレイには、トリガー、ターゲット、一連のアクション、そして定義された成功の成果があります。高コンバージョンなセールスプレイの構造のガイドでは、この構造を詳しく解説しています。ほとんどの案件で繰り返し起こる瞬間のためにプレイを構築しましょう。痛みを表面化させ定量化するディスカバリープレイ、単一のチャンピオンを超えて広げるマルチスレッド化プレイ、既存業者が同席しているときの競合排除プレイ、そして音信不通になった案件のための再エンゲージメントプレイです。

プレイはモジュール式であるため、担当者はすべての案件が同じだと仮定するスクリプトを行進するのではなく、組み合わせて使います。それはまた、プレイブックの進化も可能にします。あるプレイが機能しなくなったら、そのモジュールだけを交換します。システム全体を書き直す必要はありません。

計測しなければ単なるwikiページ

測定できないプレイブックは提案にすぎません。誰も開かないwikiページと、生きたシステムを分けるのは計測です。ステージごと、プレイごとに、何がコンバージョンしていて何が漏れているかが見えるということです。

これこそ、ほとんどの静的なプレイブックが崩壊する場所であり、なぜこれほど多くのセールスプレイが紙の上では素晴らしく見えても現場で静かに死んでいくのかの理由です。解決策は、プレイブックをライブシグナルに接続することです。どのプレイが発動し、どれがスキップされ、どこで案件が停滞し、バイヤーの行動がどう成果にマッピングされるか。Revnewoのようなレベニューオーケストレーションプラットフォームは、まさにこのギャップを埋めるために存在し、担当者に推測させるのではなく、ライブの購買シグナルから次善のアクションを表面化させます。文書から動的なシステムへの移行は十分に大きな転換であるため、静的なプレイブックから動的なオーケストレーションへで別途詳しく扱っています。

どのツールを使うにせよ、すべてのステージを計測し、データを毎週見て、プレイブックを一度公開して忘れる方針としてではなく、継続的に改善し続けるプロダクトとして扱いましょう。

重要なポイント

• まずモーションを選びましょう。プレイブックは、特定の一つのモーションのために構築されて初めてスケールします。
• ステージには成果として書かれた客観的な退出基準が必要です。そうすれば、どの二人の担当者も同じ案件を同じように評価できます。
• モジュール式のプレイのライブラリを構築しましょう。実際の案件は分岐し、線形のスクリプトはそれに追従できません。
• 測定できなければ、それはただの文書です。ライブシグナルに接続し、毎週レビューしましょう。

再現可能なプレイブックは、テリトリー設計から顧客の引き継ぎまで、レベニュー組織における他のすべてが乗る土台です。静的な文書から、案件が動くにつれて適応するシステムへと移行する準備ができたら、レベニューオーケストレーションが、優れたプレイブックを実際に実行されるものへと変える方法です。