営業フォローをAIで自動化するには？商談後の対応・CRM更新・追客をつなぐ設計

議事録の後に残っている仕事を数える

商談後には、見積もり依頼、資料送付、社内確認、次回日程の調整などが発生します。議事録の自動生成だけでは、担当者が内容を読み直してタスクへ転記する作業が残りがちです。導入対象を考えるときは、記録から実行までの間に何回転記があるかを調べます。

また、CRMに登録があっても、顧客への返信が済んでいるとは限りません。行動予定と完了結果を分け、実行した証跡があるかを確認する設計にします。営業担当の入力を増やさず、日々の対応から必要な記録を残すことを狙います。

本記事は当社が提案する設計例です。特定のCRMに標準搭載された機能や、導入先で確認された成果を示すものではありません。実装範囲は連携先の機能と社内ルールにより変わります。

「記録→対応案→承認→実行→確認」を一つにつなぐ

たとえば「来週までに検討します」という顧客の発言を、営業側の「来週電話する」という確定タスクに変換しないようにします。抽出した事実、AIが推測した事項、担当者が決めた事項を区別し、元の発言へ戻れるようにします。

商談音声を扱う場合は、録音の運用ルール、利用目的、閲覧できる人、保存先を先に確認します。外部AIに渡す範囲は必要な情報へ絞り、秘密情報を含む案件は別の運用が必要か検討します。

承認するのは「送ってよい」ではなく、この内容

送信の承認画面では、宛先、CC、添付、本文、対象案件を同時に確認できるようにします。本文だけ承認しても、添付資料や宛先が変われば別の行為です。承認した版を固定し、変更された場合は再確認へ戻す案を推奨します。

最初の検証では自動送信を使わず、下書きの提示と担当者の送信を組み合わせます。修正理由を集め、価格や納期などの判断が多いのか、敬語や文量の修正が多いのかを分けると、次に改善すべき箇所が分かります。

OWASPは、AIへ不要な権限や過度な自律性を与えるリスクを整理しています。営業フォローでも、メールを読めることと送信できること、案件を見られることと変更できることを別々に設計する参考になります。

追客を続ける条件より、止める条件を明確にする

返信があった、商談が終了した、担当者が変わった、顧客が連絡を望んでいない。これらを検知できず定期的な追客を続けると、関係を損ねるおそれがあります。次の連絡前に最新状態を確認し、停止条件を優先して判定します。

同じ顧客へ複数部署が連絡する場合は、部署ごとの台帳だけでは重複を防げません。会社・担当者・案件をどう区別するか、情報の共有が許される範囲はどこかを決めます。顧客名の文字列が似ているだけで自動統合するのは避け、候補として提示します。

送信結果が不明なときに再送すると、同じ内容を重複送信する可能性があります。送信IDや状態を記録し、未送信と送信結果不明を分けて扱います。

検証シナリオ：返信が来た直後に追客予定が残ったら

架空の検証例として、翌日に追客を予定していた顧客から、その朝に返信が届く状況を用意します。予定された送信を実行する直前に最新の返信を確認し、既に返答がある場合は下書きを取り下げられるかを試します。

返信が別の担当者へ届いた場合も考えます。メール全体を無制限に閲覧させるのではなく、共有が許可された案件の対応履歴を確認できる仕組みが必要です。確認できない範囲が残るなら、送信前に人が判断する条件として明示します。

また、値引き条件を担当者が修正した後、古い承認で送信されないかを確認します。承認の対象となった内容と、実際に送られた内容が一致することをテストし、変更時には確認待ちへ戻します。

こうした例外を最初に用意すると、自然なメール文を作れるかだけでは分からない運用の課題が見えます。営業担当者には「文面がよいか」と「自分の代わりに進めてよいか」を分けて評価してもらいます。

測るのは送信数ではなく、対応の完了と確認負担

評価では、商談から初回対応までの時間、期限超過した対応件数、担当者の修正時間、誤った宛先や案件の候補が出た件数を記録します。メール送信数だけを増やす設計は、顧客にとっての価値と一致しません。売上や受注率の変化は他の施策の影響もあるため、短期間でAIだけの成果とは判断しないようにします。

当社の開発プロダクトであるAI音声週報は、営業活動の情報を扱う仕組みの一例として紹介しています。ここで述べる追客フロー全体が標準機能として含まれるという意味ではなく、別途業務範囲と連携を設計します。

まず一つの商材・一つのチームで、どこまで自動で準備し、誰が何を確認するかを揃えましょう。業務全体の自動化設計と組み合わせると、議事録作成の先まで検討できます。