AIサービスのデモで見せること｜通常動作と失敗時の対応

AIサービスのデモでは、きれいな出力だけでなく、何を入力し、どこを確認し、うまく処理できないときにどう対応するかを見せます。顧客が判断したいのは、自分の仕事で使えるかということです。見本の条件と本運用の条件を分け、デモの成功を全案件の成果保証として説明しないようにします。

デモの前に、確認したいことを決める

操作の流れを見せる、完成物を評価してもらう、入力資料が合うか確かめる、承認の方法を説明する、といった目的があります。一回の商談で全部を実演しようとすると、顧客が何を見ればよいか分からなくなる場合があります。今回の判断と次の確認を分けます。

顧客が利用者なのか、決裁者なのか、管理担当なのかも聞きます。利用者には実務の入力と確認、決裁者には範囲と料金、管理担当には情報の流れが必要になる場合があります。同じ処理でも説明の重点を変えます。ただし人によって違う提供条件を伝えないようにします。

立場ごとの情報は利用者と決裁者が違う提案へ渡せます。デモではその資料を補う実例として、対象の一件を選びます。

仮定例：問い合わせの要約を見せる

仮定として、担当者向けに問い合わせを分類、要約するサービスを実演するとします。まず、公開可能な架空の問い合わせ文を用意し、デモ用であることを明記します。通常の質問だけでなく、情報が不足する文、対象外の相談、複数の依頼が混ざる文も用意します。

通常例では、何を入力し、どの項目が出るかを説明します。次に担当者が原文と照合して使う流れを見せます。AIの要約だけを完成として表示せず、元の条件が落ちていないかを確認する場面も含めます。

情報不足の例では、無理に結論を出さず、確認が必要な項目へ回す動作を見せます。顧客への返信を自動で行わない商品なら、その境界を説明します。実際のサービスがまだその処理をできない場合は、将来の計画を動作済みとして見せないようにします。

見せる内容を三段階にする

最初の例だけを何度も調整して完璧に見せると、条件を変えたときの動作が分かりません。調整した見本であることを説明し、別の例で確認する範囲を決めます。あらかじめ作った動画や出力を使うなら、リアルタイムの実演とは区別します。

現在できること、限定条件でできること、未実装の計画を分けて示します。顧客が画面を見て機能が完成していると受け取らないよう、状態を資料と口頭の両方で説明します。試作の価値は、完成の印象を作ることではなく、適合を確かめることです。

顧客の資料をその場で入力しない

顧客が実資料で試したいと言っても、先に情報の扱いを確認します。顧客の担当者が見せた資料でも、外部のAIへ送信できる権限があるとは限りません。資料の種類、利用環境、保存、規約を確認してから行います。

その場で確認できない場合は、公開可能な仮の資料で動作を説明し、実資料の試行は別の日程にします。基本となる条件はAIへの入力情報と契約へ渡せます。商談を盛り上げるために、重要な確認を省かないことが必要です。

顧客の情報を録画や紹介資料へ含める場合も、別の用途として許可を確認します。実演の了承と公開の了承を混ぜないようにします。デモで作った出力を他社へ見せる条件は資料と原稿の権利を参照できます。

失敗したときの説明も用意する

接続できない、出力が想定と違う、処理が長いなどの問題が起きる場合があります。あらかじめ確認した結果を説明用として使う、手順図で処理を示す、実演を止めて原因を調べる、といった代替案を用意します。失敗を隠して結果を差し替えるのではなく、説明用資料へ切り替えたことを伝えます。

問題が入力、設定、サービス側の状態、未実装の工程のどこにあるか、分かる範囲で整理します。その場で原因を特定できなければ、断定しません。顧客へは、確認していつ回答するかを伝えます。

例外に人が対応する設計なら、誰が通知を受け、どの情報を見て判断するかを説明します。画面上でエラーが表示されるだけでは、顧客の業務を継続できるとは限りません。受託後の対応は失敗時の連絡と修正で扱います。

速度を見せるときは、全作業を区別する

実演中の生成が数秒で終わっても、元資料の準備や最終確認が事前に行われている場合があります。実演の時間と、顧客が通常業務で使う時間を分けて説明します。画面の処理だけを、従来の全工程の時間と比較しないようにします。

複数の処理を事前に準備した場合は、その準備を示します。顧客が入力情報を用意できるか、同じ形式で繰り返せるかを確認します。条件を揃えない速度比較で、大幅な業務改善を保証しないことが重要です。

全工程を評価する考え方は生成と確認を含む採算を参考にできます。デモでは、見せた処理の前と後に何が残るかを顧客へ返します。

感想を、発注条件へ具体化する

「便利そう」という感想があったら、どの仕事で使えそうか、何を変える必要があるかを聞きます。入力資料の違い、確認者の時間、社内の管理条件が合わない場合もあります。好評価だけを導入確定のように記録しないようにします。

実際に使いたいという話になったら、対象を限定して有料で試す条件を示せます。完成物、料金、顧客の協力、評価、終了を決める方法は有料試行の提案へ渡せます。デモの延長として無制限の個別作業を引き受けないようにします。

顧客が使わない理由を述べた場合も記録します。操作が難しいのか、仕事が発生しないのか、既存手段で十分なのか、決裁が必要なのか。次に行う確認を、その理由へ合わせて選びます。

営業資料との一致を確認する

デモで示した範囲と、提案書、料金表、契約の条件を揃えます。実演では人が確認しているのに、資料では全自動と表示していないかを点検します。顧客が準備する情報や、含まれない対応も同じ説明にします。

比較の見本を使う場合は、自主制作、仮定、実案件を区別します。架空の顧客名や実績の数字を用意する必要はありません。納品前の確認の基本は原稿の点検と差戻しを参考にできますが、デモでは通常動作と失敗時の両方を評価します。

終了後に残す一枚の記録

参加者が自分で操作する時間を設けるなら、試してよい入力と対象を最初に示します。自由な入力へ対応できる商品の場合も、デモで確認していない専門判断や外部動作まで実行させないようにします。顧客が別の用途を提案したら、新しい対象として後から評価する方法があります。

実演の記録を残す場合は、参加者の発言や顧客資料が含まれているかを確認します。次の営業へ使う目的は、今回の面談記録とは別です。公開用に編集するなら、許可された範囲だけを使い、仮定の例を実際の導入成果のように紹介しないでください。

見せた環境と版、入力の条件、確認できた動作、見せていない範囲、顧客の反応、次の確認をまとめます。実演の結果を提案書へ反映する場合は、今回の限定条件を残します。条件が変われば再評価が必要な箇所も記載します。

デモに向くのは、仕事の範囲と人の関与を説明できる商品です。成功した出力だけを見せて何でもできる印象を作るより、顧客が自社の入力と運用へ合うかを判断できる実演にしてください。失敗時の対応まで見せることが、導入後の期待を揃える助けになります。