パイプラインレビューAIとは？会議前の論点整理と停滞検知をどう速くするか
パイプラインレビュー会議が「全案件の順番読み上げ」で1時間を使い切ってしまうチームは少なくありません。停滞アラートは出るのに、会議で何を決めるかが曖昧なままだと、マネージャーの負荷は下がりません。
このページでは、案件をきれいに保つ話ではなく、営業マネージャーがレビュー会議の前に何をそろえ、会議中に何を決めるかに範囲を絞ります。停滞検知の判定基準、レビュー会議の構成、案件健全性スコアリングまで具体的に解説します。
本記事のポイント
- パイプラインレビューAIは、会議中に要約を読むためではなく、会議前に論点を絞る用途で最も価値が出ます。
- 停滞検知、更新漏れ、予測差分、支援要請の4点を固定すると、レビュー会議が報告会になりにくくなります。
- AIは論点整理と優先順付けに向きますが、案件を押すか引くか、誰が介入するかの判断は人が持つべきです。
この記事で扱うテーマ
関連キーワード
- パイプラインレビュー AI
- 営業レビュー AI
- 案件レビュー AI
- pipeline review AI
このページで答える質問
- パイプラインレビューAIは何を変える？
- 会議前に何をそろえる？
- 停滞検知をどう使う？
- 停滞基準をどう決める？
パイプライン管理AIとパイプラインレビューAIは役割が違う
パイプライン管理AIは案件衛生を整えるための仕組みであり、パイプラインレビューAIは会議前に判断材料を整える仕組みです。前者は基盤、後者はマネジメント運用に近い位置づけです。
この違いを分けないまま導入すると、停滞アラートは出るのに会議で何を決めるかが曖昧なままになり、マネージャーの負荷は下がりません。
| テーマ | 主な目的 | 見るべきもの | 運用頻度 |
|---|---|---|---|
| パイプライン管理AI | 案件衛生の維持 | 停滞案件、更新漏れ、次アクション未設定 | 日次（自動） |
| パイプラインレビューAI | 会議前の論点整理 | 支援が必要な案件、予測差分、介入判断 | 週次（会議前） |
| 営業予測AI | 数字のズレ把握 | コミット差分、リスク案件、理由コード | 週次〜月次 |
停滞検知の判定基準
停滞の検知は、単に「何日動いていないか」だけでは不十分です。ステージごとに標準滞留期間を設定し、そこからの逸脱を検知する設計が必要です。
| ステージ | 標準滞留期間 | 停滞アラート基準 | 推奨アクション |
|---|---|---|---|
| 初回接触〜ヒアリング | 7日 | 10日以上未進展 | フォロー方法の見直し |
| ヒアリング〜提案 | 14日 | 21日以上未進展 | 提案準備のボトルネック確認 |
| 提案〜見積提示 | 7日 | 14日以上未進展 | 顧客側の検討状況確認 |
| 見積提示〜交渉 | 14日 | 21日以上未進展 | 決裁ルートの再確認 |
| 交渉〜受注/失注 | 21日 | 30日以上未進展 | マネージャー介入の判断 |
この基準は業種や商材の単価で異なります。まずは自社の過去データから中央値を算出し、1.5倍をアラート基準として設定するのが現実的です。
レビュー前にAIがそろえるべき4つの論点
停滞案件
最終接点が古い案件や、前回会議から進んでいない案件を先に出すと、会議で全件確認する必要が減ります。停滞理由（顧客側の遅延/担当者の未アクション/情報不足）まで仮分類されていると、議論が速くなります。
更新漏れ
案件が止まっているのか、単に更新されていないのかを切り分けると、不要な深掘りが減ります。最終更新日が7日以上前の案件を自動フラグするだけでも効果があります。
予測差分
担当者見立てとマネージャー見立ての差が大きい案件を先に出すと、会議が判断に寄ります。とくに受注確度を20ポイント以上変更した案件は、理由の確認を優先します。
支援要請
価格交渉、競合対応、役員巻き込みのように、マネージャーが介入すべき案件を分かる形にすると、会議後のアクションが明確になります。
案件健全性スコアリング
案件ごとの健全性をスコア化すると、レビュー会議で注目すべき案件の優先順位が自動で決まります。
| スコア要素 | 配点 | 判定ロジック |
|---|---|---|
| ステージ進捗 | 25点 | 標準滞留期間内なら満点、超過日数に応じて減点 |
| 次アクション設定 | 20点 | 行動+期限+対象者が揃っていれば満点 |
| 関係者情報 | 20点 | 決裁者・推進者の特定状況で按分 |
| 更新鮮度 | 15点 | 最終更新が3日以内なら満点、7日超で0点 |
| 競合対策 | 10点 | 競合の有無と対策の記載があれば加点 |
| 予測一致度 | 10点 | 担当者とマネージャーの見立ての差で按分 |
スコアが50点未満の案件をレビュー対象とし、70点以上はスキップ可能とすることで、会議時間を半分以下に圧縮できるケースもあります。
レビュー会議の構成
| セクション | 内容 | 時間配分 | 判断アウトプット |
|---|---|---|---|
| 前回アクション確認 | 前回会議の決定事項の進捗 | 5分 | 完了/未完了の確認 |
| 要注意案件レビュー | 健全性スコア50点未満の案件 | 15分 | 続行/介入/退出/再育成 |
| 予測差分の確認 | 数字見通しの変化と理由 | 5分 | コミット修正の要否 |
| 支援要請の対応 | マネージャー介入が必要な案件 | 10分 | 介入者と期限の確定 |
| 次回までのアクション | 決定事項の整理と担当割り | 5分 | アクションリストの確定 |
レビュー会議を速くする運用設計
- 会議の24時間前に、AIが要確認案件だけを抽出したレビューシートを出す。
- 案件ごとに、現状、リスク、次アクション、支援要請の4項目だけを見る。
- 健全性スコアで優先順位をつけ、スコアの低い案件から議論する。
- 会議中は事実確認を最小化し、続行、介入、退出、再育成のどれに寄せるかを決める。
- 会議後は決定事項を次アクションへ戻し、次回会議で改善確認を行う。
- 月次で停滞基準とスコアリングの閾値を見直し、自社の実態に合わせる。
判断をぶらさないための整理ポイント
CRM や営業基盤の記事では、機能比較だけで判断を進めると、入力設計、責任分界、会議運用のずれが残りやすくなります。実務では、どのデータを正本にするか、誰が更新するか、どこでレビューするかを先にそろえる方が失敗しにくくなります。
特に比較、移行、料金、運用負荷のテーマでは、導入前提と運用条件を visible text で置いておくと、検索流入後の意思決定が進みやすくなります。
| 論点 | 先に確認すること | 後回しにすると起きること |
|---|---|---|
| 入力設計 | 誰がいつ更新するか、会議で使う項目と一致しているか | 入力は増えるが意思決定には使われない状態になる |
| マスタ管理 | 会社、担当者、案件の正本がどこか | 名寄せ漏れと履歴分断で比較がぶれる |
| 引き渡し条件 | 営業、マーケ、CS の境界が言語化されているか | 受け取り拒否や責任転嫁が起きやすくなる |
| レビュー運用 | 週次や月次で何を見るか固定されているか | 導入後の改善が属人化して止まる |
導入・運用で先に決めること
比較記事や導入記事では、製品差より前に「自社がどこで詰まっているか」を揃える必要があります。入力が止まるのか、マスタが壊れているのか、会議で現状が見えないのかで、見るべき製品機能も変わります。
そのため、導入判断の本文では、運用責任者、評価指標、移行対象データ、現場の例外処理をセットで示す方が、実装後の迷いを減らせます。
見直し時に確認したいチェックリスト
- 比較表が機能名の列挙で終わらず、運用前提まで示しているか。
- 移行対象と持ち出し対象の違いが本文で読めるか。
- 営業や運用担当が毎週見る数字が固定されているか。
- 失敗しやすい条件や向かないケースを明示しているか.
よくある質問
パイプラインレビューAIは営業予測AIの一部ですか？
一部は重なりますが、主眼は会議前の論点整理です。数字の予測より、どの案件を議論するかを絞る運用に寄ります。予測AIは数値精度、レビューAIは会議効率が評価軸です。
レビュー会議の頻度はどれくらいがよいですか？
多くの組織では週次が基本です。案件数が少ないチームは隔週でも回りますが、月次やQBRだけでは案件の変化に追いつけないため、最低でも隔週を推奨します。
全案件をAIで点数化すれば十分ですか？
十分ではありません。点数だけだと介入理由が分からないため、停滞、差分、支援要請など論点が見える必要があります。スコアはあくまで優先順位付けのツールとして使います。
停滞基準は全ステージ同じでよいですか？
同じにすべきではありません。初期ステージは短く、後半ステージは長めに設定するのが一般的です。自社の過去データから各ステージの中央値を算出し、基準にするのが最も正確です。
