営業デモの作り方と見せ方｜BtoBの商談は「動くもの」で前に進む

「画面は見てもらえたのに、次の打ち合わせが決まらない」。デモの操作手順が整っていても、相手が社内で何を確かめるのかが空欄のままでは商談を引き継げません。問い合わせ対応を題材にした台本と合意メモの記入例で、その空欄を埋めます。

以下の記入例は本稿で作成した架空の業務例で、SAIの顧客案件や成果の報告ではありません。参照するGongの分析は同社が公表した商談の観察結果です。特定の見せ方による因果効果や、日本の中小企業における成果を保証するものではありません。

営業デモは、相手と商談後の判断から型を選ぶ

図は営業デモで使える見せ方と、それぞれで狙う伝わり方を並べたものです。効果の大小や受注率を比べた図ではありません。どの型を使う場合も、先に「誰に・何を確かめてもらうか」を置きます。

現場の担当者が知りたいのは、自分の仕事に置き換えたときに使えるかどうかです。管理者なら承認や担当交代の扱い、情報システム担当なら既存環境への接続が判断材料になります。出席者の肩書だけで決めず、その場で担当範囲を確認してください。

表は横にスクロールできます。

商談の開始時には「今日は問い合わせの振り分けを確認し、担当部署で試すかどうかを相談したい」と目的を言葉にします。相手の目的が違えば、用意したデモの一部を見せない判断もできます。全機能を説明し終えることをゴールにしないでください。

Salesforceの公式教材も、顧客の業界や業務を理解し、確認できた課題を基に一緒に方策を作る進め方を示しています。公開情報だけで課題を決めつけず、相手と確かめる順序が参考になります（Salesforce Trailhead「Customer-Centric Discovery」、2026年9月21日確認）。

台本には、入力・操作・出力・確認したいことを書く

機能一覧を台本にすると、ボタンの説明が続きます。相手の仕事を題材にするときは「どんな情報が届き、誰が処理し、何を見て判断するか」を一続きにしてください。業務そのものが整理できていなければ、先に営業業務の棚卸しと自動化の対象選びから着手します。

次は「問い合わせの引き継ぎが抜ける」という仮の課題を置いた記入例です。業種・使うツール・担当の分け方は、自社の商談に合わせて書き換えます。

台本ができたら、画面を作る前に各行を読み返します。「その出力を見ても何を判断するか分からない」なら、機能を足す前に確認する課題へ戻ってください。

見せるデータは、相手が日常で扱う情報の形式に寄せます。ただし取引先名や個人情報を持ち込む必要はありません。架空の情報でも、空欄や曖昧な依頼が混じるようにすると確認したい工程を表せます。実データを使う場合の承認範囲や持ち込み先は、生成AIの社内利用ルールと合わせて確かめます。

生成AIやコーディング支援ツールは、試作の下書きを作る選択肢になります。生成した画面や処理は事前に動作を確認し、商談で見せる場面を絞ります。準備に要する時間は連携先やデータの状態によって変わるため、一律に短時間で完成すると見込まないほうがよいでしょう。

見せる順番は、相手が確認したい課題に合わせる

相手が引き継ぎの抜けを心配しているなら、最初にその状況が分かる一覧を見せます。そこから必要な入力や操作へ戻れば、設定画面の説明に入る前に用途を共有できます。管理者向けの機能が充実していても、その場の確認事項でなければ後に回します。

Gongは商談記録の分析から、成約したデモに事前の課題確認と対応したテーマの順序が見られたと報告しています。説明を続けるより、顧客との短い対話を挟むことも勧めています。古い調査に基づく公表記事であり、特定の台本を使えば成約するという実験結果ではありません（Gong「Effective strategies for conducting successful sales demos」、2017年9月14日公開・2026年3月4日更新・2026年9月21日確認）。

前の台本なら、画面を切り替えるごとに問いを置けます。

• 一覧を見せた後：「引き継ぎを確認するうえで、足りない項目はありますか」
• 担当候補を表示した後：「同じ問い合わせでも、担当が変わる条件はありますか」
• 保留にした後：「この状態を確認する方は、今日の出席者に含まれていますか」

回答を聞いていないのに画面だけ進めると、前提がずれたまま最後まで説明してしまいます。「便利そうですね」という感想が出たときも、どの仕事で使えると感じたのかを一段具体に聞きます。

