オートパイロットが乗っ取る前にSaaSデモを練習する
月に何十回も同じデモを行うこと自体が、本番での失敗を招きます。各コールの前に実際にリハーサルすべきこと——スクリプト全体をもう一度ではなく、壊れやすい部分だけをご紹介します。
デモ不要 · 契約不要 · いつでもキャンセル可能
クイックアンサー
件数の多いSaaSデモが本番で失敗するのには予測可能な理由があります。担当者が、このプロスペクトがディスカバリーで実際に言ったことに合わせて調整するのではなく、標準スクリプトをオートパイロットで実行してしまい、予期しない質問や本番中の不具合に不意を突かれるのです。解決策はデモ全体をもう一度リハーサルすることではなく、そのアカウント特有のピボットポイント、想定される最も難しい質問、そして通話に臨む前のきれいな立て直しの動きをリハーサルすることです。
SaaS営業は、他の営業モーションではあまり見られないほどデモの件数に依存しています。ミッドマーケットやエンタープライズのSaaS企業の担当者は、まったく異なるユースケース、技術スタック、懸念を持つプロスペクトを相手に、同じコアデモを月に20回、30回、40回と実行することがあります。その件数の多さは製品への本当の流暢さを築きますが、同時に特定の、予測可能な失敗モードも築いてしまいます——オートパイロットです。10回目あたりのどこかで、担当者はこのプロスペクトがディスカバリーで実際に言ったことにデモを積極的に合わせることをやめ、慣れていて以前うまくいったバージョンを実行し始めます。それこそが、標準スクリプトがカバーしていないことをプロスペクトが尋ねたときに壊れるバージョンなのです。
なぜ件数の多さが、本来防ぐべき失敗をまさに引き起こすのか
直感的な想定では、担当者とデモの件数が多いほど本番での驚きは少なくなるはずです——結局、すべては以前に聞かれたことがあるのだから、と。しかし実際には、件数の多さは特定の通話に対する個々の担当者の準備には逆の効果をもたらすことが多いです。なぜなら、単純な反復が標準フローを筋肉記憶に刻み込む一方で、調整のステップ——通話前にこのプロスペクトのディスカバリーメモについて実際に考える必要があるステップ——は、担当者が忙しくなるにつれて省かれてしまうからです。その結果、一般的な部分は洗練されて見えるものの、プロスペクトの実際の状況がテンプレートから外れる部分でまさに崩れてしまうデモが生まれます。自分のユースケースに当てはまらない機能、言及されていなかった必要な連携、あるいはオートパイロット状態の担当者が優雅に対処するリハーサルされた方法を持っていない技術的な不具合です。
「デモを練習する」ではないデモ前チェックリスト
「デモを練習する」というのは、ほとんどの経験豊富な担当者がすでに卒業している一般的なアドバイスです——彼らはデモを知っています。実際にライブでの驚きを減らすのは、毎回同じ部分ではなく、このプロスペクトに固有の部分を狙った、より狭く具体的な種類のリハーサルです。
- ピボットポイント。このプロスペクトがディスカバリーで言ったことに基づいて標準フローから逸脱する2、3の瞬間を特定します——当てはまらないモジュールをスキップする、彼らが特に尋ねた1つの機能でじっくり時間をかける、表明された優先事項に合わせてフローを並べ替える、といったことです。
- そのアカウントにとって最も難しい質問。彼らの技術スタック、表明された競合評価、あるいはディスカバリーで挙げられた懸念に基づいて、最も出てきそうな2、3の質問を特定し、箇条書きだけでなく、実際の答えを声に出してリハーサルします。
- 立て直しの動き。環境が壊れたり、機能が読み込まれなかったり、デモアカウントのデータが古かったりした場合に、何を言い、何をするかをあらかじめ決めておきます——パニックのようには聞こえないほど十分にリハーサルされた、簡潔で落ち着いた確認とバックアップ手段へのきれいな切り替えです。
ピボットポイント
最も難しい質問
本番での立て直し
なぜ練習がディスカバリーメモの見直しに勝るのか
ほとんどの担当者はデモの準備を実際に行っています——ディスカバリーコールのメモを読み返し、プロスペクトのウェブサイトを確認し、競合比較シートにも目を通すかもしれません。それは本物の準備であり、完全に受動的なものです。そのどれも、調整済みバージョンのピッチを声に出して言うことや、プロスペクトが本番で尋ねる前に最も難しい質問に実際に答えることを含んでいません。このサイト自身のSaaS営業に関する表現にあるように、チームは人数を増やすのであってスキルを増やすのではありません——40回デモをこなした担当者は件数を持っていますが、41回目のプロスペクトの特定の状況への準備を必ずしも持っているわけではありません。メモを見直すことと実際の調整された会話をリハーサルすることの間にあるこのギャップがThe Practice Gapであり、それが良いデモを実際のプロスペクトとの接触に耐えるデモへと変えるのです。
Frontline Coachでデモを練習する
Frontline Coachでは、担当者は本番のコールの前に特定のプロスペクトのデモをロールプレイできます——一般的なSaaSバイヤーではなく、担当者自身の製品とそのアカウントの実際のディスカバリーメモから構築されたシナリオなので、練習はその商談における実際のピボットポイントと実際の難しい質問を狙ったものになります。Frontline Coachのプロダクトナレッジ取り込み機能が担当者自身の実際の製品コンテキストから情報を取り込むため、シナリオは別の研修セッションを必要とせず数分で設定できます。プラットフォームが件数の多いデモチームに具体的にどう適合するかはSaaS向けFrontline Coachページを、一人の担当者やチーム全体がどう始められるかは料金プランをご覧ください。Frontline Coachは月額$9.99からのセルフサーブで始められ、次のデモの練習を始めるのにデモは必要ありません。
よくある質問
経験豊富なSaaS担当者でも、なぜデモが失敗することがあるのですか？
件数の多さがオートパイロットを生みます。月に何十回も同じデモを行う担当者は、このプロスペクトがディスカバリーで実際に言ったことに合わせて調整するのではなく、自然と標準スクリプトを実行するようになります。オートパイロットは、プロスペクトが予期しない質問をしたり、自分のユースケースに当てはまらない機能に言及したり、環境に不具合が起きたりするまでは問題ありません——そして、まさにそのときに、リハーサルしていない担当者は本番で不意を突かれてしまうのです。
デモ全体ではなく、担当者が実際に何をリハーサルすべきですか？
デモ全体を最初から最後まで通してリハーサルすることは必要ですが、それだけでは十分ではありません。より効果の高い準備は、ピボットポイント——ディスカバリーで学んだ内容に合わせて標準フローを調整する2、3の瞬間——と、そのアカウントの技術スタック、競合評価、あるいは表明された懸念に基づいて聞かれる可能性が高い2、3の最も難しい質問をリハーサルすることです。
本番中にデモが壊れた場合——バグ、読み込みの遅さ、環境の問題——担当者はどう立て直すべきですか？
謝罪してプロスペクトの前でその場で直そうとする本能は、たいてい事態を悪化させます。リハーサルされた立て直し——問題を簡潔に伝え、バックアップの手段（録画したクリップ、別のアカウント、ホワイトボードでの説明）に移り、プロスペクトの本来の質問に戻る——は有能さとして受け止められます。リハーサルされていない立て直しは、製品が信頼できないという印象を与えます。
デモの件数が多いほど、担当者は本番での予想外の事態にうまく対応できるようになりますか？
自動的にはそうなりません。デモの件数が多い担当者は標準フローが速くなることが多いですが、それは予期しないことが起きたときに柔軟に対応し続けるスキルとは別物です。予想外の瞬間を明確に狙った意図的な練習がなければ、件数が多いことは単に同じ慣れたスクリプトを繰り返すだけを意味し、それこそがスクリプトが通用しないときに失敗する筋肉記憶そのものです。
Frontline Coachは、一般的なデモシナリオだけでなく、特定のプロスペクトの反論もシミュレートできますか？
はい。Frontline Coachのプロダクトナレッジ取り込み機能により、担当者は自社の実際の製品と特定のアカウントの想定される懸念に基づいたロールプレイを構築できます。そのため、練習セッションはその商談における実際のピボットポイントと難しい質問を狙ったものになります——画一的なデモスクリプトではありません。