監修：平野 哲也（株式会社オンリーストーリー 代表取締役）

営業デモで多くの機能を見せたのに、商談後の反応が曖昧なまま終わることがあります。

デモの目的は全画面を見せ切ることではなく、顧客が次の検討に進める状態をつくることです。

営業デモとは

営業デモとは、商品やサービスを実際に動かして見せ、導入後の状態を相手に確かめてもらう場です。

製品デモンストレーション、操作デモ、実演といった呼び方をされることもあります。

資料の説明と違うのは、相手が自分の業務に当てはめて確かめられる点にあります。

そのため、見せる機能の多さではなく、相手が確認したいことに答えられたかで評価が決まります。

この記事では、準備から当日の進め方、振り返りまでを順に整理します。

デモの前に確認したい五つの情報

デモの準備では、製品の説明順を考える前に、顧客が今回知りたいことを整理します。

次の五つを確認すると、見せる画面、説明の深さ、時間配分を選びやすくなります。

対象となる業務と困りごと

最初に、誰がどの作業で困っているのかを確認します。

情報共有を改善したいという要望だけでは、どの機能を見せるべきか決まりません。

担当者から承認者への申請が遅れる、案件情報を複数の表へ転記しているなど、実際の行動まで具体化します。

可能なら、現在の作業が始まるきっかけ、途中の確認、完了条件を聞きます。

業務の流れが分かれば、デモでも同じ順序で操作を見せられます。

参加者の役割と確認したいこと

現場担当者は日々の操作負担、管理者は進捗の見え方、情報システム部門は管理機能など、関心が異なる場合があります。

参加者の人数だけでなく、役割と判断事項を把握しましょう。

全員に同じ説明を長く続けるより、共通の業務を見せた後に、役割ごとの確認へ分ける方法があります。

参加者が分からない場合は、当日の冒頭で確認する前提を置き、特定の役割にしか分からない専門的な操作から始めないようにします。

今回の検討段階

情報収集中の顧客と、導入候補を比較している顧客では、必要なデモが異なります。

前者には基本的な業務の流れ、後者には必須要件への対応や制約の確認が役立ちます。

すでに試用している顧客には、一般的な紹介より、実際に困った操作を再現して説明する方が適していることがあります。

検討段階を確認せずに同じ台本を使い続けると、説明の詳しさが合わなくなります。

必須条件と今回答えるべき疑問

デモを見た後、何が分かれば検討が進むのかを事前に聞きます。

担当者ごとに閲覧範囲を変えられるか、既存データをどのように取り込むか、承認の差し戻しに対応できるかなど、確認したい条件を整理します。

デモ画面だけでは判断できない項目もあるため、実演、資料での説明、後日の回答に分けましょう。

要望を受けた時点で、すべて対応できる前提にしないことが大切です。

時間と利用環境

面談時間、対面かオンラインか、画面共有の可否、音声の必要性を確認します。

短時間のデモに詳細な初期設定まで詰め込むと、顧客が最も見たい業務に時間を使えなくなります。

オンラインでは、表示する文字の大きさやウィンドウの切り替え方も確認します。

顧客の画面サイズが分からない場合は、細かな一覧表を一度に見せるより、確認する場所を拡大して説明しましょう。

一つの業務を軸にデモのシナリオを作る

事前に確認した課題を、顧客が実際に行う作業の順番へ落とし込みます。

一つの業務がどう完了するかを軸にすると、複数の機能を見せる場合も説明がつながります。

課題・操作・結果・確認の順で組み立てる

機能名を順番に読む構成ではなく、顧客の課題に対応する業務シナリオを一つ選びます。

たとえば、問い合わせを受けた担当者が内容を登録し、責任者が担当を割り当て、対応状況を確認する流れです。

各場面で、何のための操作か、操作すると何が変わるか、顧客の業務に合うかを順番に伝えます。

操作の前に目的を説明すれば、顧客は画面上の変化を追いやすくなります。

