案件・ヨミ管理

案件のフェーズ遷移を可視化し停滞地点を特定する

同じ案件の複数商談の文字起こしを時系列で貼るだけで、案件が営業フェーズをどこまで進んだか、いまどこで止まっているかをAIで可視化するプロンプトです。停滞の起点と詰まっている理由の仮説を発言ベースで整理し、パイプラインレビューで確認すべき点を洗い出します。

  • 分析・レポート

必要データと準備

必要なのは1種類です。

  • 同一案件の複数商談の文字起こし(時系列): 一つの案件について、初回接触・デモ・提案・フォローなど、複数回の商談の録音・自動文字起こしから全文をコピーし、開催日が分かる形で古い順に貼ります。フェーズの遷移を見るプロンプトなので、1件だけでは「遷移」が描けません。2回以上、できれば直近までの数回をまとめて貼るほど、どこで動きが止まったかがはっきりします。話者ラベル(自社/相手)が付いていると、誰の発言を根拠にフェーズを判定したかが追いやすくなります。文字起こしの取り方は商談文字起こしの共通ガイドも参照してください。
  • 任意で足せるもの: 自社の営業フェーズ定義があれば一緒に貼ると、その定義に沿って判定します。なければAIが一般的なフェーズ(初回接触→課題ヒアリング→提案・デモ→見積・稟議→クロージング→受注)を仮に用います。停滞期間を測りたい場合は今日の日付も渡します。

このプロンプトの前提: 判定は文字起こしにある会話だけを根拠にします。SFA/CRMの記録は使わないため、会話に現れない進捗(書面の提出、稟議の申請、社内での根回しなど)は反映されません。会話上は止まって見えても裏で動いていることはあるため、出力は「会話から見た現在地」として扱い、実際の進捗は担当への確認で補ってください。

プロンプト本文

プロンプト(コピーして使う)
あなたは営業案件のパイプラインを分析するアナリストです。
同一案件について時系列に並んだ複数商談の文字起こしを読み、案件が営業フェーズをどう進んできたかを可視化し、いまどこで止まっているか(停滞地点)とその要因仮説を特定してください。判断は文字起こしにある発言だけを根拠にし、書かれていないことは推測と明記するか「不明」としてください。

## 商談の文字起こし(複数・時系列)
{同一案件の複数回の商談文字起こしを、開催日が分かる形で古い順に貼り付け。2回以上}

## 想定する営業フェーズ(任意)
{自社のフェーズ定義があれば貼り付け。なければ空欄。空欄の場合は「初回接触→課題ヒアリング→提案・デモ→見積・稟議→クロージング→受注」を仮に用いる}

## 今日の日付(任意)
{停滞期間を測るための基準日。なければ空欄}

## 出力フォーマット
1. フェーズ遷移タイムライン
   各商談を時系列(開催日つき)に並べ、その回で到達したフェーズと、前回比の動き(前進/横ばい/後退)を判定する。判定根拠となる発言を各回1つ短く引用する
2. 現在地と停滞地点
   いまどのフェーズにいるか、いつの商談から前進が止まっているか(停滞の起点)を示す。今日の日付があれば停滞期間を示す。動いていないと判断した根拠を引用する
3. 停滞の要因仮説
   会話から読み取れる「詰まっている理由」を挙げる。相手が明言した障害は[事実]、会話から読み取った推測は[推測]と区別する
4. 前進に必要な未解決事項
   次のフェーズに進むために埋まっていない条件・確認事項を、確認相手とセットで挙げる
5. マネージャーへの示唆(3つ以内、具体的な行動で)
   パイプラインレビューで担当に確認・指示すべき点

## 注意事項
- フェーズ判定・停滞判定は、文字起こしにある発言のみを根拠にする。書かれていない進捗を「進んだ」と判断しない。根拠がない箇所は「不明」と明記する
- 事実(相手・自社が実際に言ったこと)と、そこからの推測を必ず分ける。推測には[推測]と付す
- 曖昧な同意(「検討します」「前向きに」「社内で調整します」等)を、フェーズ前進のシグナルとして扱わない。動いた根拠が乏しい場合は「横ばい」とする
- 停滞期間は、文字起こしに開催日があり今日の日付が与えられた場合のみ算出する。日付がなければ順序のみを扱い、期間は「不明」とする
- 商談と商談の間に何が起きたか(実施されなかった社内のやり取り等)は文字起こしからは分からない。空白期間の中身を創作しない
- 引用は文字起こしの原文を短く抜き出す。金額・日付・固有名詞は原文どおりにする
- この分析はSFA/CRMの記録を使っていない。会話に現れない進捗(書面提出・稟議申請など)は反映されない前提であることを明記する

