商談直前に企業サイトや過去メールを慌てて読み、相手に合わない一般的な質問から始めていないでしょうか。
検索と要約だけをAIへ任せると、古い公開情報、別会社の情報、社内の推測が混ざり、もっともらしい誤解を持って商談へ入る危険があります。
この記事では、情報源の分離、事実要約、仮説、質問、商談後の更新までを整理します。
株式会社ラクボは、AI導入を単体ツールの設定で終わらせず、業務設計、確認、運用、改善までを一つの仕組みとして支援しています。実務で止まらず、担当者が判断できる状態を重視しています。
公開情報と社内履歴を分けて集める
公開情報は公式サイト、採用情報、ニュース、公開資料に限定し、取得日とURLを残します。社内情報は問い合わせ内容、過去商談、購入履歴、対応履歴を権限内で参照します。二つを別欄に置き、公開事実と自社の記録を混ぜません。
似た社名、古い役職、終了したサービスがないかを人が確認します。SNSの個人投稿や出所不明のまとめを、本人の意向や経営課題として断定しないようにします。
AIには事実・推測・不足情報を分けさせる
要約の出力は、確認できた事実、そこから考えられる仮説、情報不足の三つに分けます。各事実へ出典を付け、AIが新しい数字や固有名詞を補わないようにします。仮説には確信度ではなく、商談で確認する質問を添えます。
たとえば採用ページの更新を『採用に困っている』と断定せず、『採用施策を強化している可能性。現在の優先職種を確認』と書けば、会話の入口になります。
一ページの商談準備メモへ絞る
メモは企業概要、接点、公開された変化、課題仮説三つ、確認質問五つ、提案してはいけない条件に絞ります。長い調査報告書より、営業が五分で読めることを優先します。価格や契約条件は最新の承認済み資料だけを参照します。
問い合わせ情報を営業へ渡す場合は問い合わせ対応の自動振り分け設計と分けて運用すると、調査内容が受付時の事実を上書きしません。
商談後に仮説の当否を記録する
商談後は、当たった仮説、外れた仮説、新しく分かった事実、次回までの確認事項を記録します。AIが作ったメモの正しさを評価し、外れた理由を情報の古さ、同名企業、推測過多、営業の確認不足へ分けます。
毎週数件だけ見直し、不要な情報源と有効な質問を更新します。調査時間だけでなく、初回商談で確認できた重要項目、次回約束、修正件数を測ると、準備の質を改善できます。
試験は一つの営業チームで十商談程度から始めます。準備メモの作成時間、営業が削除した項目、商談で確認できた仮説、誤った事実を記録します。調査件数を増やすより、営業が読まなかった情報を削ることが重要です。顧客へ見せる資料と内部仮説を同じ文書にしないよう保管場所を分けます。個人の経歴やSNS情報を使う場合は、業務上必要な公開情報に限定し、推測による人物評価へ広げません。
初回実装では、まず「公開情報と社内履歴を分けて集める」と「AIには事実・推測・不足情報を分けさせる」を一つの対象で確認し、次に「一ページの商談準備メモへ絞る」までを担当者と手作業で通します。最後に「商談後に仮説の当否を記録する」の指標を決めてから自動化範囲を広げます。一度に全件へ適用せず、修正理由、判断者、元データ、停止条件を記録してください。小さな試験で人が直した箇所を残すことが、AIの出力を増やすより再現性の高い運用につながります。
この運用を自社のデータ、担当者、承認ルールに合わせて構築したい場合は、ラクボの期間限定AI部署・AI顧問をご覧ください。現在の業務から小さく試す範囲を整理したい方は、AI 商談準備 顧客リサーチについて相談できます。