操作の後には、この進め方で御社の担当者間の確認を置き換えられそうか、と具体的に聞きます。

下表は、30分のデモを想定したシナリオの組み立て例です。

場面	見せる操作	確認する問い
導入	操作はせず、今日見る範囲を口頭で示す	見たい業務はこれで合っているか
課題の再現	いまの手作業の流れを画面で再現する	現在の手順はこの通りか
中心の操作	課題が解消される操作を一つだけ通す	この操作は誰が行うか
結果の確認	出力された帳票や通知を見せる	この形のまま現場へ渡せるか
例外の確認	想定外の入力をわざと行う	この例外は実際に起きるか
締め	確認できたことと残った疑問を読み上げる	次に何を用意すればよいか

場面ごとに問いを1つ置くと、感想ではなく判断の材料が集まります。

最初に完成状態を見せる方法もある

入力項目が多い製品では、最初からすべての入力を実演すると、完成までの意味が伝わりにくくなります。

その場合は、処理が終わった状態を先に見せ、どのような情報が確認できるかを説明してから、主要な操作へ戻ります。

ただし、準備済みのデータであることは明確にし、操作しただけで自動的にすべて完成したように見せないようにします。

事前設定が必要な箇所は、設定済みの状態であることと、導入時に誰が設定するのかを補足します。

標準の流れと例外の流れを分ける

基本操作に続いて、差し戻し、入力ミス、担当者変更など、顧客にとって重要な例外を一つ見せます。

すべての例外を扱う必要はありませんが、正常に進む画面だけでは運用を判断しにくい場合があります。

たとえば承認機能なら、承認完了だけでなく、内容の修正が必要になったときの戻し方も確認します。

例外を含めることで、導入後に誰が対応するかという会話につなげられます。

30分の営業デモを行う場合の構成例

以下は時間配分の一例であり、すべての商材に共通する最適な時間ではありません。

時間の目安	内容	確認すること
最初の5分	課題と参加者の確認	今日確かめたいことが一致しているか
次の12分	主要業務の実演	業務の流れと結果が理解できるか
次の5分	例外や必須条件の確認	運用上の懸念が残っていないか
次の5分	質疑と未回答の整理	追加調査が必要な項目は何か
最後の3分	次の行動の合意	誰が何をいつまでに確認するか

質問が多い場合は、後半の説明を短縮し、顧客の疑問に時間を振り向けます。

その際も最後の確認時間は残し、話し切れなかった内容と回答予定をまとめましょう。

製品全体の説明が必要な場合は、今回の目的に合う部分を先に確認し、別の機会を設ける方が整理しやすくなります。

当日の進め方と話し方

当日は、用意したシナリオを進めながら、参加者の理解と確認したい点を確かめます。

操作の速さよりも、顧客が画面の変化を自社の業務に結び付けられる説明を意識しましょう。

冒頭で見せる範囲を共有する

最初に、今日は申請から承認までを確認し、データ移行の詳細は別途整理する、と実演の範囲を伝えます。

顧客が別の項目を優先したい場合は、この時点で調整できます。

一方的に予定を宣言するのではなく、この範囲で本日の確認目的に合っているかを確かめます。

説明する範囲が決まると、途中で別の機能へ話が広がった際にも、扱い方を相談しやすくなります。

操作ごとに画面の見る場所を伝える

ここを押しますという説明だけでは、オンライン参加者が操作箇所を見失うことがあります。

画面右側の承認状況をご覧ください、と場所を伝え、変化が表示されてから意味を説明します。

マウスを素早く動かしたり、複数の画面を続けて切り替えたりせず、顧客が確認できる間を取ります。

操作に慣れた営業担当者ほど、初めて見る人には情報量が多いことを意識しましょう。

感想より業務との一致を聞く

いかがでしょうかという質問だけでは、便利そうですという感想で終わることがあります。

現在の業務では、この確認をどなたが担当されていますか、と具体的な問いに置き換えます。

