商談メモからお礼メール・次回ToDo・提案案を作る方法

商談が終わると、仕事は三つ残ります。顧客へ送るお礼メール、社内で対応するToDo、次回提案の案です。同じ商談メモを材料にしても、読む人と情報の確度が違うため、一つの要約を三か所へ貼るだけではうまくいきません。

お礼メールには確認済みの約束だけを書きます。社内ToDoには担当者と期限が必要です。次回提案には、まだ確定していない案も含められます。この三つを分けてAIへ依頼すると、後処理を速めながら、顧客と交わしていない約束を書いてしまうミスを防げます。

商談の翌日まで残りがちなのは、お礼メール・社内ToDo・次回提案のどれですか？

作業を翌日に持ち越しているなら、下書きごとに同じ記録を読み直していないか確かめてみてください。録音を一度文字にし、そこから用途別の下書きを作れば、同じ内容を何度も転記せずに済みます。

商談メモは、一度だけ整理する

録音の文字起こしや手書きメモをそのままAIへ渡すと、提案、希望、決定が混ざります。先に次のラベルを付けます。

区分	意味	例
顧客が明言した事実	顧客が現状として説明したこと	週報を金曜に営業企画が集計している
合意	双方が次の行動として決めたこと	来週水曜までにデモ候補日を送る
未決	まだ決まっていないこと	対象部署、予算、導入時期
営業仮説	営業側の解釈や提案の芽	CRM入力と週報に二重入力がある可能性

「興味がありそう」「好感触だった」は営業仮説です。顧客が「検討する」と言っただけなら、導入決定ではありません。AIには、ラベルのない内容を合意へ移さないよう指示します。

メモに担当者や期限がなければ「未設定」と残します。自然な文章にするために、AIが期限を「来週」、担当者を「営業担当」などと補うと、後で約束の食い違いになります。

読む相手と用途に合わせて書き分ける

顧客向けメールと社内メモは、同じ記録から作れても、伝える内容と詳しさが違います。

顧客には確認済みの約束、社内には担当者と期限、次回提案にはまだ確定していない仮説が必要です。同じ記録から作っても、三つの文章は分けます。

顧客向けメールへ、社内の受注確度や競合評価を書きません。社内ToDoに、丁寧な挨拶は不要です。提案案では仮説を書けますが、合意した事実のようには書きません。

一度のプロンプトで三つ出しても構いませんが、指示と出力欄を分けます。完成後も三つを別々に確認します。

1. お礼メールを作る

お礼メールの役割は、商談内容を長く要約することではありません。時間をもらったお礼、重要な認識、双方が決めた次の行動を短く確認することです。

依頼文は次のようにします。

以下の商談メモから、顧客向けのお礼メールを作成してください。書いてよいのは「顧客が明言した事実」と「合意」のラベルがある内容だけです。件名、宛名、二〜三行のお礼、確認した課題、当社と顧客の次の行動、結びの順にしてください。未決事項を決定のように書かず、担当者または期限がない項目はメールへ追加せず「要確認」として別に出してください。営業仮説はメールに含めないでください。

件名は、相手が後から検索しやすいよう具体的にします。「本日のお打ち合わせのお礼」だけでなく、「営業報告業務のお打ち合わせ御礼」のようにします。

AIが丁寧な文面を作っても、宛先と約束を確認する責任は送信者にあります。顧客名の表記、敬称、曜日と日付の一致も見ます。

2. 社内ToDoを作る

社内ToDoは、行動、担当者、期限、完了条件の四点を一組にします。

商談メモの「合意」と「未決」から社内ToDo候補を作ってください。各項目を、行動、担当者、期限、完了条件、根拠となる発言に分けます。担当者や期限がない場合は未設定とし、推測しないでください。顧客側の行動は当社のToDoに混ぜず、確認待ちとして分けてください。

「資料を作る」では完了が分かりません。行動・担当者・期限・完了条件まで書きます。

ToDoをタスク管理へ自動登録できても、最初は自動登録せず、確認用の一覧に置くところで止めます。担当者を間違えると通知が飛び、誤った期限がチームの予定に入るからです。

3. 次回提案の仮説を作る

提案案は確定事項ではありません。商談で聞いた課題から、何を見せれば判断が進むかを考える作業です。

「顧客が明言した事実」と「営業仮説」を使い、次回デモの案を最大三つ作ってください。各案に、解く課題、見せる入力、完成する出力、顧客へ確認する質問、成立しない条件を付けてください。顧客が導入を決めたとは書かず、製品機能や時間短縮率を創作しないでください。

