IT営業のデモシナリオは、操作する順番より先に「参加者が何を判断できれば次へ進めるか」を決めると整理しやすくなります。全機能を短時間で見せることが目的になると、顧客が気にしている業務や導入条件への説明が薄くなります。
この記事では、商談でのデモを準備するためのひな型を示します。例は説明用であり、当社の導入実績や検証結果ではありません。
デモで確認することを一つの文にする
Microsoft Learnは、デモを関係者との要件確認に役立てる方法を紹介し、既製品のデモ、プロトタイプ、PoCなどを分けています。また、見た目が完成していても、本番運用に必要な機能が揃っているとは限らないことを説明するよう促しています。Microsoft Learnのデモ教材
たとえば「申請の承認状況を管理者が追えるかを確認する」という目的なら、申請入力、承認待ちの一覧、差し戻し後の状態までを一続きで見せます。管理画面の全メニューを紹介する必要があるかは、その目的から判断します。
参加者に現場担当と決裁者がいる場合は、同じ画面を見る理由を分けます。現場担当には操作と例外処理、決裁者には確認できた範囲と残る導入条件が必要です。
シナリオに残す五つの欄
次の表は準備用の提案です。製品名だけを入れた台本よりも、説明の根拠と不足を共有しやすくなります。
| 欄 | 書く内容 | 仮の申請業務の例 |
|---|---|---|
| 判断事項 | 顧客が確かめたいこと | 承認待ちを担当者が把握できるか |
| 前提 | 利用者・権限・データの状態 | 申請者と承認者を分けたサンプル環境 |
| 操作 | 説明と一緒に行う流れ | 入力、申請、承認待ち一覧の確認 |
| 見せる根拠 | 画面上で確認する結果 | 状態と担当者が表示されること |
| 残る条件 | デモだけでは判断できない点 | 実際の承認規程への適合、既存システムとの連携 |
「対応できる」とだけ書かず、標準機能で見せる部分、設定した部分、画面だけの試作部分を区別してください。将来開発する予定の機能を、現在使える機能として説明しないためです。
正常な流れに、判断に必要な例外を足す
例外を無制限に並べると本筋が見えにくくなります。顧客の懸念に直結するものを選び、どこまで実演し、どこを別の確認に回すかを決めます。
申請の例なら「入力の不足を戻せるか」「承認者が不在の場合はどう扱うか」が候補です。デモ環境で再現できない条件は、できたように説明せず、製品資料で確認するのか追加検証が必要なのかを宿題にします。
表示にサンプルデータを使う場合は、その旨を伝えます。実データの量や権限構成と異なる環境で動いたことだけをもって、本番の性能や運用の適合まで保証しないようにします。
リハーサルでは役割と復帰地点を確認する
画面が順調に動くかだけでなく、説明が止まったときの扱いも確認します。以下は準備チェックの例です。
- 説明役と操作役が異なる場合、切り替えの合図が決まっている。
- 開始前のデータと操作後の状態が分かり、次回のために戻せる。
- 通信や環境の問題が起きた場合、静止画や資料で説明する範囲を明示できる。
- 質問で寄り道しても、どの画面から本筋に戻るかが分かる。
- 回答できない事項を記録する担当がいる。
静止画へ切り替えた場合も、実演が完了した扱いにはしません。「今日はここまで確認できた」と結果の範囲を残します。
終了時は感想よりも次の判断材料を残す
デモ後は「好評だった」で終えず、確認できた事項、顧客との認識差、追加で必要な根拠を分けます。宿題には担当、回答する内容、次に判断する場を付けます。期限が決まっていなければ、その決定自体を残してください。
提案全体の比較軸を先に揃えたい場合は、提案比較表の作り方も参照できます。デモで得た反応は、機能評価だけでなく、提案の前提や確認条件を更新する材料になります。
まずは次の商談について、判断事項を一文、見せる流れを一つ、残る条件を一つ書いてみてください。その三点が揃うと、追加する画面と省く説明を選びやすくなります。