この通知を受けるタイミングで問題ないか、入力項目に不足がないかなど、顧客が判断できる対象を絞ると、懸念を確認しやすくなります。

反応が少ないときも、関心がないと決めつけず、画面が見えているか、前提が伝わっているかから確認します。

できないことと未確認事項を区別する

質問に即答できないときは、推測で機能を約束しないようにします。

標準機能で対応できること、設定や追加検討が必要なこと、現時点では対応できないことを分けて説明します。

確認が必要な場合は、質問の内容、想定する利用条件、回答予定を記録します。

あとで確認しますという返事だけで終わらず、顧客が何を判断するための質問なのかも聞くことが大切です。

営業デモでトラブルが起きたときの対応

実演が予定どおりに進まない場合は、顧客が確認できた範囲を明確にすることが大切です。

代替資料で説明できることと、後日動作を確かめることを分け、次の確認につなげます。

画面が動かない場合

同じ操作を何度も繰り返すより、まず状況を伝えます。

実演環境で処理が完了しないため、準備済みの画面で結果を説明し、動作は別途確認するというように、説明と未検証部分を分けます。

動画や画像を使う場合は、それが事前に用意した資料であり、現在のライブ操作ではないことを明示します。

不具合の原因が分からない段階で、通信環境や顧客側の設定に原因があると断定しないようにしましょう。

デモ用データに不備がある場合

入力内容や表示結果が想定と違った場合も、都合のよい部分だけを説明せず、確認が必要な箇所を伝えます。

準備した別のシナリオへ切り替えるなら、確認できなかった項目を記録します。

商談後の報告では、何を実演できて、何を再確認する必要があるかを分けます。

デモの完了と、顧客の必須要件を満たす確認の完了は同じではありません。

時間が足りなくなった場合

残り時間を伝え、顧客が優先したい質問を確認します。

営業側の台本を最後まで進めるために質問を切り上げると、重要な疑問が残ることがあります。

未実演の項目を一覧にし、追加面談が必要か、資料で足りるかを合意します。

次回の予定は、追加で何を判断するための時間なのかが分かる形で設定しましょう。

準備段階で確認するチェックリスト

デモ当日の説明に集中できるよう、シナリオと利用環境の準備を合わせて確認します。

次の項目を実演前に見直し、不足があれば担当者と対応を決めておきましょう。

• 顧客の対象業務と、今回確認する疑問が一文で説明できる
• 参加者の役割に合わせた説明箇所が決まっている
• デモ用データで最初から最後まで操作を確認している
• 実顧客の個人情報や秘密情報が画面に表示されない
• 通知や別タブなど、不要な情報が映らない状態になっている
• 実演できない場合の画像や説明資料が用意されている
• 機能の制約、設定が必要な箇所、未確認事項を把握している
• 質問を記録する担当と、回答をまとめる担当が決まっている

このリストは準備漏れを減らすためのもので、顧客ごとのシナリオ作成を置き換えるものではありません。

デモ用データは、対象業務を想像できる程度に具体的であれば十分です。

実際の顧客名や個人情報を使わず、架空の名称であることを分かるようにしておきましょう。

商談後は判断材料を整理して送る

デモで得た顧客の反応や質問は、次の検討に使える形にまとめます。

確認した内容と双方の宿題を残しておくと、参加していない関係者にも商談の状況を伝えやすくなります。

確認できたことと残った疑問を分ける

デモ後のメールでは、資料を添付するだけでなく、確認できた業務、残った懸念、追加回答の予定を簡潔にまとめます。

顧客の発言は、正式に合意したことと、検討中の意見を区別して記載します。

営業側の理解が正しいか確認できる形にすると、次回の打ち合わせで認識を合わせやすくなります。

フォローメールの例

本日はお時間をいただき、ありがとうございました。

今回は、申請の登録から承認状況の確認までをご覧いただきました。

現行の担当者間の確認に置き換えられる可能性がある一方、差し戻し時の通知先について追加確認が必要と認識しております。

