Agentic CRMを活用してパイプラインの停滞商談を自律検知する方法

パイプラインの状況はCRM上で一覧できているのに、停滞している商談にどう手を打てばいいか分からない、という営業組織は多いのではないでしょうか。パイプライン管理とは、商談の進捗を可視化し、停滞や失注のリスクに対処して受注確度を高める活動です。しかし、その多くは「見える化」で止まっており、停滞商談を検知しても次のアクションにつながっていません。実際に、CRMに蓄積されたデータは年間34%の速さで劣化するとされ（Gartner）、記録が古くなるほど停滞の判断自体が難しくなります。

そこで本記事では、パイプラインの停滞商談をAgentic CRMがどのように自律検知し、撤退・方針転換・優先継続という3つの方針でアクションにつなげるのか、「見える化」から「動く化」への転換という観点で解説します。

この記事を書いた人

本田正憲

合同会社クロスコムの代表｜専門商社にて7年間のBtoB営業を経て、マーケティング業界に参入。現在はSalesforce公式コンサルティングパートナーとして、ソリューション営業の業務プロセスに特化したAgentforce導入・定着支援と、Agentic CRM設計支援を提供している。

パイプラインが「見えているのに動けない」3つの原因

まずは、パイプラインが見えているのに動けなくなる原因を整理します。今回は、製造業向けの受発注管理システムを販売する中堅IT企業を例に考えていきます。この企業は説明のための架空の設定であり、実在の企業ではありません。この企業は営業担当が14名おり、CRMを導入して毎週月曜に週次のパイプラインレビューを実施しています。常時120件ほどの商談を抱え、1件あたりの平均リードタイムは約5か月です。一覧の上では進捗が見えているにもかかわらず、停滞した商談が放置されがちでした。ここでは、その3つの原因を整理します。

原因①活動記録が担当者任せで停滞が可視化されない

1つ目の原因は、活動記録が担当者任せになっていて、停滞が可視化されないことです。

なぜなら、商談が今どの状態にあるかは、担当者がCRMに活動を記録して初めて一覧に反映されるからです。記録が滞れば、実際には止まっている商談も、画面上は動いているように見えてしまいます。

たとえば、先ほどの受発注管理システムを販売する企業では、営業担当が訪問や電話のあと、CRMへの入力を後回しにしがちでした。ある担当者は、2週間連絡が取れていない商談を、最終接触日を更新しないまま「提案中」のステージに置いていました。マネージャーが週次レビューで一覧を見ても、その商談は正常に進行しているように映り、停滞に気づけませんでした。

このように、活動の記録が個人の裁量に委ねられていると、停滞は数字に現れず、対処の対象にすらなりません。

原因②停滞基準がなく次回アクション超過が見逃される

2つ目の原因は、そもそも「何日動かなければ停滞か」という基準がなく、次回アクションの超過が見逃されることです。

停滞かどうかを判断する日数の基準がなければ、次にやるべき行動の期限を過ぎても、それが遅れなのかどうかを誰も判定できないからです。

たとえば、この企業では次回アクション日をCRMに入力する運用はあったものの、期限を過ぎた商談を洗い出す仕組みがありませんでした。提案後のフォロー期限を10日過ぎた商談も、失注間近の商談も、一覧では同じ「商談中」として並んでいました。営業担当ごとに「1週間で動く商談」もあれば「1か月放置される商談」もあり、停滞の感覚は人によってばらばらでした。

このように、停滞を判定する共通の基準がないと、対処すべき商談を絞り込むことができません。

原因③週次レビューまで停滞に気づけず対処が遅れる

3つ目の原因は、停滞に気づくのが週次レビューの場に限られ、対処が後手に回ることです。

なぜなら、停滞の発見を人の目視によるレビューに頼っていると、レビューとレビューの間に起きた変化は、次の会議まで検知されないからです。

たとえば、先ほどの企業の週次レビューは毎週月曜でした。ある大型商談で、顧客側の窓口が火曜日に異動となり、返信が止まりました。しかし、その変化がレビューで話題に上がったのは翌週の月曜で、6日間まったく手が打たれませんでした。競合が動くには十分な時間で、最終的にこの商談は失注しました。

停滞に気づいた時点で、すでに対処のタイミングを過ぎているというのが、見える化だけで止まっている組織で繰り返し起きる問題です。