相手に操作してもらう場合は、説明を覚えたかを試す場にしないでください。「この問い合わせを担当へ渡してください」のように仕事を依頼し、止まった場所を記録します。説明を足さないと使えなかった箇所も、次の修正材料です。

試作で動いた範囲と、本番で未検証の範囲を分ける

デモの画面が動くことと、本番の業務を預けられることは別に確認します。たとえば担当候補を表示できても、退職者の権限削除や連携先の停止への対応を検証したことにはなりません。

英国政府のGOV.UK Service Manualは、試作のコードには本番と同じセキュリティや負荷対応が備わっているとは限らないと説明しています。そのまま本番へコピーしないよう求めているのは、見た目の完成度では判断できない条件が残るためです（GOV.UK「Making prototypes」、2016年10月18日公開・2026年9月21日確認）。

次の表は、本稿が提案する確認欄です。前述の架空例を使い、実演した範囲と残る確認を分けています。

表は横にスクロールできます。

「未検証」を隠さずに書くと、次の打ち合わせに呼ぶべき人も分かります。権限の話なら管理者、判断の例外なら現場担当者が必要です。デモにいなかった人の承認まで、その場で済んだ扱いにしないでください。

デモで得た反応を本番の計画へ移す段階では、PoCから本番運用へ進むための確認事項に分けて整理できます。営業デモの台本に運用設計をすべて詰め込む必要はありません。

商談後のメモには、確認担当と判断期限を残す

デモで出た要望を機能の追加依頼としてだけ記録すると、作った後に何を確かめるかが抜けます。相手が解決したい仕事と、その判断に必要な材料を残してください。

以下は商談後に共有する合意メモの記入例です。台本と同じ架空の問い合わせ対応を題材にしています。実際には相手が合意した内容だけを書き、まだ決まっていない欄は未定とします。

メモを送るときは「認識が違う箇所を教えてください」と添え、合意した事項と提案側の宿題を区別します。参加していなかった決裁者にも渡るため、デモを見ないと分からない略語や画面名だけで書かないようにします。

デモ後の動きは、次の確認日の合意・必要な関係者の参加・検証や受注への移行に分けて記録します。対象案件数と同じ期間をそろえて見ても、顧客層や案件の成熟度が違えば単純比較はできません。受注した理由をデモだけに帰さず、どの疑問が解消したかも残します。

課題が未確認なら、デモの作り込みを止める

デモを作る前に確認したほうがよい場面もあります。価格や契約条件だけが検討材料なら、条件を整理した資料で進められることがあります。業務の流れが相手にも分からないなら、試作より現場への聞き取りを先に置きます。

特に次の状態では、画面を増やすほど準備と説明の負担が増えます。

• 誰の判断に使うか決まっていない：出席者と確認事項を決め直します。機能の要望だけを集めないようにします。
• 例外をすべてその場で作ろうとしている：変更内容を記録して持ち帰ります。既存の動作確認を崩す変更は、商談中に無理に反映しません。
• 試作を完成品と受け取られている：本番接続や運用の未検証項目を示し、依頼されている範囲を確認します。
• 実演の復旧に話す時間を使っている：確認用の画面や録画へ切り替えます。録画は事前に撮ったものであると伝え、その場で動いているように装いません。

完成度を一律の割合で決めるより、今回確かめる場面が動くかどうかで準備を区切ります。逆に見た目が整っていても、判断に必要な場面が示せなければ準備を終えたとは言えません。

SAIの視点：動くものを見せた後の判断まで設計する

新規事業の商談では、まだ確かめていない仮説が画面の中に混ざります。顧客の反応を聞いてから作る範囲が変わるため、実演と本番の約束を混同しないことが大切です。

株式会社SAIの新規事業開発支援では、エンジニアが企画から入り、動くデモの開発や商談同席を通じて想定顧客の反応を確かめます。事業の立ち上げから検討する自責〜JISEKI〜も提供しています。

相談の際には、見せたい機能の一覧に加えて「相手に確かめたい課題」と「商談後に決めたいこと」をお送りください。本文の台本を使い、動くものが必要な場面と資料で足りる場面から検討します。営業デモについて相談する。