AIで営業提案書を作る手順｜顧客課題から構成・文章・修正まで

商談メモ、顧客から受け取った資料、自社のサービス資料はそろっている。それでも白紙のスライドを開くと、何から書けばよいか分からない。そこでAIへ「提案書を作って」と頼むと、見た目は整っていても、自社紹介が長く、顧客が何を判断すればよいか見えない資料になりがちです。

提案書で最初に決めるのは、スライドの枚数でもデザインでもありません。誰に、いつまでに、何を決めてもらう資料かを一文にします。そのうえで、商談で確認した事実、営業側の仮説、まだ聞けていないことを分けます。

AIは、材料を並べ直し、構成と文章の下書きを作る相手として使えます。ただし、顧客の事情、価格、導入効果、契約条件を勝手に補わせません。提案書の約束に関わる部分は、元資料と社内承認へ戻って人が確かめます。

その提案書で、相手に何を決めてもらいますか？

「サービスを理解してもらう」では広すぎます。「営業部長に、9月から一部署で試すかを決めてもらう」のように、読み手、決定、時期まで書くと、残す材料を選びやすくなります。

相手に決めてほしいことを一文にする

提案書の冒頭に会社紹介を置く前に、次の三つを一文へまとめます。

• 読み手は誰か
• 読み手に何を決めてほしいか
• いつまでに、どの範囲を決めるか

たとえば、架空の例として「営業部長に、9月から東日本チームの商談メモ整理を試すか決めてもらう」と置きます。ここまで決まれば、会社の沿革や全機能を載せる必要はありません。試行の判断に必要な課題、対象業務、運用、費用、条件だけを残せます。

読み手が現場担当者なら、操作と日々の負担が重要です。部長なら、費用、対象範囲、責任者、評価方法が必要でしょう。同じ商材でも、読み手が変われば構成も変わります。

一枚目には「何を提案するか」だけでなく、「この資料で何を決められるか」を書きます。読み手が最後まで読んでから目的を探す提案書にしないためです。

事実・仮説・不明点を分ける

次に、商談メモと受領資料を三列へ分けます。

スマホでは表を横にスクロールできます。

その数字は、顧客が示した事実ですか、それとも営業側の仮説ですか？

二つが混ざると、提案の説得力が上がるどころか、後で「その前提は聞いていない」と戻されます。特に工数、売上効果、利用人数、導入時期は、AIがもっともらしく補いやすい部分です。分からない値は「要確認」と書き、確認する相手と期限を置きます。

商談後のメモをお礼メール、社内ToDo、次回提案へ分けるところから始めたい場合は、商談メモから三つの下書きを作る手順を先に確認できます。

顧客課題から提案理由までを並べる

材料が分かれたら、次の順番で6枚以内の骨子を作ります。枚数は絶対ではありません。最初の社内レビューで話を広げすぎないための目安です。

課題の直後に商材名を置くだけでは、「なぜこの方法なのか」が抜けます。現行手順のどこを変えるか、既存の道具で足りない理由、導入しない条件も短く示します。

相手が選べる余地も残します。現在の運用で問題が小さい、承認済み環境がない、担当者を置けない場合は、提案を急がない方がよいでしょう。合わない条件を先に示すと、この先の比較も、必要な人に届きやすくなります。

AIには構成と不足確認を頼む

AIへ「提案書を作って」とだけ渡すのではなく、依頼の枠を決めます。顧客名や個人名を入れる必要がなければ、役割名へ置き換えます。勤務先が承認したAI環境を使えない場合は、架空データで構成だけを相談します。

読み手: 営業部長
この資料で決めてほしいこと: 9月から一部署で試行するか
確認済み事実: （商談メモと正式資料から抜粋）
営業側の仮説: （仮説と分かる形で記載）
不明点: （確認が必要な項目）
使ってよい根拠: （資料名、日付、該当箇所）
禁止: 資料にない数値、顧客発言、導入効果、契約条件を作らない
出力: 6枚以内の構成案。各枚に目的、使う根拠、不足資料を付ける

最初の出力では、文章を長く作らせません。各スライドの目的、必要な根拠、不足している資料を確認します。順番が通ったあとに、見出しと本文を作ります。