パイプラインを「見える化」から「動く化」に変えるAgentic CRMの仕組み

ここまで、パイプラインが見えているのに動けない3つの原因を整理してきました。では、この状態をどう変えればよいのでしょうか。重要なのは、「見える化」から「動く化」への転換です。停滞を一覧で見せるだけでなく、AIが停滞を検知し、対処の方針まで示してアクションにつなげます。これは2025年から2026年にかけてのパイプライン管理の主要なテーマになっています（ブリッジインターナショナル）。ここでは、その転換を実現するAgentic CRMの3つの仕組みを解説します。

仕組み①AIが活動ログから停滞をリアルタイムで自動検知する

1つ目の仕組みは、AIが活動ログを常時読み取り、停滞をリアルタイムで自動検知することです。

人が週次でレビューする代わりに、AIがメールや通話、次回アクション日の超過を監視すれば、停滞は発生した時点で検知できるからです。

たとえば、先ほどの受発注管理システムの企業では、次回アクション日を過ぎ、かつ直近10日間に顧客との往復がない商談を、AIが自動で抽出する設定にしました。月曜のレビューを待たず、条件に触れた商談はその日のうちにリスト化されます。以前は6日間気づけなかった窓口の返信停止も、翌日には検知される状態になりました。

このように、検知を人の目視からAIの常時監視に移すことで、停滞への対処が後手に回らなくなります。

仕組み②AIが停滞商談を3つの対処方針に自律分類する

2つ目の仕組みは、検知した停滞商談を、AIが3つの対処方針に自律的に分類することです。

なぜなら、停滞と一口に言っても、見込みが薄れた商談と、あと一押しで動く商談では、取るべき行動がまったく違うからです。

たとえば、この企業ではAIが停滞商談を「撤退・方針転換・優先継続」の3つに振り分けるようにしました。競合が優勢で予算も凍結した商談は撤退、提案内容が相手の関心とずれている商談は方針転換、購買のシグナルは強いのに営業側の動きが止まっている商談は優先継続、という具合です。分類の根拠になるのは、過去の受注・失注データとエンゲージメントの推移でした。

停滞を一律に扱わず、撤退・方針転換・優先継続の方針ごとに分けることが、見える化を動く化に変える中心になります。

仕組み③AIが対処方針に応じたアクションを自律通知する

3つ目の仕組みは、分類した方針に応じて、AIが次のアクションを担当者やマネージャーに自律通知することです。

方針が決まっても、それが担当者の画面に届かなければ、結局は放置されてしまうからです。

たとえば、先ほどの企業では、優先継続に分類された商談は担当者へ「今日中に連絡すべき商談」として通知され、撤退候補はマネージャーのレビュー用リストに自動で登録されるようにしました。方針転換にあたる商談には、提案のどこがずれているかの仮説もあわせて添えられます。担当者は毎朝、AIが選んだ数件の商談だけを確認すればよくなり、120件すべてを見直す必要がなくなりました。通知を受けたその日のうちに動けるため、停滞が長引く前に手を打てるようになりました。

このように、検知から分類、通知までを一続きにすることで、パイプラインは見えるだけの状態から実際に動く状態へと変わります。

停滞商談の種類別対処方針の設計

前章では、停滞を検知して3つの方針に分類し通知する仕組みを解説しました。ここからは、その「撤退・方針転換・優先継続」という3つの方針を、それぞれどう見極めるのかを設計します。分類の精度は、この見極めの基準をどれだけ具体的に決められるかで決まります。ここでは、3つの方針ごとの判断の考え方を整理します。

撤退判断：競合優位・予算凍結の兆候がある商談の見極め方

まず撤退判断は、勝ち筋が見えなくなった商談を早めに手放すための見極めです。

なぜなら、受注の可能性が低い商談にリソースを割き続けると、本当に動かすべき商談への時間が削られてしまうからです。

たとえば、先ほどの受発注管理システムの企業では、「競合がすでに導入を決めている」「予算が次年度以降に凍結された」「決裁者との接点が3か月以上ない」の3つのうち2つに当てはまる商談を、撤退候補とする基準を決めました。ある商談では、窓口担当は前向きでも、決裁者が競合製品での稟議を進めていることが分かり、撤退候補に分類されました。担当者はフォローを止め、その分の時間を優先継続の商談に振り向けました。

