営業デモで多くの機能を紹介したのに、商談後の反応が曖昧なままになっていませんか。
操作画面を見せることに集中すると、顧客が解決したい業務や、導入を判断するための疑問が置き去りになることがあります。
営業デモとは、製品やサービスの動きを実演し、顧客が自社の業務で利用する姿を具体的に確かめる機会です。
SaaSやITサービスの場合は、機能の数よりも、顧客の業務がどのように進み、誰が何を確認できるかを伝えることが重要になります。
目標は、すべての画面を見せ終えることではありません。
顧客が、役立つ点、合わない点、追加確認が必要な点を整理し、次の検討に進める状態をつくることです。
本記事では、事前確認、シナリオ作成、当日の実演、終了後のフォローに分けて営業デモの進め方を解説します。
デモの準備では、製品の説明順を考える前に、顧客が今回知りたいことを整理します。
次の五つを確認すると、見せる画面、説明の深さ、時間配分を選びやすくなります。
最初に、誰がどの作業で困っているのかを確認します。
情報共有を改善したいという要望だけでは、どの機能を見せるべきか決まりません。
担当者から承認者への申請が遅れる、案件情報を複数の表へ転記しているなど、実際の行動まで具体化します。
可能なら、現在の作業が始まるきっかけ、途中の確認、完了条件を聞きます。
業務の流れが分かれば、デモでも同じ順序で操作を見せられます。
現場担当者は日々の操作負担、管理者は進捗の見え方、情報システム部門は管理機能など、関心が異なる場合があります。
参加者の人数だけでなく、役割と判断事項を把握しましょう。
全員に同じ説明を長く続けるより、共通の業務を見せた後に、役割ごとの確認へ分ける方法があります。
参加者が分からない場合は、当日の冒頭で確認する前提を置き、特定の役割にしか分からない専門的な操作から始めないようにします。
情報収集中の顧客と、導入候補を比較している顧客では、必要なデモが異なります。
前者には基本的な業務の流れ、後者には必須要件への対応や制約の確認が役立ちます。
すでに試用している顧客には、一般的な紹介より、実際に困った操作を再現して説明する方が適していることがあります。
検討段階を確認せずに同じ台本を使い続けると、説明の詳しさが合わなくなります。
デモを見た後、何が分かれば検討が進むのかを事前に聞きます。
担当者ごとに閲覧範囲を変えられるか、既存データをどのように取り込むか、承認の差し戻しに対応できるかなど、確認したい条件を整理します。
デモ画面だけでは判断できない項目もあるため、実演、資料での説明、後日の回答に分けましょう。
要望を受けた時点で、すべて対応できる前提にしないことが大切です。
面談時間、対面かオンラインか、画面共有の可否、音声の必要性を確認します。
短時間のデモに詳細な初期設定まで詰め込むと、顧客が最も見たい業務に時間を使えなくなります。
オンラインでは、表示する文字の大きさやウィンドウの切り替え方も確認します。
顧客の画面サイズが分からない場合は、細かな一覧表を一度に見せるより、確認する場所を拡大して説明しましょう。
事前に確認した課題を、顧客が実際に行う作業の順番へ落とし込みます。
一つの業務がどう完了するかを軸にすると、複数の機能を見せる場合も説明がつながります。
機能名を順番に読む構成ではなく、顧客の課題に対応する業務シナリオを一つ選びます。
たとえば、問い合わせを受けた担当者が内容を登録し、責任者が担当を割り当て、対応状況を確認する流れです。
各場面で、何のための操作か、操作すると何が変わるか、顧客の業務に合うかを順番に伝えます。
操作の前に目的を説明すれば、顧客は画面上の変化を追いやすくなります。
操作の後には、この進め方で御社の担当者間の確認を置き換えられそうか、と具体的に聞きます。
入力項目が多い製品では、最初からすべての入力を実演すると、完成までの意味が伝わりにくくなります。
その場合は、処理が終わった状態を先に見せ、どのような情報が確認できるかを説明してから、主要な操作へ戻ります。
ただし、準備済みのデータであることは明確にし、操作しただけで自動的にすべて完成したように見せないようにします。
事前設定が必要な箇所は、設定済みの状態であることと、導入時に誰が設定するのかを補足します。
基本操作に続いて、差し戻し、入力ミス、担当者変更など、顧客にとって重要な例外を一つ見せます。
すべての例外を扱う必要はありませんが、正常に進む画面だけでは運用を判断しにくい場合があります。
たとえば承認機能なら、承認完了だけでなく、内容の修正が必要になったときの戻し方も確認します。
例外を含めることで、導入後に誰が対応するかという会話につなげられます。
以下は時間配分の一例であり、すべての商材に共通する最適な時間ではありません。
| 時間の目安 | 内容 | 確認すること |
|---|---|---|
| 最初の5分 | 課題と参加者の確認 | 今日確かめたいことが一致しているか |
| 次の12分 | 主要業務の実演 | 業務の流れと結果が理解できるか |
| 次の5分 | 例外や必須条件の確認 | 運用上の懸念が残っていないか |
| 次の5分 | 質疑と未回答の整理 | 追加調査が必要な項目は何か |
| 最後の3分 | 次の行動の合意 | 誰が何をいつまでに確認するか |
質問が多い場合は、後半の説明を短縮し、顧客の疑問に時間を振り向けます。
その際も最後の確認時間は残し、話し切れなかった内容と回答予定をまとめましょう。
製品全体の説明が必要な場合は、今回の目的に合う部分を先に確認し、別の機会を設ける方が整理しやすくなります。
当日は、用意したシナリオを進めながら、参加者の理解と確認したい点を確かめます。
操作の速さよりも、顧客が画面の変化を自社の業務に結び付けられる説明を意識しましょう。
最初に、今日は申請から承認までを確認し、データ移行の詳細は別途整理する、と実演の範囲を伝えます。
顧客が別の項目を優先したい場合は、この時点で調整できます。
一方的に予定を宣言するのではなく、この範囲で本日の確認目的に合っているかを確かめます。
説明する範囲が決まると、途中で別の機能へ話が広がった際にも、扱い方を相談しやすくなります。
ここを押しますという説明だけでは、オンライン参加者が操作箇所を見失うことがあります。
画面右側の承認状況をご覧ください、と場所を伝え、変化が表示されてから意味を説明します。
マウスを素早く動かしたり、複数の画面を続けて切り替えたりせず、顧客が確認できる間を取ります。
操作に慣れた営業担当者ほど、初めて見る人には情報量が多いことを意識しましょう。
いかがでしょうかという質問だけでは、便利そうですという感想で終わることがあります。
現在の業務では、この確認をどなたが担当されていますか、と具体的な問いに置き換えます。
この通知を受けるタイミングで問題ないか、入力項目に不足がないかなど、顧客が判断できる対象を絞ると、懸念を確認しやすくなります。
反応が少ないときも、関心がないと決めつけず、画面が見えているか、前提が伝わっているかから確認します。
質問に即答できないときは、推測で機能を約束しないようにします。
標準機能で対応できること、設定や追加検討が必要なこと、現時点では対応できないことを分けて説明します。
確認が必要な場合は、質問の内容、想定する利用条件、回答予定を記録します。
あとで確認しますという返事だけで終わらず、顧客が何を判断するための質問なのかも聞くことが大切です。
実演が予定どおりに進まない場合は、顧客が確認できた範囲を明確にすることが大切です。
代替資料で説明できることと、後日動作を確かめることを分け、次の確認につなげます。
同じ操作を何度も繰り返すより、まず状況を伝えます。
実演環境で処理が完了しないため、準備済みの画面で結果を説明し、動作は別途確認するというように、説明と未検証部分を分けます。
動画や画像を使う場合は、それが事前に用意した資料であり、現在のライブ操作ではないことを明示します。
不具合の原因が分からない段階で、通信環境や顧客側の設定に原因があると断定しないようにしましょう。
入力内容や表示結果が想定と違った場合も、都合のよい部分だけを説明せず、確認が必要な箇所を伝えます。
準備した別のシナリオへ切り替えるなら、確認できなかった項目を記録します。
商談後の報告では、何を実演できて、何を再確認する必要があるかを分けます。
デモの完了と、顧客の必須要件を満たす確認の完了は同じではありません。
残り時間を伝え、顧客が優先したい質問を確認します。
営業側の台本を最後まで進めるために質問を切り上げると、重要な疑問が残ることがあります。
未実演の項目を一覧にし、追加面談が必要か、資料で足りるかを合意します。
次回の予定は、追加で何を判断するための時間なのかが分かる形で設定しましょう。
デモ当日の説明に集中できるよう、シナリオと利用環境の準備を合わせて確認します。
次の項目を実演前に見直し、不足があれば担当者と対応を決めておきましょう。
このリストは準備漏れを減らすためのもので、顧客ごとのシナリオ作成を置き換えるものではありません。
デモ用データは、対象業務を想像できる程度に具体的であれば十分です。
実際の顧客名や個人情報を使わず、架空の名称であることを分かるようにしておきましょう。
デモで得た顧客の反応や質問は、次の検討に使える形にまとめます。
確認した内容と双方の宿題を残しておくと、参加していない関係者にも商談の状況を伝えやすくなります。
デモ後のメールでは、資料を添付するだけでなく、確認できた業務、残った懸念、追加回答の予定を簡潔にまとめます。
顧客の発言は、正式に合意したことと、検討中の意見を区別して記載します。
営業側の理解が正しいか確認できる形にすると、次回の打ち合わせで認識を合わせやすくなります。
本日はお時間をいただき、ありがとうございました。
今回は、申請の登録から承認状況の確認までをご覧いただきました。
現行の担当者間の確認に置き換えられる可能性がある一方、差し戻し時の通知先について追加確認が必要と認識しております。
通知設定については、いただいた運用条件を基に確認し、合意した期日までに回答いたします。
御社内では、承認担当の方に操作の流れをご確認いただく予定と理解しております。
認識に相違がございましたら、お知らせください。
この例文は架空の商談を想定したもので、実際に確認していない内容をそのまま使わないようにします。
顧客側の行動についても、合意がないものを予定として書かないことが大切です。
振り返りでは、何回デモを実施したかに加え、顧客の疑問がどこまで解消したかを確認します。
数字の定義と対象条件を揃え、説明内容を改善する材料として使いましょう。
デモ実施件数だけでは、顧客の検討に役立ったかは分かりません。
顧客が確認したい項目をどこまで扱えたか、未回答が何件残ったか、次の判断行動が合意されたかを記録します。
ここでの次の行動は、単なる日程調整ではなく、利用部門の評価や費用の確認など、導入判断に関わる内容として定義します。
次の行動を合意した割合を測るなら、対象期間に実施したデモのうち、合意の有無を確認できた件数を分母にするなど、定義を固定します。
未確認の案件は別に残し、合意なしと同じ扱いにしない方法が考えられます。
新規の情報収集段階と、最終比較段階のデモを混ぜると、比率の違いを内容の良し悪しだけでは説明できません。
商材、検討段階、対象顧客をそろえたうえで、質問内容や商談記録と合わせて振り返りましょう。
営業担当者が整えた環境で見せるデモと、顧客の環境で確かめる試用やPoCでは、分かることが異なります。
デモで業務の流れを理解できても、顧客の実データでの処理、社内の運用、既存環境との接続が確認できたとは限りません。
デモだけでは答えられない項目が重要なら、次の検証方法を相談します。
その際、試してみましょうと進める前に、何を確認し、誰が結果を判断するかを決めることが大切です。
営業デモの質を高めるには、操作の流暢さだけでなく、顧客の業務を理解してシナリオを絞る準備が必要です。
対象業務を一つ選び、操作後の結果、例外の扱い、未確認事項を整理しましょう。
面談する相手との接点づくりが課題の場合は、決裁者マッチングなどの手段を検討できます。
接点を得た後に役立つのは、相手が判断したい内容に合わせた説明です。
営業活動の入口を見直したい場合は、onlystoryのサービス案内を確認し、自社が会いたい相手と相談したい課題を整理してみてください。
まずは次のデモについて、顧客に何が分かれば成功なのかを一文で決めることから始めましょう。
オンリーストーリー代表 平野からのメッセージ
