AIの提案文を直した理由を、次の担当者へ。営業チームで残す5つの項目

月曜日に直した一文が、翌週また現れる

月曜日。営業担当者がAIに、次回提案のたたき台を頼みました。下書きには「既存システムと必ず連携できます」とあります。担当者はそこで手を止めました。相手のシステムも接続方法も、まだ確かめていません。

担当者は「連携可否は、対象システムと接続方法を確認してご案内します」と書き換え、責任者と確認して提案書を仕上げました。

翌週、別の担当者が似た案件の下書きを作ると、また「必ず連携できます」という表現が現れます。前回の完成版は共有フォルダにあります。それでも、なぜ断定を避けたのか、どの条件で確認するのかは見つかりません。

この場面は説明のために作った架空の例です。実在の顧客、製品の連携可否、導入成果を示すものではありません。

完成版だけでは、次の判断を引き継げない

最終版の文章は、その案件で採用した答えです。次の担当者が必要とするのは、同じ答えを使ってよいかを決める材料です。対象システムが違えば、確認先も連携方式も変わります。

だから、修正した文章を共有するだけでは足りません。「何を確認できていなかったから直したのか」と「どこまで使えるのか」を一緒に渡します。

一つの修正を、5項目で渡す

専用システムを増やす前に、既存の提案確認メモへ次の5項目を一件だけ追加してみます。記入例も架空です。

1. 元の下書き：「既存システムと必ず連携できます」
2. 採用した表現：「連携可否は、対象システムと接続方法を確認してご案内します」
3. 直した理由：対象システムと接続方式が未確認で、連携を約束できない。
4. 使える条件と例外：連携可否が未確認の案件では断定を避ける。技術確認済みの案件には、この文を無条件に使わない。
5. 確認者と次の確認：営業責任者が共有範囲を確認し、次の類似案件で採用・追加修正・不使用のどれだったかを振り返る。

次の担当者は文面をコピーする前に、確認の順序を見られます。顧客名や固有の取引条件を他案件へ持ち込まずに済むよう、実案件では利用目的と閲覧権限を確認します。

翌週に確かめるのは、保存件数ではない

カードを保存しただけでは、まだ引き継ぎができたとは言えません。別の担当者が読んだか、必要な確認を進められたか、使わなかった理由は何かを見ます。

• 採用した：どの条件が一致したか
• 修正した：新たに必要だった確認は何か
• 使わなかった：対象外と分かった条件は何か

ここまで記録すると、その知識を続けて使うか、限定するか、見直すかを人が判断できます。利用件数だけで営業成果への影響を断定することはできません。

まずは、今週の修正から1件

今週直したAIの下書きから、理由が次回にも役立ちそうな一文を選びます。5項目を残し、共有してよい範囲を人が確認する。翌週、別の担当者が使えたかを見て、残す項目を調整します。

株式会社BREW UPは、人とAIの仕事で得た判断や修正を次の仕事へ戻す考え方を「Learning Workforce」と呼んでいます。この記事の5項目は、その考え方を営業の一業務に落とした実践案です。時間短縮や受注増を確認した結果ではありません。

知識をチームへ戻す仕組み全体は、Team BrainとKnowledge Loopの設計で説明しています。