このように、撤退の基準を先に決めておくことで、勝てない商談を惰性で追い続ける状態を避けられます。

方針転換：提案やDMUのズレがある商談の立て直し方

次に方針転換は、商談自体は生きているものの、提案の中身や相手がずれている商談を立て直す見極めです。

停滞の原因が、見込みの低さよりも提案のミスマッチにある場合、アプローチを変えれば商談はふたたび動き出すからです。

たとえば、この企業では、現場担当者だけと商談が進み、決裁者や情報システム部門が一度も登場していない商談を、方針転換の候補としました。ある商談では、現場の使いやすさばかりを訴求していましたが、実際に評価していたのは経営層の投資対効果でした。そこで提案の切り口を、導入後のコスト削減額の試算に変えたところ、止まっていたやり取りが再開しました。

このように、誰に何を訴求するかを組み替えることで、失注しかけていた商談を立て直せます。

優先継続：シグナルは強いが営業が止まっている商談の加速方法

最後に優先継続は、購買のシグナルは強いのに、営業側の動きが止まっている商談を加速させる見極めです。

なぜなら、相手の関心が高いうちに動けなければ、せっかくの商談も時間とともに冷めてしまうからです。

たとえば、先ほどの企業では、資料の再閲覧や見積もりページへのアクセスが増えているのに、担当者からの連絡が1週間途絶えている商談を、優先継続に分類しました。ある商談では、顧客が価格ページを3日間で5回開いていたにもかかわらず、担当者が別案件に追われて放置していました。AIの通知を受けて即日連絡したところ、翌週には最終見積もりの提示まで進みました。

シグナルが強い商談ほど、営業が動くタイミングを逃さないことが受注確度を大きく左右します。

Agentic CRMが停滞商談を自律処理する場面3選

ここまでは、3つの方針をどう見極めるかという設計の話でした。では、その設計をもとにAgentic CRMが実際にどう動くのでしょうか。ここでは、先ほどの受発注管理システムの企業で、停滞商談をAIが自律的に処理した3つの場面を紹介します。

場面①停滞商談をAIが検出してマネージャーに自律通知する

1つ目の場面は、AIが停滞商談を検出し、マネージャーへ自律的に通知したケースです。

停滞の検出をマネージャーの目視に頼らず、AIが条件に触れた商談を自動で知らせれば、対処の判断がその日のうちに始められるからです。

たとえば、ある月曜の朝、AIが「次回アクション日を7日超過し、直近の往復もない商談が9件ある」とマネージャーに通知しました。以前であれば、この9件は週次レビューで初めて話題に上がっていたはずでした。マネージャーはその場で担当者に確認を依頼し、うち3件はその日のうちに再アプローチが始まりました。結果として、停滞から対処までの時間が、平均で6日から1日以内に短縮されました。

このように、検出から通知までをAIが担うことで、マネージャーは会議を待たずに動けるようになりました。

場面②連絡先の返信率低下をAIが検知してアプローチ案を出す

2つ目の場面は、連絡先の返信率が下がったことをAIが検知し、次のアプローチ案まで示したケースです。

なぜなら、返信率の低下は相手の関心が薄れ始めた兆候であり、早めに接触の仕方を変える必要があるからです。

たとえば、ある商談では、これまで2日以内に返ってきていた顧客からの返信が、2週間で3回連続して途絶えました。AIはこの変化を検知し、「窓口担当の関心が下がっている可能性があるため、別の関係者への接触を検討」というアプローチ案を担当者に提示しました。担当者は現場担当者を通じて情報システム部門の担当者に連絡を取り、止まっていた技術面の確認が動き出しました。

このように、シグナルの変化に応じた次の一手をAIが示すことで、担当者は迷わず打ち手を選べるようになりました。

場面③撤退基準に達した商談をAIがクローズ推奨に登録する

3つ目の場面は、撤退の基準に達した商談を、AIがクローズ推奨として自動で登録したケースです。

勝ち目のない商談をパイプラインに残し続けると、着地見込みの精度が下がり、営業の時間も奪われるからです。

たとえば、ある商談は、競合の導入がほぼ確定し、決裁者との接点も3か月以上ありませんでした。AIはこの商談を撤退基準に該当すると判定し、マネージャーのレビュー用リストにクローズ推奨として登録しました。マネージャーが内容を確認して承認すると、商談はパイプラインから外れ、着地見込みの数字も実態に近づきました。担当者はこの商談にかけていた時間を、優先継続の商談へ回せるようになりました。

