失注・保留のまま止まった案件から、今月声をかけ直す先を選んで再提案の切り口まで作る

処理の起点を決める

月初の定期実行を起点にします。営業が「今月やろう」と思ったときに動かす形にすると、忙しい月は動かなくなります。

Apps Scriptで組む場合、1回の実行が6分で打ち切られます。 900件を1回で処理すると必ず超えるため、件数で区切って複数回に分けます。トリガーの合計実行時間にも上限があり、Google Workspaceのアカウントで1日6時間です。件数が多い場合は、この枠に収まるかを先に計算してください。

入力データを集める

データの取得方法を決める

商談メモ： CRMのAPIで案件IDごとに取得します。1件あたりの文字数が大きいため、全件を毎回渡す設計にしないでください。 機械的な絞り込みを先に通し、残った案件のメモだけを渡します。

接点データ： マーケティングツールから、失注日以降の接点だけを取ります。「失注後に資料請求している」は強い材料です。

除外リスト： これは人が管理します。与信上の問題がある先や、明確に断られた先へ連絡してしまうと、掘り起こしどころではなくなります。

AIへ渡す前に整形する

1. 機械的な絞り込み … 経過月数（3か月未満は外す）、案件の規模、除外リストとの突合。AIに渡す件数をここで10分の1にします
2. 重複の統合 … 同じ顧客に複数の失注案件があることがあります。顧客単位にまとめ、案件は履歴として持ちます
3. メモの整形 … 定型の署名、引用されたメール本文、日程調整のやり取りを落とします。残すのは中身のある記述だけです
4. 個人名の扱い … 先方担当者の氏名は、役職と部署に置き換えてから渡します。 誰に当たるかは人が決めます
5. 連絡済みの除外 … 直近6か月に掘り起こしの連絡をした先を外します

AIに処理させる

2段階に分けます。

1段目（抽出）： 商談メモから、失注理由・そのときの障害・決裁の構図・比較された他社を抜き出します。ここは全件に対して行い、バッチ処理でまとめて投げます。 即時性が要らない処理なので、Claude APIのバッチ（多くが1時間以内に完了、料金は通常の半額）が向きます。

2段目（生成）： 順位の上位に残った案件についてだけ、切り口と文面を作ります。

AIに点数や順位を出させません。 同じ案件でも実行のたびに揺れるためです。AIには観点ごとの判定と根拠を返させ、加点はプログラムで行います。

加点の例です。

この加点の重みは、最初は勘で置いて構いません。 3か月運用して、実際に商談化した案件の特徴を見て直します。

指示内容を固定する

あなたは、過去の商談記録を読んで営業を支援する担当者です。
失注・保留になった案件について、なぜ決まらなかったのかを整理してください。

【厳守事項】
- 記録に書かれていないことを補わないでください。
  読み取れない項目は unreadable にしてください。
- 点数、順位、確率を出さないでください。
  観点ごとの判定と、その根拠の引用だけを返してください。
- 顧客の現在の状況を推測しないでください。
  記録にある時点の事実だけを扱ってください。
- 先方担当者の人物評を書かないでください。
- 判定した項目には、記録本文からの引用を必ず添えてください。

【案件の基本情報】
{deal_summary}

【商談メモ（時系列）】
{activity_notes}

【提案した内容と見積】
{proposal_summary}

【失注後の接点】
{post_loss_touchpoints}

「顧客の現在の状況を推測しない」の1行が重要です。 AIは記録にない現況を、もっともらしく書きます。それを読んだ営業が「もう予算がついているらしい」と思い込むと、初手で失敗します。

出力形式を固定する

{
  "deal_id": "",
  "customer_id": "",
  "lost_reason_detail": {
    "category": "budget | timing | price | function | incumbent | internal | other | unreadable",
    "quote": ""
  },
  "blocker": { "description": "", "quote": "" },
  "decision_structure": { "decider_role": "", "opponent_role": "", "quote": "" },
  "competitor": "",
  "resolvable": "likely | unlikely | unknown",
  "resolvable_reason": "",
  "reapproach_angles": [],
  "unreadable": []
}

quote がない判定は、加点の対象から外します。根拠のない材料を順位に反映させると、営業がリストを信用しなくなります。

システムへ連携する

書き戻しを省かないでください。 掘り起こしの連絡をCRMに残さないと、翌月また同じ先が上位に出てきます。

人が確認する

全件、営業が確認してから連絡します。自動送信はしません。

理由は、失注先への連絡が関係の修復を伴う行為だからです。断られた経緯がある相手に、事情を知らない文面を送ると、関係が完全に切れます。この構成で減らしているのは「思い出す時間」であって、「当たり方の判断」ではありません。

確認を速くするための設計が重要です。

• 1行に 顧客名・失注理由・障害・引用・接点・切り口 を並べる
• 引用からCRMの該当メモへリンクする
• 加点の内訳を見せる（なぜ上位なのかが分かる）
• 「読み取れない」が多い案件は別の列にまとめる

例外に対処する

記録を残す

• 抽出した失注理由・障害と、その引用
• 加点の内訳と、算出された順位
• 生成した切り口・文面と、営業が実際に使った文面
• 連絡した日、相手、反応
• 再商談になったかどうか、なった場合はその後の結果

最後の項目が、この構成の唯一の答え合わせです。3か月ためると、加点の重みを実績で直せます。 「経過月数より、失注後の資料請求のほうが効く」といったことが分かります。

個人名を含む商談メモそのものは、処理後に保持しないでください。 残すのは抽出結果と引用箇所です。