担当者が実際に使うセールスプレイブックを作る

ほとんどすべての営業組織には、どこかにプレイブックがあります——共有ドキュメント、Wikiページ、前回のセールスキックオフのスライド資料などです。しかし最初の2週間を過ぎると、そのほとんどが開かれなくなります。それは担当者が怠けているからでも、内容が間違っているからでもありません。ほとんどのプレイブックが、担当者が実際に使う必要のある方法ではなく、教科書が作られるやり方で作られているからです。担当者は通話前にプレイブックを座って勉強することはありません。彼らが必要としているのは、本番で応答しなければならない30秒前の、一つの特定の問題への答えです。プレイブックがそれを提供できなければ、それはツールであることをやめ、棚に眠る資料になります。

静的な文書の問題

典型的なプレイブックは一度だけ書かれ、通常はイネーブルメントやプロダクトマーケティングのチームによって、会社概要、理想的な顧客プロファイル、競合ポジショニング、メソドロジー概要、反論対応の付録といった抽象的なカテゴリーを中心に構成されます。それは包括的で、善意に基づいていますが、担当者が実際に助けを必要とする瞬間からはほぼ完全に切り離されています。プロスペクトが「すでに競合製品を使っていて、乗り換える理由が見当たりません」と言ったとき、担当者は本番中にPDFの34ページ目までスクロールすることはありません。彼らはその場しのぎで、しかもうまくいかない対応をすることになり、プレイブックは唯一の仕事に失敗したことになります。

さらに悪いことに、この種のプレイブックはたいてい、開始日と終了日のあるプロジェクトとして扱われます。公開されると、イネーブルメントは次の施策に移り、6か月後には価格が変わり、競合状況も変化しているのに、誰もその文書に手を付けていません。担当者はそれに気づきます。一度プレイブックが間違っていたり古くなっていたりしたことがあると、担当者はそれを信頼しなくなり、修正された後でさえ開かなくなってしまいます。

理論ではなく瞬間を中心に整理する

解決策は、構成を完全にひっくり返すことです。抽象的なセールス理論を中心とした章立てではなく、担当者が通話で実際にぶつかる特定の瞬間——定義された一連のよくある反論（価格、競合比較、「検討します」、タイミング）と、定義された一連のステークホルダータイプ（決裁者、技術評価者、懐疑的なエンドユーザー）——を中心にプレイブックを構成しましょう。各エントリは短くあるべきです——1、2文のフレーミングと、その瞬間にトップ担当者が実際に使う言葉——そして、担当者が推測しなければならない章タイトルではなく、シナリオで検索できるようにしましょう。

これはまた、プレイブックに属さないものについて規律を持つことも意味します。会社の一般的な背景情報、組織図、社内プロセスの文書はまったく別の場所に置くべきです。リファレンス資料と通話中の言葉を混在させたプレイブックは検索が速くなくなり、速さこそがすべての要点です。担当者が必要なものを30秒以内に見つけられなければ、それは役割を果たしていません。

本物の商談との接触に耐えるプレイブックのためのチェックリスト

• すべてのエントリが、一般的なトピックではなく特定の反論やステークホルダータイプを中心に構成されている。
• 各エントリは1画面に収まり、実際に使う言葉を見つけるためにスクロールする必要がない。
• 各エントリの言葉は、ホワイトボードセッションから書かれたものではなく、トップ担当者が実際に言って効果があったものである。
• 更新を担当する所有者がおり、レビューの頻度（年次ではなく月次）が定義されている。
• 担当者がプレイブックでまだカバーされていないシナリオを発見したら、新しいエントリが追加される。
• 担当者が、ある言い回しが効かなくなったと気づいたときにフラグを立てる手段があり、廃止や書き直しができる。

一度きりのプロジェクトではなく生きた文書にする

使われるプレイブックと使われないプレイブックの最大の違いは、それが継続的なインフラとして扱われているか、それとも公開済みの成果物として扱われているかです。新しいプレイブックのコンテンツの最良の情報源は戦略合宿ではなく、まさに今起きている通話です。特定の反論を一貫して和らげるフレーミングを見つけた担当者は、実質的に現場でテストされたコンテンツを持っており、それは次の四半期の更新のときではなく、すぐにプレイブックに反映されるべきです。それを浮かび上がらせるための軽量なプロセス——Slackチャンネル、チームミーティングでの定例5分間のアジェンダ項目、CRMのタグなど——を構築することで、プレイブックを大きな年次プロジェクトに逆戻りさせることなく最新の状態に保てます。

なぜプレイブックを読むことは使う準備ができていることと同じではないのか

よく作られたプレイブックであっても、それ自体には限界があります。正しい言葉を読むことと、プロスペクトが押し返してくる中でプレッシャーの下、リアルタイムでそれを届けられることは同じではありません。これがプラクティスギャップです——何を言うべきかを知っていることと、それが重要な瞬間に流暢に言えることの間の隔たりです。担当者はプレイブックの競合反論のエントリを10回読んでも、実際にプロスペクトが本番中にその競合名を口にした瞬間に固まってしまうことがあります。なぜなら、読むことはリハーサルではないからです。

これこそが、プレイブックを公開するだけでなく練習することが差別化要因になる部分です。Frontline Coachでは、イネーブルメントチームがプレイブック内の正確なシナリオ——特定の反論、特定のステークホルダーペルソナ——を取り出し、応答が暗記ではなく反射的になるまで担当者が繰り返し実行できるAIロールプレイの練習に変えられます。プラットフォームのプロダクトナレッジ取り込み機能が御社の担当者が実際に販売しているものを取り込むため、ロールプレイはテンプレートに取り付けられた一般的なシナリオではなく、御社の実際の製品と実際の競合状況を反映します。プレイブックの導入は、より広範なメソドロジー導入プランと組み合わせ、プレイブックの根底にあるフレームワークを本物のメソドロジーに基づかせましょう——MEDDIC、Challenger、Sandlerの比較をご覧ください——そうすることで、プレイブックはゼロから発明したものではなく、本物のフレームワークを適用したものになります。