撤退の判断をAIが補助することで、パイプラインには本当に追うべき商談だけが残るようになります。

停滞商談管理でAgentic CRMを使う際の失敗パターン3選

ここまで、Agentic CRMが停滞商談を自律処理する場面を見てきました。ただし、この仕組みは設定を誤ると、かえって現場の負担になります。ここでは、停滞商談の管理でAgentic CRMを使うときに陥りやすい3つの失敗パターンを整理します。

失敗①停滞日数を設定せずAIを動かして誤検知が多発する

1つ目の失敗は、停滞と判定する日数を決めないままAIを動かし、誤検知が多発することです。

なぜなら、何日で停滞とみなすかはステージや商材によって変わり、その基準がなければAIは正常な商談まで停滞と判定してしまうからです。

たとえば、先ほどの受発注管理システムの企業では、当初すべてのステージで一律「5日動きがなければ停滞」と設定しました。しかし、提案後の稟議待ちは2週間かかるのが通常で、正常に進んでいる商談まで大量に停滞として抽出されてしまいました。担当者は毎日30件を超える通知を受け取り、確認に追われる結果になりました。そこでステージごとに停滞日数を変え、稟議待ちは14日、初回接触後は7日と調整したところ、誤検知が大きく減りました。

このように、停滞日数をステージに合わせて決めておくことが、誤検知を防ぐ前提になります。

失敗②対処方針の基準がなくAIの分類が営業感覚とズレる

2つ目の失敗は、対処方針の基準を決めないままAIに分類させ、その結果が営業の感覚とずれることです。

撤退や優先継続を分ける条件が曖昧だと、AIは根拠のない分類を返し、担当者が結果を信頼しなくなるからです。

たとえば、この企業では最初、「見込みが低ければ撤退」という漠然とした基準しかありませんでした。そのためAIは、担当者の感覚では十分に勝ち目のある商談まで撤退候補に入れてしまい、営業から「分類が当てにならない」という声が出ました。そこで撤退の条件を「競合の導入確定」「予算凍結」「決裁者接点3か月以上なし」と具体化したところ、分類が営業の判断と一致するようになりました。

このように、方針を分ける条件を具体的な事実で定義することが、AIの分類を信頼できるものにします。

失敗③アラートが多すぎて担当者が無視するようになる

3つ目の失敗は、アラートを出しすぎて、担当者がそれを無視するようになることです。

なぜなら、通知が多すぎると重要なものとそうでないものの区別がつかなくなり、結局すべてが読み飛ばされてしまうからです。

たとえば、先ほどの企業では、停滞商談をすべて等しく通知していた時期がありました。1日に何十件も届くため、担当者は通知をまとめて既読にするようになり、本当に急ぐべき商談まで見落としていました。そこで、優先継続に分類された商談だけを「その日のうちに対応」として通知し、それ以外は日次のまとめに回すよう変えました。通知は1日数件に絞られ、担当者が確実に対応するようになりました。

アラートは数を絞り、本当に今動くべき商談だけを届けることが、AIを使った停滞管理を定着させる条件です。

Agentic CRMを使ったパイプライン停滞管理が機能する企業の条件

前章では、停滞管理でつまずきやすい失敗パターンを整理しました。では、どういう企業であればAgentic CRMを使った停滞管理がうまく機能するのでしょうか。ここでは、成果につながりやすい企業に共通する3つの特徴を解説します。

特徴①CRMに活動履歴と次回アクション日が記録されている

1つ目の特徴は、CRMに活動履歴と次回アクション日が、日常的に記録されていることです。

なぜなら、AIが停滞を検知する材料は、担当者が残した活動の記録と、次にやるべき行動の期限だからです。

たとえば、先ほどの受発注管理システムの企業では、訪問や電話のあとに活動を記録し、次回アクション日を必ず入力する運用が定着していました。この記録があったからこそ、AIは「期限を過ぎ、往復も止まっている商談」を正確に抽出できました。もし記録が虫食いの状態であれば、AIは停滞の発生を認識できなかったはずです。逆に言えば、記録さえそろっていれば、特別なデータ整備をしなくても停滞検知はすぐに動き始めます。

このように、活動と次回アクションの記録がそろっていることが、停滞検知の出発点になります。