たとえば次の三案です。

• 商談メモから週報の下書きを作る
• 決定事項と担当者付きToDoを抽出する
• 過去四週の商談から共通質問をまとめる

すべてを一度にデモせず、顧客がいちばん手間に感じている作業を一つ選びます。実データを使えない場合は、項目だけを似せた架空データを作ります。

一つの架空メモを三つに分ける

元メモを次のように整理したとします。

このメモから、お礼メールには合意と確認済みの課題だけ、社内ToDoには候補日送付とデモ準備、提案案には週報下書きと承認フローを出します。「二重入力が最大の課題」とは断定せず、次回の質問にします。

人が確認する順番

確認は文章の美しさより、誤ると困る項目から行います。

1. 宛先、会社名、氏名
2. 顧客との約束と担当
3. 日付、曜日、期限
4. 金額、数量、製品名
5. 決定と未決の区別
6. 顧客発言と営業仮説の区別
7. 添付ファイルと共有権限
8. 文体と誤字

元メモに戻れない内容は削除するか、確認待ちへ移します。文章が少し短くなっても、存在しない約束を入れない方が重要です。

自動送信しない方がよい理由

商談後は早く連絡したいものです。ただ、最初から自動送信すると、次のような誤りが顧客に届くおそれがあります。

• 顧客の氏名や会社名を誤る
• 未決事項を合意済みとして送る
• 自社が約束していない納期を書く
• 社内メモの受注確度を顧客へ出す
• 添付や共有権限を間違える
• 顧客が希望していない提案を前提にする

最初の目標は、確認用の下書きが10分以内にそろうことです。3種類の下書きが安定してから、CRMの下書き欄への転記など、間違えても社内で直せる操作を一つずつ追加します。外部への送信は、最後まで人が確認しても十分に時間を減らせます。

専用ツールが必要な条件

月に数件の商談で、手書きメモから十分な速さで三つの成果物を作れるなら、通常の生成AIとテンプレートで足ります。

専用の議事録サービスを比較するのは、商談数が多い、録音と文字起こしを毎回行う、同じ要約テンプレートをチームで使いたい、過去商談を横断確認したい場合です。Nottaでは文字起こしからテンプレートを使ってAI要約を生成でき、Notta Brainでは複数の議事録を横断的に扱えると案内されています。

ただし、顧客情報を社外クラウドへ保存できない会社では、機能が合っても導入できません。契約前に保存先、利用データ、アクセス権、削除方法を管理者と確認します。

一週間の試し方

営業担当者一人を対象に、一週間に行う三件の商談で試します。各回、次を記録します。

• 元メモを4区分にする時間
• 三つの下書きが出るまでの時間
• 人が修正した件数
• 約束、期限、固有名詞の誤り
• 送信までの合計時間
• 商談翌日に残った作業
• 顧客や社内からの訂正

効果は生成時間ではなく、確認を含めた合計時間で見ます。AIの下書きは速くても、修正が多くて原音を何度も聞くなら、メモの区分や出力テンプレートを直します。

Nottaで商談後の3つの下書きを作る

Nottaで文字起こしを作り、この記事の手順で3種類の下書きに分けます。商談当日にお礼メール、社内ToDo、次回提案の下書きまでそろえば、翌日は内容の確認と提案準備から始められます。

顧客へ確かめる質問や、次回デモで見せる内容を考える時間に回せるか、一週間の試行で確かめましょう。

Nottaが3種類の下書きを必ず正しく作るわけではありません。まず会話を文字にして、元の発言を確かめられるようにします。そのうえで、人が顧客向け、社内向け、提案向けに仕上げれば、約束を確認しながら作業時間を減らせます。

商談後に確認すること

• 顧客が明言した事実、合意、未決、営業仮説を分けた
• お礼メールに仮説を入れていない
• 顧客側と自社側のToDoを分けた
• 担当者と期限を推測していない
• 次回提案を最大三案に絞った
• 宛先、氏名、会社名を確認した
• 日付、曜日、金額、製品名を確認した
• メール送信前に人が全文を読んだ
• CRMへ登録する内容と社内メモを分けた
• 顧客情報を承認された環境で扱った

商談数が多く、記録から複数の成果物を繰り返し作る場合だけ、専用サービスを検討します。通常のメモと生成AIでもこの手順は試せます。最初の目標は完全自動化ではなく、商談当日に内容を確認した3種類の下書きをそろえることです。