通知設定については、いただいた運用条件を基に確認し、合意した期日までに回答いたします。

御社内では、承認担当の方に操作の流れをご確認いただく予定と理解しております。

認識に相違がございましたら、お知らせください。

この例文は架空の商談を想定したもので、実際に確認していない内容をそのまま使わないようにします。

顧客側の行動についても、合意がないものを予定として書かないことが大切です。

営業デモの振り返りで見る指標

振り返りでは、何回デモを実施したかに加え、顧客の疑問がどこまで解消したかを確認します。

数字の定義と対象条件を揃え、説明内容を改善する材料として使いましょう。

実施件数だけでなく確認結果を残す

デモ実施件数だけでは、顧客の検討に役立ったかは分かりません。

顧客が確認したい項目をどこまで扱えたか、未回答が何件残ったか、次の判断行動が合意されたかを記録します。

ここでの次の行動は、単なる日程調整ではなく、利用部門の評価や費用の確認など、導入判断に関わる内容として定義します。

比率の比較は対象条件をそろえる

次の行動を合意した割合を測るなら、対象期間に実施したデモのうち、合意の有無を確認できた件数を分母にするなど、定義を固定します。

未確認の案件は別に残し、合意なしと同じ扱いにしない方法が考えられます。

新規の情報収集段階と、最終比較段階のデモを混ぜると、比率の違いを内容の良し悪しだけでは説明できません。

商材、検討段階、対象顧客をそろえたうえで、質問内容や商談記録と合わせて振り返りましょう。

デモと試用・PoCの役割を混同しない

営業担当者が整えた環境で見せるデモと、顧客の環境で確かめる試用やPoCでは、分かることが異なります。

デモで業務の流れを理解できても、顧客の実データでの処理、社内の運用、既存環境との接続が確認できたとは限りません。

デモだけでは答えられない項目が重要なら、次の検証方法を相談します。

その際、試してみましょうと進める前に、何を確認し、誰が結果を判断するかを決めることが大切です。

顧客の判断に必要な実演から始める

営業デモの質を高めるには、操作の流暢さだけでなく、顧客の業務を理解してシナリオを絞る準備が必要です。

対象業務を一つ選び、操作後の結果、例外の扱い、未確認事項を整理しましょう。

面談する相手との接点づくりが課題の場合は、決裁者マッチングなどの手段を検討できます。

接点を得た後に役立つのは、相手が判断したい内容に合わせた説明です。

営業活動の入口を見直したい場合は、onlystoryのサービス案内を確認し、自社が会いたい相手と相談したい課題を整理してみてください。

まずは次のデモについて、顧客に何が分かれば成功なのかを一文で決めることから始めましょう。

---

よくある質問

Q. 営業デモは何分くらいが適切ですか

A. 商材や参加者によって変わるため、一律の最適な長さはありません。

30分なら冒頭で課題と参加者を確認し、主要業務の実演、質疑、次の行動の確認に配分する構成が一例です。

時間の長さより、顧客が今日確かめたいことに実演の時間を割けているかを基準に構成を調整しましょう。

Q. デモで質問に答えられないときはどうしますか

A. 推測で機能を約束しないことが大切です。

できないことと未確認のことを区別して伝え、回答の期限と担当を示します。

その質問で顧客が何を判断したいのかも確認しておくと、後日の回答が検討に役立つ内容になります。

Q. デモと試用・PoCはどう違いますか

A. デモは営業担当者が整えた環境で動きを見せる場です。

試用やPoCは顧客の環境やデータで確かめるため、分かることが異なります。

デモで業務の流れを理解してもらい、実データでの確認が必要な項目を試用やPoCに回すと役割を整理できます。

Q. デモの成果はどう測ればよいですか

A. 実施件数だけでは検討に役立ったかは分かりません。

次の行動を合意できた件数など、対象期間と分母の定義を固定して比較します。

あわせて顧客の反応や未解決の質問を記録しておくと、次回以降のデモ内容を改善しやすくなります。