特徴②停滞判定日数がステージごとにCRM上で合意されている

2つ目の特徴は、停滞と判定する日数が、ステージごとに社内で合意されていることです。

停滞の基準がステージに合っていなければ、AIの検知は誤りだらけになり、現場に使われなくなるからです。

たとえば、この企業では、初回接触後は7日、提案後の稟議待ちは14日というように、ステージごとの停滞日数をマネージャーと営業が話し合って決めていました。基準が共有されているため、AIが停滞と判定した商談に対して「これは確かに遅れている」と全員が納得できました。誰かが独断で決めた基準でなかったことが、運用の安定につながりました。

このように、停滞日数をステージ単位で合意しておくことが、AIの判定を現場に受け入れられるものにします。

特徴③週次以外でもAIアラートを確認できる運用体制がある

3つ目の特徴は、週次のレビュー以外の場でも、AIのアラートを確認できる運用体制があることです。

なぜなら、AIが停滞をリアルタイムで検知しても、それを見て動く人がいなければ、通知は放置されてしまうからです。

たとえば、先ほどの企業では、担当者が毎朝の始業時にAIの通知を確認する習慣をつくり、マネージャーは日中に届く撤退候補のリストをその都度チェックしていました。週次レビューは全体の方針確認の場に変わり、個別商談への対処は日々の中で完結するようになりました。通知を受け止める体制があったからこそ、検知が実際のアクションにつながりました。

アラートを日常的に確認する運用があってはじめて、停滞管理は動く化まで到達します。

Agentic CRMを使ったパイプライン停滞管理を急ぐべきでない企業の特徴

一方で、Agentic CRMを使った停滞管理を、今すぐ導入すべきでない企業もあります。前章の条件が整っていない場合は、先に日々の運用を整えるほうが先決です。ここでは、導入を急ぐべきでない企業の3つの特徴を整理します。

特徴①活動記録が習慣化されておらず停滞シグナルが取れない

1つ目の特徴は、活動記録が習慣化されておらず、停滞のシグナル自体が取れないことです。

なぜなら、AIは記録されたデータからしか停滞を判断できず、記録が乏しければ検知の材料がないからです。

たとえば、ある企業では、営業担当が受注した案件だけをCRMに記録し、進行中の商談の活動はほとんど残していませんでした。この状態でAIを動かしても、そもそも停滞を判定するための往復履歴や次回アクション日がなく、検知はほとんど機能しませんでした。まず必要なのは、日々の活動を記録する習慣を先につくることでした。記録がなければ、どれだけ高度なAIを導入しても、検知は空振りに終わります。

このように、記録の習慣がない段階では、停滞検知の前に活動記録の定着を優先すべきです。

特徴②商談ステージの定義が曖昧で停滞の判断基準がない

2つ目の特徴は、商談ステージの定義が曖昧で、停滞を判断する基準を決められないことです。

ステージの意味が担当者ごとに違えば、どの状態を停滞とみなすかも定まらず、AIの基準もつくれないからです。

たとえば、ある企業では「商談中」という一つのステージに、初回接触から最終見積もりまでのすべてが入っていました。これでは、どのくらい動きがなければ停滞なのかを決めようがありません。AIを導入する前に、まず商談ステージを接触・提案・見積もり・稟議のように分け、それぞれの意味を揃える必要がありました。ステージが分かれて初めて、どの段階で何日止まれば停滞かという基準を定義できます。

このように、ステージの定義が曖昧なままでは、停滞の基準も設計できません。

特徴③CRMへの記録抵抗が強くAIの判断精度が出ない

3つ目の特徴は、CRMへの記録に対する現場の抵抗が強く、AIの判断精度が出ないことです。

なぜなら、担当者が記録を負担に感じて入力を避けると、データが欠け、AIの分類も的外れになるからです。

たとえば、ある企業では、営業担当が「入力する時間があれば1件でも多く訪問したい」と考え、CRMへの記録を最低限しか行っていませんでした。この状態でAIに停滞を分類させても、判断の根拠となるデータが不足し、精度の低い結果しか返りませんでした。まず記録が営業自身の役に立つと感じられる仕組みをつくることが先でした。記録が営業の負担にしか感じられないうちは、AIが判断に使えるデータもそろいません。

記録への抵抗が残ったままでは、AIの判断精度は上がらず、停滞管理の導入は時期尚早だと考えます。

