静的なプレイブックから動的なオーケストレーションへ

ほぼすべてのレベニューチームがプレイブックを持っています。しかし、実際に機能しているものを持つチームはずっと少数です。たいていはステージ、プレイ、テンプレート、ベストプラクティスをまとめたデッキやWikiページで、RevOpsが組み立て、キックオフでお披露目され、その後レップが勘に戻り市場がそのドキュメントの内容を追い越していく中で、じわじわと放棄されていきます。2カ月目以降、誰もそれを開かなくなります。プレイブックが失敗するのは、内容が間違っているからではありません。静的だから失敗するのです。意図された行動のスナップショットであって、その行動を実際に起こさせたり、スナップショットを最新に保ったりする仕組みが何も付いていないのです。

動的オーケストレーションとは、プレイブックがドキュメントであることをやめ、システムになったときの姿です。プレイの内容自体は変わりません。変わるのは、プレイブックがリアルタイムのシグナルを読み取り、適切な瞬間に適切なアクションをレップの目の前に置き、その後何が起きたかに注意を払うようになるという点です。

静的なプレイブックが陳腐化する理由

静的なプレイブックには、あらかじめ期限が組み込まれています。それが描く世界が動き続ける一方で、ドキュメント自体はじっとしているからです。私たちは多くの企業でこれが起きるのを見てきましたが、原因はいつも同じ数パターンです。

記憶に依存している。静的なプレイは、レップがその存在を覚えていて、その瞬間を認識し、実行することを選んだ場合にのみ発動します。レップが他に40件の案件を抱えているある火曜日、プレイと買い手との間には3つの失敗ポイントがあることになります。

見ることができない。ドキュメントは、特定の買い手が今何をしているかをまったく把握していません。だから、レップに「今がこのプレイを実行すべき瞬間だ」と伝えることができません。

そして学習しない。あるプレイがコンバージョンしなくなっても、Wikiページの中では何も気づきません。人間がたまたま監査するまで、同じ負けパターンを推奨し続けます。そしてその監査は、たいてい永遠に行われません。

これらを組み合わせると、ほとんどのセールスプレイが現場で静かに死んでいくというおなじみのパターンが生まれます。アイデア自体が悪かったわけではありません。ただ、その成果物にはそれを実行させ、タイミングを図り、改善する手段が何もなかったのです。

動的オーケストレーションが実際に意味すること

動的オーケストレーションは、プレイブックの中にある思考（ステージ、プレイ、クオリフィケーションロジック）をそのまま保持しながら、ドキュメントには持ち得ない能力でそれを包み込みます。

1つ目はセンシングです。システムはスタック全体からシグナルを継続的に取り込みます。プロダクト利用状況、エンゲージメント、CRMの変更、購買委員会の動き、インテントデータ。レップが報告しなくても、何が起きているかを把握します。

2つ目は意思決定です。それらのシグナルをプレイブックのロジックに照らし合わせて、各アカウント・各案件について次に取るべき最善のアクションを導き出します。これは生のシグナルを次善のアクションに変えるための仕組みです。

3つ目は実行です。そのアクションをレップのワークフローに届けるか、自動的に実行し、その後結果を観察してフィードバックすることで、次の意思決定を少しずつ良くしていきます。

印刷された地図とライブナビゲーションは、同じ道路を含んでいます。しかし、経路を再計算してくれるのはどちらか一方だけです。あなたのプレイブックは、その地図に当たります。

それでも、まず良いプレイブックが必要

この注意点は、思われている以上に重要です。オーケストレーションは、与えられたものが何であれそれを増幅します。プレイが曖昧で、ステージがあいまいで、クオリフィケーションが未定義であれば、それを自動化することは、悪いガイダンスをより速く伝播させるだけです。動的オーケストレーションは、再現可能なGTMプレイブックにある思考を置き換えるものではありません。それは、その思考を記憶に頼ることなく、日々確実に実行させるためのものです。

何かをオーケストレーションする前に、明確なトリガーと観測可能な結果を持つプレイが必要です。これはきちんと行われたセールスプレイの解剖学そのものであり、システムがいつ発動すべきか、うまくいったかどうかをどう判断すべきかを知るために必要です。買い手の状態を定義しておく必要もあります。そうすればルーティングは案件ステージだけでなく行動に基づいて動かせます。そして明確なオーナーシップも必要です。そうすればアクションはキューではなく特定の人物のもとに届きます。

これらを紙の上でまず正しく整えてください。そうすればオーケストレーションは、良い静的プレイブックを生きたものに変えることができます。しかし、あなたが省略した中身までは発明してくれません。

大がかりな作り直しなしで移行する

多くのチームは、この移行を再プラットフォーム化プロジェクトとして扱うことでつまずきます。そうする必要はありません。私たちの経験でうまくいく道筋は、段階的で、いくぶん地味なものです。

まずは価値の高いプレイを1つ選ぶことから始めます。明確なシグナルと、失敗した場合の痛みが大きいもの、例えば停滞案件の再エンゲージメントや、チャンピオン離脱時のプレイなどです。そのトリガーと配信を組み立て、ループが閉じることを証明します。

自動化する前に可視化する。システムが自らアクションを起こす前に、まずは適切な瞬間にシグナルを見えるようにするだけにします。「このアカウントがXをした」という事実を適切なレップに適切なタイミングで提示するだけで、多くの場合それだけで大部分の効果が生まれます。

次にフィードバックループを加えます。提示されたプレイがコンバージョンしたかどうかを追跡します。これは静的なプレイブックには決してできないことであり、動的なプレイブックを時間とともに改善させる要因です。

1つのプレイでパターンがうまく機能したら、プレイごとに拡張していきます。プレイブックを書き直しているのではありません。各プレイを順番に生き返らせているのです。

この進め方は、オーケストレーションにおける最大の失敗モード、つまり壊れたプロセスを大規模に自動化してしまうことからも守ってくれます。スケールさせる前に各プレイを検証することで、システムが十分な信頼を得るまで人間をループの中に留めておけます。

主なポイント

• 静的なプレイブックは、記憶に依存し、リアルタイムの買い手行動を見ることができず、結果から学習しないために死んでいく。
• オーケストレーションは、既存のプレイの上にセンシング、意思決定、実行を加え、フィードバックループが円を閉じる。
• オーケストレーションは与えられたものを増幅する。曖昧なプレイは、より速く曖昧に実行されるだけである。
• まず紙の上でプレイブックを直す。明確なトリガー、観測可能な結果、定義された買い手の状態、アクションごとに1人のオーナー。
• 一度に1つのプレイずつ進め、アクションを自動化する前にシグナルを可視化する。

静的から動的への移行は、ほとんどのレベニューチームの目の前に置かれている最大のアップグレードです。それは、誰も開かないドキュメントを、行動するシステムへと変えるからです。レベニューオーケストレーションプラットフォームが、大がかりな刷新なしにそれをどう実現するかを知りたい方は、レベニューオーケストレーションとは何かから始めてみてください。