バイヤーの行動にリアルタイムで適応するプレイブックの構築

ほとんどのセールスプレイブックは、売り手が次に何をしたいかを中心に組み立てられています。3日目にメール2通目を送る。1週目にデモを予約する。四半期末までにクローズを迫る。これはバイヤーが実際に何をしているかに関わらず押し付けられる、売り手側のシーケンスであり、現実がスクリプトから外れた瞬間に破綻します。そしてそれは常に起こります。バイヤーはあなたのケイデンスでは動きません。彼らは自分のケイデンスで動くのです。

バイヤーの行動に適応するプレイブックは、それを逆転させます。「今どのステップにいるか?」ではなく、「バイヤーは何をしているか、それは次に何をすべきかを何を教えてくれるか?」を問うのです。ケイデンスを組むよりも構築は難しくなります。しかしそれこそが、B2Bバイヤーが今実際にどう振る舞っているか——自己主導的で、順序がバラバラで、エンゲージすると決めるまでほとんど見えない——に追いつける唯一の種類のプレイブックです。

静的なケイデンスは破綻する

静的なケイデンスは、すべてのバイヤーが同じ速度で同じ道をたどると仮定しています。実際の購買の旅はそれとはまったく異なります。あるプロスペクトは3週間沈黙した後、契約準備が整った状態で戻ってきます。別のプロスペクトは熱心にエンゲージし、社内であなたの資料を転送しておきながら、会ったこともないステークホルダーが聞いたこともない異議を唱えたために停滞します。硬直したシーケンスは両者を同じように扱い、両方のタイミングを外します。

そのコストは大きく、そしてほとんど目に見えません。準備ができていないバイヤーへの無駄なタッチは、彼らにあなたを無視することを学習させます。バイヤーが準備完了のシグナルを出しているのに、その日ケイデンスが担当者に無関係なことをさせている、機会の逃失。そして本当の動き(社内転送、繰り返しの訪問、スレッドへの新しい名前の登場)がスクリプトの外で起きても誰も気づかない、盲点。

静的なプレイブックは、多くのセールスプレイが現場で死んでいく主な理由の一つです。それらは存在しない平均的なバイヤーのために書かれたものだったのです。

3つの層

適応型プレイブックには、静的なプレイブックにはない3つの層があります。

シグナルとは、バイヤーがどのような状態にあるかを明らかにする観察可能な行動です。ウェブサイトや価格ページへの訪問、コンテンツのダウンロード、メールのエンゲージメントパターン、PLGモーションにおけるプロダクト利用、ステークホルダーの変化、社内で転送された提案書、音信不通になること。シグナルがなければ、適応すべき対象自体がありません。

ルールはシグナルを意味にマッピングします。「1週間で3回の価格ページ訪問に加え、スレッドに新しいステークホルダーが加わった、これは能動的な評価段階を意味する」といった具合です。ルールはノイズの多い行動を、行動可能な状態に変換します。

レスポンスは、ルールが一致したときに発動するプレイです。それぞれがトリガー、ターゲット、アクション、結果を備えた正式なセールスプレイですが、今回のトリガーはカレンダー上の日付ではなく、バイヤーが行ったことです。

興味深いのはこのループです。シグナルがルールに供給され、ルールがレスポンスを選び、レスポンスが新たなインタラクションを生み、それが新たなシグナルを生む。プレイブックは12番目のステップまで盲目的に進むのではなく、常に調整を続けます。

バイヤーの状態を中心に組み立てる

案件ステージは、案件がどこにあると自分たちが考えているかについての社内的な会計処理です。バイヤーの状態は、バイヤーが実際にどこにいるかです。この二つは誰もが認めたがる以上に頻繁に食い違い、適応型プレイブックがうまく機能するのは、後者を中心に組み立てられているからです。

最近のエンゲージメントがない休眠アカウントには、「様子を伺っています」的なメールではなく、関連性のある何かに結びついた軽い再エンゲージメントプレイを行います。より多くのコンテンツやサイトでの活動を示しているものの直接的な接触がない探索中のアカウントには、好奇心に踏み込みすぎない有益なアウトリーチを行います。価格ページへのエンゲージメント、複数のステークホルダー、直接的な質問など、能動的に評価しているアカウントには、マルチスレッド化とビジネスケースのプレイを行います。そして活発だったのに案件の途中で静かになったアカウントには、隠れたブロッカーを表面化させるために設計された停滞診断プレイを行います。

それぞれの状態に固有のプレイがあります。バイヤーは自分の行動に基づいて状態間を移動し、しばしば後戻りします。ステージベースのプレイブックにはそれを表現する方法がありません。この状態駆動型の設計こそが、静的なプレイブックから動的なオーケストレーションへの移行をそもそも実現可能にするものです。

リアルタイムは本当にリアルタイムでなければならない

これはほとんどのチームが間違える部分です。バイヤーが価格ページを5回訪問したというシグナルも、担当者が3日後の週次レポートでそれを見るのでは価値がありません。窓は閉じてしまっています。適応性はレイテンシの関数です。シグナルを検知しレスポンスを表示するのが早ければ早いほど、そのプレイのコンバージョン率は高くなります。

2つのことが本当に成り立っていなければなりませんが、ほとんどの手動プロセスはどちらも満たしていません。シグナル捕捉は常時稼働していなければなりません。担当者に一日中十数個のデータソースを監視させるわけにはいかないからです。そして推奨されるプレイは、シグナルが発火した瞬間に、担当者が金曜日にチェックするダッシュボードではなく、すでに作業している場所に表示されなければなりません。

これこそがレベニューオーケストレーションプラットフォームが実現するために作られたものです。シグナルを継続的に読み取り、それが重要になる瞬間に次善のアクションへと変換します。この層がなければ、「適応的」は素晴らしいアイデアのままにとどまります。なぜなら、どんな人間もすべてのバイヤーを毎分監視することはできないからです。

重要なポイント

• 静的なケイデンスは均一なバイヤーを前提としています。そのようなバイヤーは存在しないため、無駄なタッチ、機会の逃失、盲点が生まれます。
• シグナル、それを解釈するルール、発動するレスポンス。これが構造であり、それらの間のループこそが適応性を生み出します。
• 案件ステージではなくバイヤーの状態を中心にプレイを組み立てましょう。バイヤーは順序を無視して、時には後戻りしながら動きます。
• レイテンシがすべてです。3日遅れて見つかったシグナルは、すでに閉じた窓です。
• 誰か、あるいは何かが継続的に監視し、プレイを担当者の目の前に提示しなければなりません。それは担当者の仕事ではなく、システムの仕事です。

実際の行動に反応するプレイブックは、再現可能なGTMプレイブックが固定シーケンスであることをやめたときにたどり着く先です。バイヤーシグナルが適切なタイミングで適切なアクションに変わる様子を見たいなら、レベニューオーケストレーションがその出発点です。