Agentic CRMでパイプラインの停滞管理を自律化する5ステップ

ここまで、停滞管理が機能する企業とそうでない企業の違いを見てきました。ここからは、実際にAgentic CRMでパイプラインの停滞管理を自律化するまでの流れを、5つのステップに分けて解説します。先ほどの受発注管理システムの企業が、どの順番で仕組みを整えたかに沿って進めます。

ステップ①停滞判定日数と連絡先の関与度基準をCRMに設定する

まず取りかかるのは、停滞と判定する日数と、連絡先の関与度の基準を、CRMに設定することです。

停滞管理のすべての起点は、どの商談を停滞とみなすかの基準にあるからです。

たとえば、先ほどの企業では、初回接触後7日、提案後14日というステージ別の停滞日数を、CRMのカスタム項目として設定しました。あわせて、連絡先の関与度を「直近30日の往復回数」「資料閲覧の頻度」でスコア化し、関心の高い連絡先を判別できるようにしました。この2つの基準が、後のすべての自動処理の判断材料になりました。基準を最初にCRMへ明文化しておくと、担当者やマネージャーの間で停滞の解釈がぶれなくなります。

このように、停滞日数と関与度の基準を先に決めることが、自律化の出発点になります。

ステップ②対処方針の判定ロジックをAIスコアリングに設定する

次に行うのは、撤退・方針転換・優先継続を分ける判定ロジックを、AIのスコアリングに設定することです。

検知した停滞商談を方針ごとに振り分けるには、その判断の条件を数値化しておく必要があるからです。

たとえば、この企業では、競合の状況・予算の状態・決裁者との接点・購買シグナルの強さを組み合わせて、3つの方針を判定するロジックを設計しました。競合が確定していて決裁者接点もなければ撤退、シグナルが高いのに営業が止まっていれば優先継続、というように条件を明文化し、AIがスコアに応じて自動で分類できるようにしました。条件を言葉で決めておけば、なぜその商談が撤退や優先継続に分類されたのかを、あとから担当者が確認することもできます。

このように、方針の判定を数値の条件に落とし込むことが、AIの自律分類を可能にします。

ステップ③活動データをCRMに自動連携する仕組みを構築する

そのうえで必要になるのが、活動データをCRMに自動で連携する仕組みを構築することです。

なぜなら、AIの検知や分類の精度は、元になる活動データがどれだけ自動で集まるかに左右されるからです。

たとえば、先ほどの企業では、メールや通話の履歴を手入力に頼らず、メールツールと電話システムをCRMに連携し、往復の記録が自動で残るようにしました。担当者が入力を忘れても、顧客とのやり取りの事実はCRMに蓄積されます。これにより、停滞の判定に使えるデータの欠けが大きく減りました。活動が自動で残る仕組みがあれば、担当者は記録のための入力に時間を取られず、顧客との対話に集中できます。

このように、活動データの自動連携が、検知と分類の精度を支えます。

ステップ④停滞検知から自律アラート送信フローをCRMで実装する

続いて実装するのが、停滞の検知から自律的なアラート送信までのフローを、CRM上で組むことです。

検知と分類ができても、それを担当者に届けるフローがなければ、アクションにはつながらないからです。

たとえば、この企業では、停滞条件に触れた商談をAIが検知したら、方針に応じて通知先と文面を変えるフローをCRMに実装しました。優先継続は担当者へ即時通知、撤退候補はマネージャーのリストへ登録、という具合に自動で振り分けられます。担当者は毎朝、自分あての通知を確認するだけでよくなりました。通知の内容も方針ごとに変わるため、受け取った担当者は次に何をすべきかをすぐ判断できます。

検知から通知までを自動フロー化することで、停滞への対処の初動が大きく早まります。

ステップ⑤撤退・優先継続の対処フローをCRMで自動化する

最後に取り組むのが、撤退と優先継続の対処フロー自体を、CRMで自動化することです。

なぜなら、通知の先にある実際の処理まで自動化して初めて、停滞管理は動く化に到達するからです。

たとえば、先ほどの企業では、撤退が承認された商談は自動でクローズ処理に進み、着地見込みから除外されるようにしました。優先継続の商談は、フォロータスクが自動生成され、期限が近づくと再通知されます。人が判断すべき承認だけを残し、その前後の処理はCRMが担うようにしたのです。担当者とマネージャーは判断に専念でき、事務的な処理に時間を奪われなくなりました。

