商談後の提案書づくりでは、顧客が実際に話した課題と、営業側が考えた解決仮説が混ざりやすくなります。AIは商談メモを整理して構成案を作れますが、自然な文章で不足情報を補うことがあるため、根拠を残す設計が必要です。
提案書に使う入力資料
- 商談メモまたは文字起こし
- 顧客から受領した資料
- 自社の正式な製品・サービス資料
- 導入条件と対応範囲
- 承認済みの価格・事例・数値
古い資料や社内用の未承認情報を混ぜません。顧客情報をAIで処理できるか、利用環境と社内規程も確認します。
先に事実を4つに分ける
| 区分 | 内容 |
|---|---|
| 確認済み | 顧客が明示した現状・課題・条件 |
| 仮説 | 営業側が考える原因や効果 |
| 提案 | 自社が提示する解決方法 |
| 未確認 | 次回確認が必要な情報 |
この分類をせずに文章化すると、「顧客は大幅なコスト削減を求めている」など、実際には話していない主張が入りやすくなります。
構成を作る指示例
> 商談記録と正式な製品資料だけを使い、提案書の下書きを作成してください。「顧客が確認した課題」「解決の方向性」「提案内容」「期待効果の仮説」「導入条件」「未確認事項」に分け、各事実に出典を付けてください。価格、効果、実績は入力にない場合、作成しないでください。
数値と固有名詞を確認する
会社名、担当者名、日付、人数、利用量、価格、削減率、導入事例は原資料と照合します。AIが計算した効果は、前提式と根拠データを確認できない限り確定値にしません。「最大」「必ず」「業界初」のような表現も正式な根拠が必要です。
顧客が読みやすい流れ
- 今回確認した目的
- 現在の業務と困りごと
- 解決の考え方
- 具体的な提案
- 導入手順と役割
- 条件・対象外
- 次回確認する事項
機能一覧から始めず、顧客の業務と判断材料から組み立てます。提案の全項目を同じ強さで押さず、必須と選択肢を分けます。
送付前チェック
- 顧客の言葉と提案側の仮説が分かれている
- 未確認事項が断定表現になっていない
- 数値と条件を正式資料で確認した
- 社外秘の情報が含まれていない
- 次の判断と担当が明確になっている
まとめ
AIは商談メモから提案書の骨格を短時間で作れます。確認済み事実、仮説、提案、未確認事項を分け、数値と条件を人が照合することで、顧客の課題に沿った誤解の少ない提案につながります。
実践確認：この記事を現場で使う手順
商談メモから提案書の下書きをAIで作る方法を実務へ入れるときは、AIに完成品を一度で作らせるより、事実整理・下書き・確認を分けます。確認の中心は発言者・決定事項・担当・期限です。入力資料の責任者と最終承認者を同じ人にせず、根拠をたどれる状態を残します。
入力を4つに分ける
- 確定事実：日時、担当、金額、決定済みの条件
- 引用・根拠：会議記録、規程、見積書、一次資料のURL
- 仮説：まだ確認できていない原因や効果
- 未確認事項：誰にいつ確認するかが必要な項目
この区分を付けてからAIへ渡すと、推測が事実のように混ざる問題を減らせます。個人情報や機密情報は、利用環境と社内規程を確認し、不要な部分を伏せます。
下書き用の指示例
> 次の資料から「商談メモから提案書の下書きをAIで作る方法」の下書きを作ってください。確定事実と仮説を混ぜず、数値には出典を付け、情報が不足する箇所は「要確認」と表示してください。読み手が判断・実行するために必要な項目を先に並べ、表現を整えるのは最後にしてください。
人が確認する順番
- 人名、会社名、日付、金額、単位を元資料と照合する
- 「決定」「予定」「提案」「推測」の区別を確認する
- 担当者と期限が本文のどこにあるか確認する
- 読み手が次に行う操作を一つに絞る
- AIへ入力してはいけない情報が残っていないか確認する
1週間の試行で測る
完成時間だけでなく、修正回数、事実誤り、確認のために戻った資料数、読み手からの質問数を記録します。発言者・決定事項・担当・期限の抜けが続く場合は、プロンプトを長くするのではなく、入力テンプレートへ必須欄を追加します。効果が確認できるまでは、AI出力を自動送信・自動承認しない運用が安全です。
