動きの止まった商談を洗い出して、次の一手の案までそろえる

処理の起点を決める

週1回の定期実行にします。営業会議の前日か当日の朝に合わせます。

日次にすると通知が日常の雑音になり、月次では手遅れになります。商談期間が3〜6か月の業種では、週1回がちょうど良い間隔です。 商談期間が年単位の業種（大型設備、公共案件）では隔週や月次に落とします。

入力データを集める

4番目が要ります。 消耗品の追加受注で2週間動かないのは異常ですが、基幹システムの更改で2週間動かないのは普通です。商材ごとに基準を変えないと、全部の案件が「停滞」になります。

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

商談と活動履歴： 営業支援システムのAPIから取得します。Salesforce を使う場合、REST API のクエリのリソースにSOQLを渡します。GET /services/data/vXX.X/query/?q=SOQL の形で、クエリ文字列の空白は + に置き換えます。同期のリクエストで一度に返るのは最大2,000件で、超えると done が false になり、続きを取得するための情報が返ります。 クエリが不正な場合は MALFORMED_QUERY が返ります。

商談が数千件ある場合は、この続きの取得を必ず実装してください。最初の2,000件だけを処理して「全件見た」としてしまう誤りが起きやすい箇所です。

やり取りの本文： 停滞スコアの高い案件だけ取得します。全件のメール本文を読み込む必要はありません。費用と処理時間の大半はここで決まります。

AIへ渡す前に整形する

1. 対象の絞り込み … 進行中で、金額が一定以上、完了予定日が未来の案件に限ります。既に失注・受注したものは外します
2. 特徴の計算 … 案件ごとに次を計算します

1. 商材ごとの正規化 … 平均商談期間で割り、商材が違っても比べられるようにします
2. 担当者の在籍確認 … 退職・異動した担当者の案件を別枠にします。これは停滞ではなく引き継ぎ漏れです
3. 長期案件の除外 … もともと年単位の案件は、別の基準で見ます

AIに処理させる

計算と文章化で役割を分けます。

プログラムにさせること： 特徴の計算と停滞スコアの算出。重みは、過去の実績（同じ状態から受注に至ったか、失注したか）から決めます。複雑な手法は要りません。 どの特徴がどれだけ効いたかを説明できる形にします。

生成AIにさせること：

受注の可否や確度をAIに書かせないでください。 「この案件は受注可能性が低い」と書かれた一覧が回ると、営業が動く前に諦めます。

指示内容を固定する

あなたは営業を補佐する担当者です。
止まりかけている商談の記録と、直近のやり取りを渡します。
止まっている理由の候補と、次の一手の案を出してください。

【厳守事項】
- 記録とやり取りに書かれていないことを書かないでください。
  顧客の社内事情を推測して断定しないでください。
- 理由の候補には、根拠になったやり取りの箇所を引用してください。
  引用できない候補は出さないでください。
- 受注できるか、確度が何％かを書かないでください。
- 「この案件は見込みが薄い」といった評価を書かないでください。
- 次の一手は、担当者がすぐ実行できる具体的な行動にしてください。
  「フォローを強化する」ではなく「◯◯について確認の連絡をする」と書いてください。
- 値引きや特別条件の提示を提案しないでください。
- 記録が少なく判断材料がない場合は、その旨を書いてください。
  無理に理由を作らないでください。

【商談の基本情報】
{opportunity}

【停滞の特徴（計算済み）】
{stall_features}

【直近のやり取り】
{recent_activities}

【同じ状態から動いた過去の案件の例】
{similar_cases}

「値引きを提案しない」の1行を入れておいてください。 止まっている案件に対して、生成AIは値引きや特典の提示を提案しがちです。それが一覧に並ぶと、価格で動かす発想が営業に広がります。

出力形式を固定する

{
  "opportunity_id": "",
  "owner": "",
  "amount": 0,
  "stage": "",
  "stall_score": 0,
  "score_reasons": [
    { "feature": "最終活動からの日数", "value": 0, "contribution": 0 }
  ],
  "possible_causes": [
    { "cause": "", "quote": "" }
  ],
  "next_actions": [],
  "unknowns": [],
  "insufficient_record": false
}

score_reasons に、点数の内訳を入れます。「なぜこの案件が上位なのか」が一覧で分かることが、使われ続けるかどうかを決めます。 点数だけを出すと、営業は納得しません。

insufficient_record が立つ案件が多いなら、それは仕組みの問題ではなく、活動履歴が入力されていないという運用の問題です。

システムへ連携する

営業支援システムの確度やフェーズを自動で書き換えないでください。 数値は営業が入力するもので、仕組みが書き換えると、システムの数字が誰の判断か分からなくなります。

人が確認する

全件、営業本人が判断します。

一覧に並ぶのは「見落としているかもしれない案件」であって、「手を打つべき案件」ではありません。顧客の予算時期の都合で意図的に置いている案件もあります。 その判断は営業にしかできません。

判断を速くするための設計が要ります。

• 点数の内訳を一覧に表示する
• 「保留」を選ぶときに理由を1つ選ばせる（予算時期／先方都合／優先度が低い／こちらの都合）
• 保留にした案件は、指定した日まで一覧に出さない
• 次の一手の案は3つまで。多いと読まれない

「保留」を選びやすくすることが大切です。 保留が選べないと、一覧を無視する習慣がつきます。

例外に対処する

記録を残す

• 週ごとの停滞スコアと内訳
• 生成AIが出した理由の候補と次の一手
• 営業の判断（動く／保留／失注）と理由
• その後の結果（受注・失注・継続）

3番目と4番目を突き合わせると、基準の精度が測れます。 「上位に並んだ案件のうち、実際に失注した割合」を見れば、点数の付け方が妥当かが分かります。この検証を四半期に一度行い、重みを見直してください。