以上が、Agentic CRMでパイプラインの停滞管理を自律化する5つのステップでした。

パイプラインの停滞管理で追うフェーズ別KPI

前章では、停滞管理を自律化する5つのステップを解説しました。導入したら、次はその効果をどう測るかが問われます。ここでは、停滞管理の進み具合を測るKPIを、導入期・活用期・成果期の3つのフェーズに分けて解説します。

フェーズ①導入期：停滞の自動検知率と誤検知率で測る

導入期にまず見るのは、停滞の自動検知率と誤検知率です。

なぜなら、この時期の課題は、AIが停滞を正しく拾えているか、そして正常な商談を誤って停滞と判定していないかを確かめることだからです。

たとえば、先ほどの受発注管理システムの企業では、導入当初、人が目視で見つけた停滞商談のうちAIが検知できた割合と、AIが停滞と判定したうち実際は正常だった割合を、毎週記録しました。当初は誤検知率が高かったものの、停滞日数をステージごとに調整するにつれて、誤検知は数週間で大きく下がりました。検知率と誤検知率をあわせて見ることで、AIが停滞を拾いすぎているのか、それとも逃しているのかを切り分けられます。

このように、導入期は検知の正確さを指標に置くことが重要です。

フェーズ②活用期：対処方針分類後の商談化率変化で測る

活用期に見るのは、対処方針で分類したあとの商談化率の変化です。

検知が正確になったら、次は分類にもとづく対処が実際に成果へつながっているかを確かめる必要があるからです。

たとえば、この企業では、優先継続に分類して即日アプローチした商談が、その後どれだけ次のステージに進んだかを追いました。優先継続の商談は、放置されていた頃と比べて次のステージへの移行率が明確に上がりました。あわせて、撤退に分類した商談を早めに手放した分、営業は勝ち筋のある商談に時間を使えるようになりました。分類が正しいかだけでなく、分類したあとに商談が前へ進んだかどうかを見る点が、このフェーズの要点です。

このように、活用期は分類後の商談化率を指標に置きます。

フェーズ③成果期：ステージ間の平均在籍日数の短縮で測る

成果期に見るのは、ステージ間の平均在籍日数がどれだけ短くなったかです。

なぜなら、停滞管理の最終的な狙いは、商談が各ステージで滞る時間を減らし、パイプライン全体を速く動かすことにあるからです。

たとえば、先ほどの企業では、停滞管理を自律化する前、提案ステージの平均在籍日数は45日でした。導入から半年後、この日数は28日まで短縮されました。パイプライン全体の平均リードタイムも、約5か月から約4か月に縮まりました。当初の「一覧では見えているのに停滞商談が放置される」という課題から始まった取り組みが、商談が動くスピードの数字となって表れたのです。

成果期はステージ間の在籍日数の短縮を指標に置くことで、見える化から動く化への成果を確かめられます。

なお、KPIの設計全般については、ほか記事「BtoBマーケティングのKPI設計ガイド」でも解説していますので、あわせて参考にしてもらえると嬉しいです。

Agentic CRMを使ったパイプライン停滞管理の費用感

KPIの見方を整理したところで、次に気になるのが費用です。ここでは、Agentic CRMを使ったパイプライン停滞管理にかかる費用を、3つの観点から整理します。金額は構成によって幅があるため、ここでは考え方と目安を示します。

費用①活動キャプチャとAIスコアリングのライセンス費用の目安

1つ目の費用は、活動データの自動取得とAIスコアリングを使うためのライセンス費用です。

なぜなら、停滞検知の精度は、活動が自動でCRMに集まるかと、AIがスコアリングを実行できるかにかかっているからです。

たとえば、メールや通話の履歴を自動でCRMに記録する機能や、商談をスコアリングするAI機能は、多くの場合、既存のCRMライセンスに追加する形で費用が発生します。利用するユーザー数や、AIの処理量に応じて課金される会話単位の課金方式が採られることもあります。先ほどの企業では、まず営業14名分から始め、効果を見ながら範囲を広げました。

ライセンス費用は利用人数と機能の範囲で変わるため、小さく始めて効果を見ながら広げるのが現実的です。

費用②停滞判定設計・フロー構築にかかる外部支援費用の目安

2つ目の費用は、停滞の判定基準づくりや自動フローの構築を外部に依頼する場合の支援費用です。

