動的プレイブック時代のイネーブルメント

セールスイネーブルメントは、常に「モノを作る」仕事でした。製品がローンチすれば、イネーブルメントはデッキ、バトルカード、認定資格を作ります。競合が動けば、イネーブルメントは反論対応ガイドを書きます。それらの資産はコンテンツライブラリに格納され、キックオフで一通り説明され、その後はほとんど放置されます。実際にそのガイドが必要になる商談の最中に担当者がいる頃には、それはフォルダ3階層下に埋もれたPDFになっており、担当者にはそれを探しに行く時間も記憶もありません。イネーブルメントは仕事をしました。それでも、必要なときに知識は現れなかったのです。

レベニューシステムが案件の内部で何が起きているかを把握できるようになると、これが変わります。イネーブルメントは、担当者が何を必要としているかを推測し、1月に学んだことを覚えていてくれることを祈る必要がなくなります。ガイダンスは、それが当てはまる瞬間に、文脈に沿って届けられます。これによってイネーブルメントは、単なる発行機能から、レベニューモーション全体で「良い状態とは何か」を決め、それが実際に実現するようにするグループへと変わります。

静的なプレイブックが失敗する理由

静的なプレイブックは、担当者が適切なタイミングで適切な知識を引き出すことを前提にしています。しかし実際には、学習の瞬間と必要になる瞬間の間には数週間の隔たりがあり、その間には他の優先事項が山ほど積み重なっています。

具体的にいくつかの問題が起こります。担当者は忘れます。1月にあるプレイの認定を受けた人が、6月の交渉の場でそれを呼び出すことはできません。意欲的な担当者でさえ、通話で使えるほど速く、膨大なライブラリの中から関連する一つの資産を見つけ出すことはできません。コンテンツは古びていきます。それが書かれた日の市場、製品、競合状況を描写しているにすぎず、そのどれも静止していないからです。そして通常、イネーブルメントはあるプレイが実際に使われたかどうかを知る術がなく、改善の手がかりがありません。あなたは虚空に向けて発行し続けているのです。

その結果、多大なイネーブルメントの労力が、本来影響を与えるべき数よりもはるかに少ない案件にしか影響を与えない成果物を生み出します。私たちはこれを、優れたイネーブルメントチームを持つ企業でも見てきました。これは、断片化したレベニュー組織のあらゆる場所に現れる「シグナルは見えているのに行動につながらない」問題と同じものであり、レベニューシグナルを次善のアクションに変えるで解説している内容そのものです。

動的プレイブックとは実際には何か

動的プレイブックとは、文書ではなく、特定の案件やアカウントで起きていることに基づいて表面化する推奨事項の集合です。「これがエンタープライズ営業手法です、40ページすべてお読みください」ではなく、「この案件は調達部門を巻き込んで複数関係者化しましたが、10日間停滞しています。エコノミックバイヤーを再エンゲージするためのプレイはこちらです」というものが、今、この担当者に対して、すでに使っているツールの中で届けられます。

システムは案件のステージ、勢い、関係者、リスク指標を把握しており、状況に合わせて自動的にガイダンスをマッチングします。イネーブルメントの仕事は、プレイとそのトリガーを定義することになります――案件が勝敗を分ける各ポイントで、どの条件下で何が起きるべきかということです。

これは、イネーブルメントがライブラリとして隣に座っているのではなく、再現可能なGTMプレイブックそのものに組み込まれることを意味します。ベストプラクティスは業務の流れの中に存在し、実際の条件で発動します。

オーケストレーションの規律としてのイネーブルメント

このように見ると、イネーブルメントはオーケストレーション機能です。その成果物は、最も優れた担当者が各状況で取るであろう行動を符号化した知識であり、それがシステムを通じてすべての担当者に届けられます。これにより、イネーブルメントはレベニュー組織の配管を構築するチームのすぐ隣に位置づけられます。

いくつかの変化が起こります。イネーブルメントは発行することをやめ、符号化することを始めます。暗黙知は明確なトリガーを持つ定義済みのプレイとなり、ファイルされるのではなく動的に届けられるようになります。ローンチイベントは継続的なチューニングに取って代わられます。動的なプレイは計測可能であり、どれが使われ、どれが結果を動かしているかをようやく把握できるからです。そして対象範囲は、キックオフ時の新人担当者にとどまらず広がります。更新時のCSM、引き継ぎ時のAE、コセルにおけるパートナー――全員が同じシステムからガイダンスを受け取り、それがオーケストレーションされたレベニュー組織のための採用が選抜しようとしている協働の習慣を強化します。

沈黙してしまった案件に取り組んでいるAEを例に考えてみましょう。旧来のモデルでは、イネーブルメントが丹念に作った「停滞案件の再エンゲージメント」ガイドは、担当者がそれを探そうと思いつかないために読まれないままです。動的なモデルでは、システムがバイヤー活動が2週間ないことと、チャンピオンが沈黙していることに気づき、具体的な次のステップとともに再エンゲージメントのプレイを担当者の目の前に提示します。知識が担当者を見つけるのです。担当者が知識を見つける必要はありません。

動的イネーブルメントへ向けて構築する

ここに到達するのは、コンテンツツールをもっと購入することによってではありません。イネーブルメントをレベニューシステムのシグナルに接続し、それらのシグナルに対してプレイを定義することによってです。それには機能横断の共有データと、ガイダンスをライブのコンテキストにマッチングできるプラットフォームが必要であり、だからこそ動的イネーブルメントとレベニューオーケストレーションは共に前進する傾向があります。イネーブルメントは符号化されたプレイを提供します。オーケストレーションはシグナルを認識した配信を提供します。

イネーブルメントリーダーにとっての実践的な第一歩は小さなものです。適切なガイダンスが結果を最も大きく変える、いくつかの瞬間を選びましょう。停滞した案件、リスクのある引き継ぎ、拡大のシグナル。まずそれらに対してプレイを符号化し、それらをトリガーすべきシグナルに結びつけ、何が使われるかを観察します。それから拡大していきましょう。

主なポイント

• 静的なプレイブックはタイミングで失敗します。担当者はプレイを必要となる何か月も前に学び、必要なときにそれを見つけられず、その間にコンテンツは古びています。
• 動的なプレイブックとは、ライブラリの中の文書ではなく、実際の案件シグナルによってトリガーされるガイダンスです。
• イネーブルメントの仕事は、トリガー付きのプレイを符号化し、実際に何が使われたかに基づいてチューニングすることになります。
• これはキックオフ時の新人担当者だけでなく、CSM、AE、パートナーにも同様に当てはまります。
• 最も重要な3つか4つの瞬間から始め、それらのシグナルにプレイを結びつけましょう。コンテンツツールを増やしてもそこにはたどり着けません。

動的イネーブルメントは、現在忘れられたPDFの中に眠っているベストプラクティスを取り出し、人々が働いている最中にその目の前へ届けます。イネーブルメントを見直しているなら、Revnewoのようなプラットフォームがライブシグナルから適切な瞬間に適切なプレイをどう届けるかを見てみてください。PDFライブラリは引退させられます。