AIが「業務効率が大幅に向上します」「売上拡大が期待できます」と書いたら、そのまま残しません。どの業務の何が変わるのか、その表現を顧客資料で裏づけられるのか、試行で何を測るのかを見直します。根拠がなければ削除します。

文章は結論・根拠・条件の順に短くする

スライド本文は、一文に一つのことだけを書きます。見出しだけを読んでも、提案の筋が追える状態を目指します。

たとえば、「業務効率化を実現するご提案」のような見出しでは、何が変わるか分かりません。「商談メモの整理を一回にし、三つの下書きへ分ける」とすれば、対象業務と変化が見えます。

本文は次の順で短くします。

1. このページで伝える結論
2. 結論を支える確認済みの事実
3. 提案する方法
4. 成立する条件、まだ確認すること

機能を並べたくなったら、一つずつ顧客課題へ対応させます。対応しない機能は載せません。読み手が判断に使わない情報を削る方が、文字を小さくして詰め込むより効果的です。

元資料へ戻れる形で確認する

AIが作った提案書を完成品として扱いません。次の項目を、元資料と照らします。

• 顧客名、部署名、担当者名
• 数値、単位、対象期間
• 顧客の発言と、その文脈
• 自社サービスの機能、対応範囲
• 価格、見積条件、有効期限
• 導入日、体制、役割分担
• 引用、画像、ロゴの利用可否

重要な主張の横には、社内の確認用として資料名、版、日付、ページを残します。顧客へその管理情報をすべて見せる必要はありませんが、質問されたときに戻れるようにします。

AIによる調査を使う場合も、引用があるだけで合格ではありません。リンクを開き、対象企業、更新日、適用範囲、本文が主張を支えているかを確認します。競合情報や一般的な市場情報を、顧客固有の事実として書かないようにします。

個人情報・機密情報は入力前に止める

提案書には、担当者名、連絡先、商談内容、未公開の予算、他社との契約、技術構成などが含まれる場合があります。AIへ入力する前に、資料の機密区分、利用する環境、共有範囲を確認します。

OpenAIはBusiness、Enterprise、APIのビジネスデータをデフォルトでモデル学習に使わないと案内しています。ただし、それだけで自社の全情報を入力してよいとは限りません。勤務先の契約、管理者設定、保存期間、接続先、社内規程を優先します。

承認済みの環境がない場合は、次のように範囲を狭めます。

• 顧客名を「A社」、担当者名を役割名へ置き換える
• 実数を架空の桁・比率へ変え、手順だけ確認する
• 契約書、個人情報、未公開資料を入力しない
• 構成案だけを作り、正式資料への差し替えはローカルで行う

匿名化しても、組み合わせから企業や個人を推測できる場合があります。迷う資料は入力せず、情報管理の担当者へ確認します。

社内レビューでは約束の範囲を先に見る

文章の誤字より先に、提案として約束している範囲を見ます。営業、サービス提供責任者、価格承認者、法務など、案件に必要な人へ確認を分けます。

スマホでは表を横にスクロールできます。

「AIが書いた文章だから」という理由で責任の所在は変わりません。送付・契約・公開は、必要な承認が済んでから担当者が行います。AIに自動送信まで任せる前に、まず下書きと確認の手順を安定させます。

次の案件で再現できるか確かめる

一件の提案書が完成しても、それだけで手順が身についたとは限りません。次の案件で同じ順番を使い、どこで止まったかを記録します。

次の案件でも同じ手順を、自分でやり直せそうですか？

決めてほしいことを一文にできるか。事実と仮説を分けられるか。元資料へ戻れるか。承認者へ渡せるか。この四つを自分で再現できるなら、まず独学で続けられます。

同じ箇所で止まる場合は、止まる理由に合わせて学び方を選びます。複数の職種やAIツールを広く試し、自分で学ぶ順番を決めたいなら、DMMが候補になります。成果物を見ながら、進め方や修正点を個別に相談したいならbyTechも比較候補です。どちらにも、この記事と同じ提案書の課題が必ずあるとは限らないため、説明会では自分の成果物を例に質問します。

最後に残すのは、きれいなスライドだけではありません。どの事実を使い、どの仮説を削り、誰の承認で約束を確定したかという記録です。そこまで残れば、次の提案書でもAIを同じ手順で使えます。