ステージごとの停滞日数や方針の判定ロジック、通知フローの設計は、自社だけで詰めるのが難しい場合があるからです。

たとえば、先ほどの企業では、停滞日数の初期設定と3方針の判定ロジックの設計を、外部の支援会社に依頼しました。自社の商談データを分析し、どのステージで何日を基準にするか、どの条件で撤退と判定するかを一緒に設計してもらいました。この初期設計を外部と組んだことで、誤検知の多い状態を早く抜け出せました。自社だけで試行錯誤するよりも、初期設計を経験のある支援会社と組むほうが、立ち上げの遠回りを避けられます。

このように、初期の設計フェーズに外部支援を使うと、立ち上げの精度と速度を高められます。

費用③アラート運用とスコア精度改善の継続コストの目安

3つ目の費用は、アラートの運用とスコア精度の改善を続けるための継続的なコストです。

なぜなら、停滞の基準や方針の判定は、一度決めたら固定でよいものではないからです。商談の実態に合わせて、調整を続ける必要があります。

たとえば、この企業では、導入後もマネージャーが月に一度、誤検知の状況と分類の精度を確認し、停滞日数や判定条件を見直していました。市場や商材が変われば、停滞とみなす基準も変わります。こうした調整を続ける工数、あるいは外部への運用支援の費用が、継続コストとして発生します。見直しを止めると、時間の経過とともにAIの分類は現場の実態からずれていきます。

このように、停滞管理は運用しながら精度を高めるため、継続的な調整のコストを見込んでおくことが重要です。

【一問一答】Agentic CRMを使ったパイプライン停滞管理でよくある質問

ここまで、停滞管理の設計から費用までを解説してきました。最後に、パイプラインの停滞管理でよく寄せられる質問に答えていきます。

質問①停滞の判定日数はどのように設定するか

ステージごとに分けて設定するのが基本です。初回接触後は短めの7日前後、提案後の稟議待ちは長めの14日前後というように、そのステージで通常どのくらい時間がかかるかを踏まえて決めます。すべてを一律の日数にすると、正常に進んでいる商談まで停滞と判定されてしまいます。

質問②対処方針の判断はどこまでAIに任せていいか

分類まではAIに任せ、最終的な判断は人が行うのが現実的です。撤退やクローズのように影響の大きい処理は、AIが候補を示し、マネージャーが承認する形にします。AIは判断の材料をそろえる役割、人は最終決定という分担にすると、精度と納得感の両方を保てます。

質問③担当者がアラートを無視する場合どう対処するか

通知の数を絞ることが先決です。すべての停滞を等しく通知すると、本当に重要なものが埋もれてしまいます。優先継続のように今すぐ動くべき商談だけを即時通知し、それ以外は日次のまとめに回すと、担当者が確実に対応するようになります。

質問④CRMへの入力が少ない状態でも使えるか

入力が乏しい状態では、精度の高い停滞検知は難しいです。AIは記録されたデータから停滞を判断するため、活動履歴や次回アクション日が残っていないと、検知の材料が不足します。まずは日々の活動を記録する運用を整えることが先になります。

質問⑤停滞管理にCRM以外で使えるツールはあるか

表計算ソフトでも停滞商談の一覧化はできますが、リアルタイムの検知と自律的なアクションまでは難しいのが実際です。停滞の自動検知や方針の分類、通知までを一続きにするには、活動データとAIが連携するCRMを軸にするのが現実的です。

パイプライン管理の本質は「見える化」ではなく「動く化」にある

パイプライン管理の本質は、商談を一覧で見せる「見える化」ではなく、停滞した商談に手を打つ「動く化」にあります。本記事では、パイプラインが見えているのに動けない原因から、Agentic CRMが停滞を自律検知し、撤退・方針転換・優先継続の3つの方針でアクションにつなげる仕組み、そして自律化のステップやKPI、費用までを一連の流れとして解説してきました。

停滞商談への対処は、担当者の記憶や週次レビューに頼るほど後手に回ります。AIが停滞を検知し、方針を分け、次の一手を通知するところまで設計できれば、パイプラインは見えるだけの状態から、実際に動く状態へと変わります。まずは停滞と判定する日数の基準を決めるところから、自社のパイプラインを動かしてみてはいかがでしょうか。本記事が、その一助になれば幸いです。