AIで解決する課題を顧客に聞く方法｜欲しい機能より困る仕事

AIで解決する課題を聞く面談では、欲しい機能より、最近困った仕事を具体的に聞きます。「AIで何をしたいですか」だけでは、思いついた希望が並び、実際の有料需要を判断しにくくなります。発生した場面、現在の対処、失敗したときの影響、外部へ頼む条件を順に確かめ、相手の発言と自分の推測を分けて記録します。

面談の前に、一つの仮説を置く

仮説は「営業担当者は提案資料の準備に困っている」のように、対象者と仕事を組み合わせます。「AIで業務を効率化したい企業」では広すぎて、質問が抽象的になりやすくなります。ただし仮説は正解として押し付けるものではありません。相手の経験を聞き、違っていれば変えるための出発点です。

面談の目的も決めます。困りごとの有無を確かめたいのか、現在の対応費を知りたいのか、試作を評価してもらいたいのかで、必要な問いが変わります。一回で全てを聞こうとすると、相手が何のために答えるのか分からなくなることがあります。予定の時間に収まる範囲で、今回の確認を絞ります。

候補の探し方は最初の顧客との接点づくりで扱います。ここでは、接点ができた後に質問を組み立て、回答を事業の判断へ使う手順を説明します。媒体の読者調査ではなく、有料の業務支援を買う可能性がある人への聞き取りです。

最初の問いは、直近の出来事へ戻す

「その作業で困りますか」と聞くと、相手が気を使って肯定する場合があります。「最後にその作業をしたのはいつですか」「どんな依頼を受けましたか」と聞けば、実際の場面を確認できます。仕事内容を想像して話しているのか、発生した出来事を話しているのかを区別してください。

続いて、誰が作業し、何を受け取り、何を完成させたかを聞きます。困った箇所が情報収集なのか、文章制作なのか、承認なのかを分けます。依頼者が「資料作成が大変」と言っていても、時間の多くを商品情報の確認に使っているなら、文章生成だけでは負担を減らせない可能性があります。

時間、頻度、影響を混ぜない

一回の作業が大変でも、年に一度なら需要は限定される可能性があります。一回は短くても毎日繰り返す仕事なら、合計の負担が大きいかもしれません。発生頻度と一回の作業量を分けて聞きます。曖昧な記憶しかない場合は、その数字を確定した原価として使わず、未確認として残します。

所要時間には、手を動かす時間、確認する時間、返答を待つ時間があります。待ち時間が長くても、AIで文章を速く作ることが解決になるとは限りません。遅れる原因を特定し、顧客が変えられる条件と、取引先や社内決裁に依存する条件を分けます。

影響も金銭だけではありません。顧客へ説明が遅れる、誤りが出る、特定の担当者へ負担が集中する、引継ぎできないといった問題があります。ただし重大そうに聞こえたから支払い意欲も高いとは断定しません。会社がどの課題を優先しているか、既に対策に使っている予算や時間があるかを確認します。

仮定例：欲しい機能と本当の負担が違う

仮定として、担当者が「AIで見積文を作りたい」と話したとします。実際の一件を聞くと、見積条件を制作部門へ確認する往復が多く、文章を書く時間は短かったと分かりました。この場合、文の生成を中心に提案する前に、受付情報や確認項目の整理が必要かを聞きます。

ここで「では情報整理が問題ですね」と結論を押し付けず、「この確認が揃えば文章は作れますか」「ほかに止まる箇所はありますか」と確認します。面談者が期待する問題を見つけようとすると、相手の発言を都合よく解釈しやすくなります。自分の仮説に合わない発言も同じように記録してください。

業務の流れを成果物にする仕事はAIによる業務整理サービスへ渡せます。面談で見えた課題を、そのまま自分が全部受託できるとは限りません。技術、確認能力、対応時間を踏まえ、提供できる範囲を後で判断します。

提案を見せるのは、経験を聞いた後にする

最初に完成案を見せると、相手がその案の感想だけを話し、現状の仕事が分からないことがあります。先に発生場面と現在の対応を聞き、その後で試作や提供内容を示します。提案を見せる前と後の回答を区別すれば、こちらの説明に影響された反応かを考えられます。

試作へ「便利そう」と言われたら、どの場面で使い、何を置き換えられるかを聞きます。実際に使う前提が揃っているか、社内で確認する人がいるか、現在の形式と合うかを確かめます。感想が良くても、業務の一部へ入れられないなら、そのまま有料提案に進めるとは限りません。

価格の質問も、希望額を聞くだけでは十分ではありません。現在その仕事にどんな費用を使っているか、発注は誰が判断するか、予算の時期、契約に必要な条件を聞きます。相手が想像で答えた価格を、そのまま市場相場として記載しないでください。

録音や資料の共有は、確認してから行う

面談を記録する場合は、目的、記録方法、閲覧する人、保存期間を説明します。録音してAIで要約するなら、その処理に使うサービスと入力条件も確認してください。録音の了承だけで、外部サービスへの送信や別の用途への利用まで許可されたとは判断しないようにします。

相手が実案件の資料を見せる場合も、必要な箇所だけ確認します。顧客名や契約内容が不要なら、持ち帰る情報を限定できます。基本となる管理はAIへの入力と情報取扱いへ、再利用の判断は預かった資料と権利へ渡せます。

面談内容を公開事例にするなら別途確認します。匿名でも仕事内容や時期から相手が推測できる場合があります。許可がない情報は、商品紹介や営業資料へ載せないようにします。公開用の例が必要なら、実際の面談を実績風に加工するより、仮定例として新たに作ります。

回答を比較するための記録

記録には、相手の役割、対象業務、直近の発生例、現在の対処、困る箇所、発注条件、未確認事項を並べます。同じ質問への回答でも、利用者と決裁者では見ている範囲が異なります。担当者の負担と会社の支払い判断を、同じ欄でまとめないようにします。

AIで面談記録を整理する場合は、元の発言に戻って点検します。推測された原因や、話していない数値が追加されていないかを確認してください。相手の発言を短くまとめるほど、前提や例外が落ちる可能性があります。重要な条件は発言箇所と対応させて残します。

複数の回答で同じ問題が出ても、同じ商品で解決できるかは別です。会社ごとの資料、権限、確認方法が違えば、個別対応が多くなる場合があります。顧客別の事情を無理に一つの需要へまとめず、共通化できる工程とできない工程を分けます。

面談の最後に合意すること

終了時には、理解した内容を短く返し、誤解がないか確認します。その場で作業を受託する約束をしていないなら、次に提案するかどうかの連絡方法を決めます。追加資料を受け取る場合は用途を示し、いつまでに何を返すかを伝えます。協力してくれたからといって、購入を当然の次段階にしません。

有料の確認へ進む場合は対象を限定した試行を提案できます。発注内容を揃える考え方は依頼前の情報整理も参考になります。面談が成功したと言えるのは、好意的な言葉を得たときだけではありません。解決案が合わない条件を把握し、無理な受注を避けられた場合も、事業判断に役立つ結果です。