このプロンプトを動かしてみる

プリセットされた依頼のまま「送信」を押すと、AIの応答がその場でストリーミング表示されます(架空データに対する収録済みの応答。生成AIは呼び出しません)。

営業AIエージェントStockworkサンプル実行(収録済み)
同じ案件の複数商談を時系列で読んで、停滞地点を可視化して。
AIに渡した入力データ(架空サンプル)
[2026-04-08 初回ヒアリング] 佐藤(管理部長): 月末の労務が田中さん一人に属人化していて、締めのたびに残業が出ている。ここを何とかしたい。 田中(人事労務): 勤怠をExcelで集計して、給与ソフトに手で転記しています。月末はこれで毎回3日くらい取られます。 [2026-04-22 デモ] 田中: 打刻と集計が自動になるのは良いですね。うちは給与のペイロールデスクを使っているんですが、そこの連携はできますか。 河野(営業): 標準で対応しています。利用中のバージョンを確認させてください。次回、御見積と合わせてお持ちします。 [2026-05-13 提案・見積提示] 河野: スタンダードプラン、200名で月額96,000円、初期20万円のお見積です。 佐藤: 金額感は想定内です。ただ投資枠が四半期ごとなので、次の枠に乗せる形で社内を通す必要があります。田中さん、連携のところ問題ないか見ておいてもらえる? 田中: 連携は確認したいです。過去に別ツールで二重入力が残った経験があるので、そこは慎重に見たい。 [2026-06-04 フォロー面談] 河野: その後、社内のご検討はいかがでしょうか。 佐藤: すみません、四半期の枠の話もあって、まだ具体的に動けていなくて。連携の件も田中さんと詰め切れていないんです。 田中: バージョンの確認、こちらもまだできていなくて。すみません。 佐藤: いったん社内で調整して、こちらからご連絡します。 入力(今日の日付): 2026-07-15
「送信」を押すと、ここに実行結果を表示します。

カスタマイズのヒント

  • 自社のフェーズ定義に合わせる: 「想定する営業フェーズ」欄に自社のSFAのフェーズ名(例: リード→SQL→提案→内示→受注)を貼ると、その言葉で遷移を判定します。ヨミ会の用語とそろい、SFA上のフェーズとのズレも見えます。
  • フェーズ移行の条件(Exit Criteria)を渡す: 「このフェーズを抜けるには決裁者との合意が必要」といった自社の移行条件を書いて渡すと、条件を満たさずにフェーズだけ進んでいる「見かけの前進」を検出しやすくなります。
  • 複数案件を一括で回す: 案件ごとに文字起こしをまとめて、それぞれ同じプロンプトを回すと、パイプライン全体で「どの案件がどのフェーズで、いつから止まっているか」の一覧が作れます。レビュー前の下ごしらえに向きます。

よくある質問

商談の文字起こしが1件しかない場合でも使えますか?

このプロンプトは「フェーズの遷移」を見るものなので、1件だけでは遷移が描けず、現在地の把握にとどまります。案件の現在地を1件から評価したい場合は、単一案件を対象にしたP080(受注確度採点)やP081(フェーズ判定)のほうが向いています。遷移と停滞を見たいときは、同じ案件の複数回の商談を時系列で貼ってください。

SFAのフェーズと、このAIの判定がズレたらどちらが正しいですか?

どちらかが正しいというより、両方を突き合わせる材料として使ってください。このプロンプトは会話だけを根拠にするため、会話に現れない進捗(稟議申請など)は反映されません。逆にSFAは担当の手入力なので実態より進んで見えることがあります。ズレた案件こそ、担当に「会話上は横ばいだがSFAは提案済み、実際どちらか」と確認する価値があります。

「停滞している」と出たら、その案件は失注に近いということですか?

必ずしもそうではありません。停滞には、決裁タイミング待ちのような健全な停滞と、相手の関心が離れたことによる停滞があります。このプロンプトは「いつから、なぜ止まって見えるか」までを会話ベースで示しますが、失注確度そのものは判定しません。停滞の理由(要因仮説)まで見て、待ちなのか離脱なのかを人が判断してください。

商談の一次情報をAIが利活用、
営業担当者の行動が変わる

プロンプトの入力データが自動で貯まる仕組みを、資料でご確認ください

メニュー

資料請求