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

必要データと準備
必要なのは1種類です。
- 同一案件の複数商談の文字起こし(時系列): 一つの案件について、初回接触・デモ・提案・フォローなど、複数回の商談の録音・自動文字起こしから全文をコピーし、開催日が分かる形で古い順に貼ります。フェーズの遷移を見るプロンプトなので、1件だけでは「遷移」が描けません。2回以上、できれば直近までの数回をまとめて貼るほど、どこで動きが止まったかがはっきりします。話者ラベル(自社/相手)が付いていると、誰の発言を根拠にフェーズを判定したかが追いやすくなります。文字起こしの取り方は商談文字起こしの共通ガイドも参照してください。
- 任意で足せるもの: 自社の営業フェーズ定義があれば一緒に貼ると、その定義に沿って判定します。なければAIが一般的なフェーズ(初回接触→課題ヒアリング→提案・デモ→見積・稟議→クロージング→受注)を仮に用います。停滞期間を測りたい場合は今日の日付も渡します。
このプロンプトの前提: 判定は文字起こしにある会話だけを根拠にします。SFA/CRMの記録は使わないため、会話に現れない進捗(書面の提出、稟議の申請、社内での根回しなど)は反映されません。会話上は止まって見えても裏で動いていることはあるため、出力は「会話から見た現在地」として扱い、実際の進捗は担当への確認で補ってください。
プロンプト本文
あなたは営業案件のパイプラインを分析するアナリストです。
同一案件について時系列に並んだ複数商談の文字起こしを読み、案件が営業フェーズをどう進んできたかを可視化し、いまどこで止まっているか(停滞地点)とその要因仮説を特定してください。判断は文字起こしにある発言だけを根拠にし、書かれていないことは推測と明記するか「不明」としてください。
## 商談の文字起こし(複数・時系列)
{同一案件の複数回の商談文字起こしを、開催日が分かる形で古い順に貼り付け。2回以上}
## 想定する営業フェーズ(任意)
{自社のフェーズ定義があれば貼り付け。なければ空欄。空欄の場合は「初回接触→課題ヒアリング→提案・デモ→見積・稟議→クロージング→受注」を仮に用いる}
## 今日の日付(任意)
{停滞期間を測るための基準日。なければ空欄}
## 出力フォーマット
1. フェーズ遷移タイムライン
各商談を時系列(開催日つき)に並べ、その回で到達したフェーズと、前回比の動き(前進/横ばい/後退)を判定する。判定根拠となる発言を各回1つ短く引用する
2. 現在地と停滞地点
いまどのフェーズにいるか、いつの商談から前進が止まっているか(停滞の起点)を示す。今日の日付があれば停滞期間を示す。動いていないと判断した根拠を引用する
3. 停滞の要因仮説
会話から読み取れる「詰まっている理由」を挙げる。相手が明言した障害は[事実]、会話から読み取った推測は[推測]と区別する
4. 前進に必要な未解決事項
次のフェーズに進むために埋まっていない条件・確認事項を、確認相手とセットで挙げる
5. マネージャーへの示唆(3つ以内、具体的な行動で)
パイプラインレビューで担当に確認・指示すべき点
## 注意事項
- フェーズ判定・停滞判定は、文字起こしにある発言のみを根拠にする。書かれていない進捗を「進んだ」と判断しない。根拠がない箇所は「不明」と明記する
- 事実(相手・自社が実際に言ったこと)と、そこからの推測を必ず分ける。推測には[推測]と付す
- 曖昧な同意(「検討します」「前向きに」「社内で調整します」等)を、フェーズ前進のシグナルとして扱わない。動いた根拠が乏しい場合は「横ばい」とする
- 停滞期間は、文字起こしに開催日があり今日の日付が与えられた場合のみ算出する。日付がなければ順序のみを扱い、期間は「不明」とする
- 商談と商談の間に何が起きたか(実施されなかった社内のやり取り等)は文字起こしからは分からない。空白期間の中身を創作しない
- 引用は文字起こしの原文を短く抜き出す。金額・日付・固有名詞は原文どおりにする
- この分析はSFA/CRMの記録を使っていない。会話に現れない進捗(書面提出・稟議申請など)は反映されない前提であることを明記するこのプロンプトを動かしてみる
プリセットされた依頼のまま「送信」を押すと、AIの応答がその場でストリーミング表示されます(架空データに対する収録済みの応答。生成AIは呼び出しません)。
AIに渡した入力データ(架空サンプル)
1. フェーズ遷移タイムライン(仮フェーズ: 初回接触→課題ヒアリング→提案・デモ→見積・稟議→クロージング→受注)
開催日 | 到達フェーズ | 前回比 | 根拠(引用) |
|---|---|---|---|
2026-04-08 | 課題ヒアリング | 前進 | 「月末はこれで毎回3日くらい取られます」(課題が具体化)[事実] |
2026-04-22 | 提案・デモ | 前進 | 「打刻と集計が自動になるのは良いですね」+連携要件の確認 [事実] |
2026-05-13 | 見積・稟議(入口) | 前進 | 「金額感は想定内です」「次の枠に乗せる形で社内を通す」[事実] |
2026-06-04 | 見積・稟議(入口のまま) | 横ばい | 「まだ具体的に動けていなくて」「社内で調整してご連絡します」[事実] |
続きを見る(現在地・要因仮説・未解決事項・示唆)
2. 現在地と停滞地点
- 現在地: 見積・稟議フェーズの入口。提案と見積は提示済みだが、稟議(社内の投資枠通し)には未着手と見られる。
- 停滞の起点: 2026-05-13の提案から2026-06-04のフォローにかけて、フェーズが前進していない。実質的な停滞は6/4面談時点で顕在化。
- 停滞期間: 直近の商談(2026-06-04)から今日(2026-07-15)まで約6週間、記録上の接点なし。6/4自体も前進の根拠がなく「横ばい」のため、実質的な停滞は5/13以降と読める。
- 根拠: 「まだ具体的に動けていなくて」「いったん社内で調整して、こちらからご連絡します」(相手発の次アクションのまま、その後の会話が記録にない)[事実]。
3. 停滞の要因仮説
- 決裁タイミングの制約: 投資枠が四半期ごとで、次の枠に乗せる必要がある。稟議を出せる時期そのものが待ち状態の可能性。根拠:「投資枠が四半期ごとなので、次の枠に乗せる形で」[事実]。
- 連携懸念の未解決: 田中氏の最大関心であるペイロールデスク連携のバージョン確認が、自社・相手とも未完了。過去の二重入力の経験から慎重。この確認が終わらないと田中氏が社内で前に進めない可能性。根拠:「バージョンの確認、こちらもまだできていなくて」[事実]、確認完了が稟議の前提になっているかは会話に明言なし[推測]。
- 社内推進の停滞: 「社内で調整して連絡します」が相手発の次アクションになっており、ボールが相手側にある。自社からの働きかけが記録上見当たらない[推測]。
- 注記: 6/4以降に何が起きたか(稟議を出したか、連携確認が進んだか)は文字起こしに現れないため不明。裏で動いている可能性は排除できない。
4. 前進に必要な未解決事項
- ペイロールデスク連携の可否確定(確認相手: 田中氏。利用バージョンの共有を依頼し、自社側で連携可否を回答する)。田中氏が慎重な最大論点で、稟議の実質的な前提になっている可能性が高い。
- 次の投資枠のタイミングと稟議スケジュール(確認相手: 佐藤氏。「次の四半期枠」が具体的にいつで、そこに向けて何を用意すればよいか)。
- 相手側に渡ったままの次アクションの回収(「社内で調整してご連絡します」を待ち続けない。自社から連携確認という具体的な用件で再接触する口実がある)。
5. マネージャーへの示唆
- 担当(河野)に、6/4以降のこの案件の接点有無を確認する。会話記録が途切れているだけで裏で動いているのか、本当に止まっているのかで打ち手が変わる。
- 止まっているなら、次アクションを相手任せにせず「連携バージョンの確認」という具体的な用件で自社発の再接触を設定させる。曖昧なフォローではなく、田中氏の宿題を自社が引き取る形にする。
- 決裁タイミング(次の四半期投資枠)を佐藤氏に確認し、その枠に間に合うよう連携確認と稟議資料の準備を逆算させる。枠を一度逃すと停滞が長期化しやすい。
注記: 到達フェーズ・停滞判定・要因仮説は、貼られた4回の文字起こしにある発言のみを根拠とした。6/4以降の進捗、連携確認が稟議の前提かどうか、社内推進の停滞は、会話に現れないか読み取りを含むため「不明」または[推測]とした。SFA/CRMの記録は使っていないため、書面提出や稟議申請などが裏で進んでいる可能性は反映していない。
カスタマイズのヒント
- 自社のフェーズ定義に合わせる: 「想定する営業フェーズ」欄に自社のSFAのフェーズ名(例: リード→SQL→提案→内示→受注)を貼ると、その言葉で遷移を判定します。ヨミ会の用語とそろい、SFA上のフェーズとのズレも見えます。
- フェーズ移行の条件(Exit Criteria)を渡す: 「このフェーズを抜けるには決裁者との合意が必要」といった自社の移行条件を書いて渡すと、条件を満たさずにフェーズだけ進んでいる「見かけの前進」を検出しやすくなります。
- 複数案件を一括で回す: 案件ごとに文字起こしをまとめて、それぞれ同じプロンプトを回すと、パイプライン全体で「どの案件がどのフェーズで、いつから止まっているか」の一覧が作れます。レビュー前の下ごしらえに向きます。
よくある質問
商談の文字起こしが1件しかない場合でも使えますか?
このプロンプトは「フェーズの遷移」を見るものなので、1件だけでは遷移が描けず、現在地の把握にとどまります。案件の現在地を1件から評価したい場合は、単一案件を対象にしたP080(受注確度採点)やP081(フェーズ判定)のほうが向いています。遷移と停滞を見たいときは、同じ案件の複数回の商談を時系列で貼ってください。
SFAのフェーズと、このAIの判定がズレたらどちらが正しいですか?
どちらかが正しいというより、両方を突き合わせる材料として使ってください。このプロンプトは会話だけを根拠にするため、会話に現れない進捗(稟議申請など)は反映されません。逆にSFAは担当の手入力なので実態より進んで見えることがあります。ズレた案件こそ、担当に「会話上は横ばいだがSFAは提案済み、実際どちらか」と確認する価値があります。
「停滞している」と出たら、その案件は失注に近いということですか?
必ずしもそうではありません。停滞には、決裁タイミング待ちのような健全な停滞と、相手の関心が離れたことによる停滞があります。このプロンプトは「いつから、なぜ止まって見えるか」までを会話ベースで示しますが、失注確度そのものは判定しません。停滞の理由(要因仮説)まで見て、待ちなのか離脱なのかを人が判断してください。
