営業プロセス設計とパイプライン管理｜設計から運用まで一気通貫で実行可能にする型を作る
公開日 ・ 更新日 ・ 読了 28分
「今月の売上、本当に着地するのか」。マネージャーが確認しようとしても、担当者の頭の中にしか案件の状況がない。個別に声をかけてヒアリングしながら数字を積み上げる、という状態が続いていないでしょうか。営業チームの人数が増えるほど、この問題は深刻になります。
パイプライン管理は、そのような「属人化した進捗把握」を組織として機能する仕組みに置き換えるためのマネジメント手法です。この記事では、営業プロセス 設計からフェーズ定義・移行条件の明文化・KPI設定・ツール選定・運用定着・改善サイクルまで、一気通貫で実行できる型を解説します。
パイプライン管理とは
パイプライン管理とは、リード獲得から受注までの営業プロセスをフェーズに分け、各フェーズに存在する案件の状況を継続的に可視化・管理するマネジメント手法です。単なる案件リストの管理ではなく、「どこで案件が詰まっているか」「どのフェーズで失注が集中しているか」を組織として把握し、打ち手につなげることを目的にしています。
この管理手法が多くの営業組織で課題になる背景には、「営業プロセスを定義してはいるが、実態の把握が個人頼み」という状態があります。プロセスを設計しても、その流れを外から観察・分析する仕組みがなければ、マネジメントは成立しません。
パイプラインという概念の意味
「パイプライン」という言葉は、リードが一方の端から入り、受注として反対の端から出てくるまでの流れを「管の中を流れる流体」に見立てたものです。この比喩が管理の本質をよく表しています。
管の中で流体が「詰まる」場所があれば、そこにボトルネックがあります。管のどこかに「穴」が開いていれば、案件が途中で漏れ出ています。パイプライン管理の核心は、この「詰まり」と「漏れ」を、感覚ではなくデータとして特定することです。上流に案件が大量に溜まっているのにクロージングフェーズに流れてこない場合、提案フェーズで何らかの問題が起きていると判断できます。特定のフェーズで失注が集中している場合、そのフェーズの活動の質に改善の余地があります。
「営業プロセス管理」との関係についても整理しておきます。営業プロセスとは、社内でどのような活動をどの順序で行うかを定義したものです。パイプライン管理は、その営業プロセスに沿って案件がどう流れているかを外から観察・分析するマネジメント手法です。ふたつは車の両輪であり、プロセスを定義するだけでも、流れを管理するだけでも機能しません。
パイプライン管理の目的
パイプライン管理の目的は、大きく3つに集約されます。
- 売上予測の精度向上 各フェーズの案件数・金額・受注確度から、今月・今四半期の売上着地を定量的に見通せるようになります。「なんとなく達成できそう」から「データ上では○○万円の着地が見込まれ、○○万円不足している」という議論に変わります。
- ボトルネックの早期発見 どのフェーズで案件が止まっているか、どこで失注が集中しているかを可視化し、問題が大きくなる前に対処できます。四半期末に積み残しが発覚するという状況を防げます。
- 営業活動の標準化と再現性の確保 受注した案件に共通するパターンをデータから読み取り、再現可能な営業プロセスとして組織に定着させられます。属人化した「勝ちパターン」を全員が使える型にすることが目的です。
重要なのは、パイプライン管理が「担当者の進捗を叱責するための道具」ではないという点です。案件が進まない原因を組織として探し、マネージャーが支援のための判断をするための情報基盤が、パイプライン管理の本来の姿です。
パイプライン管理が営業組織にもたらす効果
パイプライン管理の効果は、「売上予測の精度」「ボトルネック発見」「育成と標準化」の3つに集約されます。ただし、これらの効果を得るためには前提条件があります。本節では効果と並んで注意点・デメリットも扱います。設計なき導入では機能しないどころか、現場の疲弊を招く可能性があるためです。
効果①：売上着地予測の精度向上
パイプライン管理を機能させると、売上予測が「勘と経験」から「データと確度の計算」に変わります。具体的には、各フェーズに存在する案件数×フェーズごとの過去受注確度×平均単価という考え方で、今月・今四半期の売上見込みを定量的に算出できます。
この精度が上がると、マネジメント上の判断が変わります。「着地が足りなければどのフェーズに案件を補充するか」「クロージング近くの案件にリソースを集中するか」という意思決定を、データを根拠に行えるようになります。感覚的な楽観や悲観ではなく、具体的な数字に基づいた議論が可能になります。
効果②：ボトルネックの特定と早期対処
パイプライン管理の最も実務的な効果は、「どのフェーズで案件が止まっているか」をタイムリーに把握できる点です。
フェーズ滞留日数が平均より大幅に長い案件を定期的にリストアップすることで、放置すれば失注につながる案件を早期に発見できます。また、フェーズ転換率（各フェーズから次フェーズへ進んだ案件の割合）を継続的に追うことで、「提案フェーズから見積フェーズへの転換率が他フェーズと比べて著しく低い」といったパターンを発見し、改善の優先順位を決められます。
放置した場合のリスクは明確です。四半期末に積み残し案件が発覚してから手を打っても間に合いません。特定フェーズで失注が集中しているのにそのフェーズの活動を変えなければ、同じ失敗が繰り返されます。パイプライン管理は、この「遅すぎる発見」を構造的に防ぐ手段です。
効果③：営業担当者の育成と標準化
パイプラインデータが蓄積されると、担当者ごとの「強いフェーズ・弱いフェーズ」が数値として見えるようになります。Aさんは初回接触からニーズ確認への転換率が高いが、提案からクロージングへの転換率が低い、という個別のパターンを把握できます。
この情報があることで、マネージャーのフィードバックが「全体的に頑張れ」から「提案フェーズで顧客の意思決定構造を確認する習慣をつけよう」という具体的な指摘に変わります。また、受注した案件のフェーズ転換パターンを標準として組織に広めることで、属人化した勝ちパターンを再現可能な型に落とし込めます。パイプライン管理は、データの一元化だけでなく、営業プロセスの標準化とその再現性の確保という両輪で機能します。
パイプライン管理の注意点・デメリット
効果が大きい一方で、パイプライン管理にはいくつかの注意点があります。
- 入力コストの発生 パイプライン管理はデータが入力されて初めて機能します。現場担当者の入力負荷が高い設計になっていると、「入力するだけで一日が終わる」という状態が発生し、形骸化します。入力項目を必要最小限に絞り、モバイル対応や外部ツールとの連携でデータ収集を自動化するなど、入力負荷を下げる設計が前提条件になります。
- フェーズ定義が曖昧だとデータが信頼されなくなる 担当者によって同じ案件を異なるフェーズに置くという状態が続くと、フェーズ別の集計が意味をなさなくなります。「提案した気がするから提案フェーズに上げた」という主観的な判断がデータに混在すると、管理者もデータを信頼できなくなります。後述するフェーズ移行条件の明文化は、この問題への直接的な対処です。
- 「報告ツール」に成り下がるリスク マネージャーが数字を監視するためだけにパイプライン管理を使うと、現場は「見られるために入力する」という受け身の姿勢になります。実態とかけ離れたデータが積み上がり、ツールが形骸化します。管理の目的を「報告の取得」ではなく「ボトルネック解消のための議論の材料にする」と位置づけることが、定着の条件です。
営業プロセスの設計方法
営業プロセスを設計するとき、出発点を「売る側の活動の都合」に置くと、現場に定着しにくくなります。正しい起点は「顧客がどう検討を進めるか」というプロセスです。顧客の行動に対応する形で自社の営業活動を設計することで、フェーズが現実の商談の動きに合致し、データの信頼性が上がります。詳細な設計ステップはクラスター記事で扱います。ここではプロセス設計の基本的な考え方と、フェーズ数を決めるための判断軸を整理します。
設計の起点は「顧客の検討フロー」
営業プロセスを「提案する→デモをする→見積を出す」という売り手の活動で定義すると、顧客の行動と対応しないフェーズが生まれます。顧客が課題をまだ認識していない段階で「提案フェーズ」とマークしても、実態とのズレが生じます。
有効なアプローチは、顧客の検討段階に対応させる形でプロセスを設計することです。「課題認識→情報収集と比較→社内検討への合意→意思決定」という顧客の動きに対して、自社の営業活動をどう当てはめるかを考えます。これにより、「このフェーズに進んだということは、顧客が○○をしたということ」という対応関係が明確になり、フェーズの意味が担当者にとって自然に理解できるものになります。
顧客主語でプロセスを定義することが、フェーズ運用の信頼性を高める出発点です。売る側のツールや手順を主語に設計すると、現場への定着が難しくなるという実務上のパターンとも整合します。
フェーズ数の決め方
フェーズ数は5〜7が運用しやすい目安です。フェーズが多すぎると入力・管理が複雑になり形骸化しやすくなります。少なすぎると問題箇所を特定できず、管理の意味が薄れます。
フェーズを決めるときの問いは一つです。「このフェーズが終わったと判断できる、客観的な事実は何か」。この問いに答えられない場合、そのフェーズは実際には機能しない可能性があります。例えば「商談中」というフェーズは、始まりも終わりも主観的すぎて管理に使えません。「顧客の課題ヒアリングが完了し、決裁者が次回の提案参加を承諾した」という条件を満たした時点を「ニーズ確認完了」と定義すれば、誰が判断しても結果が一致します。
フェーズ数が決まったら、各フェーズを「顧客の意思決定の節目」に対応させて配置します。細かい活動（電話・メール・資料送付）はフェーズではなくアクション記録として管理し、フェーズはあくまで顧客の検討状態の変化を表すものとして設計します。
設計の詳細を深める前に
営業プロセスの設計は、フェーズ定義だけでなく「誰が・何を・どの順序で行うか」というアクションレベルの設計も含みます。また、業種・商材・セールスサイクルの長さによって最適な設計は異なります。設計ステップの詳細、業種別のフェーズ設計例、既存プロセスを見直すための手順については、営業プロセスの設計方法で解説しています。
フェーズ移行条件の設計
フェーズを設けても、移行条件が曖昧だとデータの信頼性が崩壊します。これはパイプライン管理で最も見落とされがちな設計上の問題です。担当者が主観的な判断でフェーズを動かしていると、フェーズ別の集計は数字として存在していても意思決定の根拠にならなくなります。このセクションでは、競合記事の大半が「フェーズを定義せよ」で止めているところを一歩進め、「何をもってフェーズが進んだとみなすか」という移行条件の設計方法を具体的に示します。
フェーズ移行条件とは何か
フェーズ移行条件とは、「次のフェーズに進んでいい」と全員が共通認識を持てる、客観的な完了条件の定義です。
典型的な失敗例は、「感触がよかったので提案フェーズに上げた」という判断です。「感触」は担当者ごとに異なり、集計した場合にノイズになります。移行条件は、できる限り「顧客側のアクション」で定義することが重要です。顧客が実際に何かをした事実は、担当者の主観よりも客観性が高いためです。
例えば「提案フェーズ」から「見積提出フェーズ」への移行条件を設計する場合、「顧客の課題ヒアリングが完了した（顧客側アクション）」かつ「決裁者が提案参加を口頭または書面で承諾した（顧客側アクション）」が満たされたときに移行可能とすれば、誰が判断しても同じ結論になります。「提案の準備ができた（自社アクション）」だけでは、顧客の状態が確認できていないため移行条件として不十分です。
移行条件の設計ステップ
移行条件の設計は、受注案件と停滞・失注案件の比較から始めます。
まず、過去に受注した案件を振り返り、各フェーズで「何をもって次へ進んだか」を棚卸しします。複数の担当者の受注案件を比較すると、共通している移行のパターンが浮かび上がります。次に、停滞した案件や失注した案件を照らし合わせ、「進んだように見えたが実は進んでいなかった」条件を洗い出します。例えば、「デモを実施した」という自社アクションだけでフェーズを上げていたが、顧客側に承認した担当者がいない状態だった、という失敗パターンが見えることがあります。
最後に、条件を「顧客側のアクション」と「自社のアクション」に分けて明文化します。
- 顧客側のアクション 「顧客が次回の打ち合わせ参加に同意した」「決裁者に引き合わせる約束を取った」「見積の発注条件について質問をしてきた」など、顧客が実際に行動した事実。
- 自社のアクション 「課題ヒアリングシートを埋めた」「提案書を送付した」「見積書を発行した」など、自社が完了すべき作業の事実。
重要なのは、自社のアクションだけで移行条件を完結させないことです。自社が「提案書を送った」だけでは、顧客が検討を前に進める状態にあるかどうかが確認できません。
移行条件をチームに浸透させる方法
設計した移行条件は、SFAのフェーズ変更時の必須入力項目として組み込むことで機能します。フェーズを変更しようとすると「決裁者の参加承諾を取得済みですか」という確認項目が表示され、記入しなければ保存できない設計にすることで、条件の確認が業務フローに組み込まれます。
また、週次レビューでフェーズ移行の根拠を口頭で確認する習慣を作ることも有効です。「なぜ今週このフェーズに上げたか」を担当者に説明させることで、移行条件への意識が自然と高まります。最初は意識的に確認が必要でも、継続することで条件確認がチームの文化になります。
営業フェーズ 定義の詳細設計や、業種別・商材別の移行条件の事例については、営業フェーズの定義と移行条件を参照してください。
パイプライン管理で追うべきKPI
KPIは「計測するために設定する」のではなく、「次の打ち手を決めるために設定する」という視点が重要です。数字を追うこと自体が目的になると、指標の数が増え、何を改善すべきかが見えにくくなります。各KPIが「どの問いに答えるための指標か」を明確にした上で選定することが、運用可能なKPI設計の条件です。KPIの詳細な測定方法や設計の考え方については、営業パイプライン 指標で扱います。ここでは、パイプライン管理に直結する代表的なKPIと、それが営業生産性のどの変数に影響するかを整理します。
営業生産性の方程式とパイプラインの関係
パイプライン管理が「なぜ売上につながるのか」を理解するために、営業生産性を次の方程式で整理できます。
営業生産性＝（商談数×受注率×単価）÷工数
パイプラインの各フェーズは、この方程式のいずれかの変数に直接影響します。
- 商談数への影響 パイプラインの上流（リード獲得→初回接触→ニーズ確認）に関わります。この区間の件数と転換率が、有効商談として下流に流れる案件数を決めます。上流に案件が少ない場合、リード獲得施策や商談化率の改善が課題です。
- 受注率への影響 各フェーズの転換率（CVR）と停滞フェーズの特定が直結します。提案フェーズからクロージングフェーズへの転換率が低い場合、提案の質や意思決定者への接触が不足している可能性があります。フェーズ転換率を見ることで、受注率を下げている原因フェーズを特定できます。
- 単価への影響 クロージング段階でのオプション提案・条件交渉の記録を追跡することで、単価が下がっているパターンを発見できます。どの案件でどのような条件変更が発生しているかを可視化することが、単価改善の起点になります。
- 工数への影響 各フェーズのリードタイム（案件発生日からのリードタイム）とフェーズ滞留日数が該当します。特定フェーズで滞留が長い場合、そのフェーズの活動に無駄が発生しているか、担当者が何かに詰まっていると読み取れます。
この4つの変数に対して、パイプライン管理がどのように貢献するかを理解した上でKPIを設定することで、「どの数字を上げれば売上に直結するか」という優先順位が明確になります。
代表的なパイプラインKPIの一覧
実務で追うべきKPIを整理します。
- フェーズごとの案件数・金額 各フェーズに何件・いくら分の案件があるかの現状把握。上流が薄い・特定フェーズが偏って多いなどの異常を発見します。
- フェーズ転換率（CVR） 各フェーズから次フェーズへ進んだ案件の割合。転換率が低いフェーズがボトルネック候補です。
- 案件発生日からのリードタイム・フェーズ滞留日数 案件が発生してから受注（または失注）に至るまでの期間と、各フェーズで何日停滞しているかの指標です。フェーズ滞留日数の平均を超えた案件は早期に確認が必要です。
- 加重平均受注予測 各フェーズの案件金額×フェーズ確度（過去の受注率）の合計。売上着地予測の基礎数値です。
- 失注率・失注理由の集計 特定フェーズでの失注集中パターンを発見するための指標です。失注理由を「競合負け」「予算不足」「ニーズなし」「タイミング」などに分類して集計すると、改善の優先順位が見えます。
これらのKPIをどの頻度で確認し、どの閾値を超えたらアクションを起こすか、という運用設計の詳細は、営業パイプラインの指標設計で解説しています。
パイプラインの可視化とツール選定
Excelでも始められますが、リアルタイムの共有と入力負荷の軽減という観点では、チームの規模が拡大するにつれて限界が生じます。規模・目的・現在のツール環境に応じた選択が重要で、「SFAを使えば自動的にパイプライン管理ができる」という考え方も誤りです。ツールはあくまで仕組みの実装手段であり、フェーズ定義と移行条件の設計が先です。
Excelでのパイプライン管理：向くケースと限界
Excelによるパイプライン管理が向くケースは、主に次の状況です。
- 営業担当者が3〜5名程度で、案件数が少ない段階。
- フェーズ数が少なく、更新頻度が週次程度に収まる状況。
- まず可視化の習慣を作りたい、試験的な運用として始めたい段階。
一方で、チームが拡大するにつれていくつかの限界が顕在化します。複数人が同時編集するとデータが破損または上書きされるリスクがあります。リアルタイムの更新が難しいため、週次レビュー時点のデータが既に古くなっていることが多くなります。集計・分析に手作業が発生し、マネージャーが「Excelの整理」に時間を使ってしまいます。モバイルからの更新が難しいため、外出中の担当者が入力を後回しにするというパターンも発生します。
SFA/CRMによるパイプライン管理：向くケースと主な機能
SFA（営業支援システム）またはSFA/CRMを活用したパイプライン管理が有効になるのは、次のような状況です。
- 担当者が増え始め、マネージャーが複数案件を横断で確認する必要が出てきた段階。
- 売上予測をより精度高く行いたい、またはデータを営業改善に活用したい段階。
- 入力の二重管理やExcelの更新漏れが問題になっている状況。
SFA/CRMには、パイプライン管理に直結する機能が複数含まれています。案件をフェーズごとにカンバン表示する「案件ボード」では、全担当者の案件をフェーズ別に一覧でき、直近のアクション状況によって色分け（青＝1週間以内にアクションあり・黄＝1か月以内・赤＝1か月以上アクションなし）することで停滞案件を視覚的に特定できます。フェーズ別の集計・転換率レポート・リードタイムの分析も、データ入力があれば自動生成されます。
例えばMazrica SalesのようなSFA/CRMでは、案件ボードでフェーズごとの滞留状況を色分け表示し、停滞案件を即座に特定できます。AIインサイト機能（Growth以上）では、案件データから進捗・リスクを提示し、案件の状況を可視化できます。このような機能はMazrica Salesに限らず、SFA/CRMカテゴリの製品が共通して提供しているものです。自社の規模・課題に合う製品を選ぶことが重要です。
ツール選定の判断軸
パイプライン管理のためにツールを選定する際には、次の4つの軸で比較することを勧めます。
- 現場の入力負荷を下げられるか モバイル対応の有無、メール・カレンダー・会議ツールとの連携によるデータ自動収集の範囲。入力が面倒なツールは形骸化します。
- フェーズ定義・移行条件を設定画面で管理できるか フェーズ変更時の必須入力項目を設定できるか、フェーズごとの確認項目をカスタマイズできるかを確認します。
- レポート・ダッシュボードがマネージャーの判断に使える粒度か フェーズ転換率・フェーズ滞留日数・担当者別の指標など、意思決定に必要な数字を自動集計できるかを確認します。
- 他ツール（MA・メール・会議ツール）との連携でデータが自動収集できるか 手入力をゼロにはできなくても、連携によって入力の手間を減らせる範囲が大きいほど定着しやすくなります。
営業パイプライン 可視化の手法とツールを組み合わせた設計の詳細については、営業パイプラインの可視化で解説しています。
パイプライン管理の運用定着：週次・月次レビューの設計
「設計して終わり」では必ず形骸化します。パイプライン管理が定着している組織とそうでない組織の最大の違いは、データを「報告」として使っているか「次の打ち手を決める議論の材料」として使っているかにあります。レビューの設計は、管理の目的をどこに置くかを組織全体に伝えるための仕組みです。
週次パイプラインレビューの設計
週次レビューの目的は、今週・今月の売上着地を確認し、アクションが必要な案件を特定することです。「先週何をしたか」を報告する場ではなく、「今週何をすべきか」を決める場として設計します。
議題は次の順序で優先します。
- 停滞案件の確認 フェーズ滞留日数が閾値（例：30日以上、または自社の平均リードタイムを大幅に超えた案件）を超えた案件を最初に扱います。放置するリスクが最も高い案件から確認します。
- クロージング間近の案件のリスク確認 今月中にクローズする予定の案件が、移行条件を満たして進んでいるかを確認します。「なんとなく今月中に決まりそう」という感触ではなく、「決裁者が承認のプロセスに入っているか」という事実で確認します。
- 新規流入案件の質評価 今週パイプラインに入った案件が、パイプライン管理に値する有効商談かを確認します。ニーズが曖昧なまま案件登録されていると、後のフェーズでのデータが歪みます。
マネージャーが時間を使うべきは、進捗報告の読み上げではなく「なぜ案件が進まないのか」の原因探索と、担当者への具体的な支援策の合意です。「次のアクションとして何をするか」を会議の終わりに決めて終わることが、レビューを形式的な報告会にしないための条件です。
月次レビューと改善サイクルの設計
月次レビューでは、週次では見えないフェーズレベルの傾向を分析します。
前月比のフェーズ転換率の変化を確認し、特定フェーズの転換率が悪化していれば原因を探します。失注理由の傾向分析では、どのフェーズでどの理由による失注が集中しているかを集計し、改善対象のフェーズと施策の優先順位を決めます。
改善施策を決める際の判断軸は3つです。
- 転換率が最も低いフェーズ ここを改善することで、下流全体の案件数が増えます。
- リードタイムが最も長いフェーズ 滞留を短縮することで、同じリードからより多くの案件を同時進行できます。
- 失注理由が集中しているフェーズ 特定の理由での失注が集中していれば、そのフェーズの活動に構造的な問題があると判断できます。
重要な原則は、「全フェーズ同時に手を入れない」ことです。複数のフェーズを同時に改善しようとすると、どの施策が効果をもたらしたかが判断できなくなります。一点集中で効果を確認してから次のフェーズへ移るというサイクルを繰り返すことが、改善の精度を上げます。
マネージャーの役割の再定義
パイプライン管理が定着しない組織の多くで、マネージャーが「数字を監視する管理者」の役割から抜け出せていないという問題があります。
数字の監視は、現場が「見られるために入力する」という行動を生みます。実態と乖離したデータが蓄積され、管理者もそのデータを信頼しなくなり、ツールが形骸化するという悪循環に入ります。
パイプライン管理を機能させているマネージャーは、レビューの中心を「ボトルネックの解消とリソース再配分」に置いています。「なぜこの案件が停滞しているか」を担当者と一緒に分析し、「どのような支援があれば前に進めるか」を考え、必要であれば同行・引き継ぎ・他部門との調整を行う、という行動が中心になります。「入力させる管理者」から「データを使って現場を助ける管理者」へのシフトが、パイプライン管理の定着に最も効果的な変化です。
パイプライン管理の失敗パターンと対策
よくある失敗の多くは、設計段階で防げます。「どういう使い方をすると形骸化するか」を設計の前提として理解しておくことが、定着への近道です。実務で繰り返し観察される失敗パターンを4つ取り上げます。
失敗パターン①：入力が目的化し形骸化する
- 原因 入力項目が多すぎる・入力したデータがマネージャーに活用されている様子がない・自分の業務に何のメリットも感じられない、という3つが重なると、現場は入力を「やらされ仕事」として認識します。
- 対策 入力項目は「フェーズ移行判断に必要な最小限」に絞ります。「あったら便利」という理由で項目を増やすと、全体の負荷が増え、重要な項目の入力も漏れ始めます。また、入力することで「自分の案件の状況が整理できる」「次に何をすべきかが見える」という設計にすることが重要です。パイプライン管理が担当者にとっての仕事の整理ツールになれば、入力は義務ではなく習慣になります。
失敗パターン②：フェーズ基準が曖昧でデータが信用されない
- 原因 フェーズ移行の判断が担当者の主観に委ねられているため、同じ状況の案件が異なるフェーズに置かれます。マネージャーもデータを信頼できなくなり、結局個別ヒアリングに頼るという元の状態に戻ります。
- 対策 「フェーズ移行条件の設計」セクションで示した客観的な完了条件を、SFAのフェーズ変更時の必須入力項目として組み込みます。条件を設定画面で管理することで、担当者が主観的にフェーズを動かしにくい構造を作ります。フェーズ基準の明文化は、一度だけでなく、運用を続ける中で実態に合わせて更新することも重要です。
失敗パターン③：パイプラインが「報告ツール」になる
- 原因 マネージャーが数字チェックのためだけにレビューを実施し、担当者が「見られるために入力する」という状態になると、入力内容が実態と乖離し始めます。マネージャーがデータを信頼しなくなり、データを使わない判断が増え、ツールが使われなくなります。
- 対策 レビューの議題を「進捗報告の取得」から「停滞の原因探索と打ち手の合意」にシフトします。会議の中で「次のアクション・担当者・期限」を決めることを必須にすることで、レビューが前向きな場に変わります。週次レビューの設計で示した議題の優先順位を、最初の数回は意識的に実施することで習慣化を促します。
失敗パターン④：フェーズ数が多すぎて管理が複雑になる
- 原因 営業活動の細かさをすべてフェーズに反映しようとすると、フェーズ数が10を超えるような設計になることがあります。担当者が「今の案件はどのフェーズか」の判断に時間がかかり、入力が止まります。
- 対策 フェーズは「顧客の意思決定の節目」に対応する数（5〜7）に絞ります。細かい活動（電話・メール・資料送付・訪問）はフェーズではなくアクション記録として管理し、フェーズは顧客の検討状態の変化だけを表すものとして設計します。「このフェーズは本当に顧客の意思決定の変化を表しているか」という問いで、既存のフェーズ設計を見直すことができます。
パイプライン管理の改善サイクル
パイプライン管理は、一度設計して終わりではありません。データをもとに継続的に改善することで初めて機能する仕組みです。最初のフェーズ設計が完璧である必要はなく、運用しながら実態に合わせて修正していくサイクルを回すことが重要です。停滞案件の早期発見と回復アクション・売上予測精度の向上という2つの実務課題を軸に、改善サイクルの設計を整理します。
停滞案件の発見と回復アクション
停滞案件を発見するための基本的な手順は、フェーズ滞留日数が閾値を超えた案件を週次でリストアップすることです。閾値は、過去の案件データから各フェーズの平均滞留日数を計算し、その目安を設定します。
停滞の主な原因は複数のパターンに分類できます。
- 顧客側の優先度低下 顧客の内部事情（予算サイクルの変更・担当者交代・別プロジェクトの優先）によって、検討が後回しになっているケース。
- 競合の介入 検討段階で競合製品との比較が始まり、顧客の意思決定が複雑になっているケース。
- 予算凍結または削減 顧客の経営状況の変化による予算の見直し。
- 社内意思決定の遅延 担当者は前向きだが、社内承認プロセスが長引いているケース。
原因のパターンによって回復アクションは異なります。優先度低下の場合は「今対応する理由」を再提示することが有効で、意思決定遅延の場合は決裁者に直接接触することが求められます。停滞案件の回復施策と、それが売上予測に与える影響の反映方法については、パイプライン 改善と売上予測の精度向上を解説したパイプラインの改善と売上予測の精度向上で詳細を解説しています。
売上予測の精度を上げるための習慣
売上予測の精度は、「受注確度」の定義が組織内で統一されているかどうかに大きく依存します。Aさんの「60%確度」とBさんの「60%確度」が指している状態が異なれば、加重平均受注予測の数字に意味がなくなります。
確度の定義を統一する実務的な方法は、フェーズ移行条件との整合性で確度を決めることです。「顧客が複数社比較検討している段階は40%、決裁者が自社製品を選択肢として明示した段階は60%、発注書の作成に着手した段階は80%」のように、フェーズや顧客の行動事実に対応させて定義します。
また、AIフォーキャスト（売上予測）機能を持つSFAを活用することで、蓄積した過去の案件データから受注確度・着地金額の予測精度を上げることができます（例えばMazrica SalesのAIフォーキャスト機能は、蓄積データから案件の進展を予測し売上着地見込みを算出します）。ただし、AIによる予測の精度も、フェーズ定義と移行条件の一貫性があってこそ高まります。データの質が予測の質を決めるという原則は変わりません。
まとめ：「型」を作り、組織全体で回せる状態にする
パイプライン管理は、フェーズを設けてツールを導入すれば完成するものではありません。「顧客の検討フローを起点としたフェーズ設計」「客観的な移行条件の明文化」「レビューを報告ではなく打ち手の合意の場にする設計」という3つが揃ったとき、初めて組織として機能します。
この記事で示した設計手順を振り返ります。
- 営業プロセスの設計は、顧客の検討フローを起点にします（詳細は営業プロセスの設計方法）。
- フェーズは5〜7に絞り、各フェーズに客観的な移行条件を定義します（詳細は営業フェーズの定義と移行条件）。
- KPIは「次の打ち手を決めるための指標」として設計し、営業生産性の方程式（商談数×受注率×単価÷工数）のどの変数に影響するかを意識します（詳細は営業パイプラインの指標設計）。
- ツールはフェーズ設計と移行条件の設計が先で、ツールはその実装手段です（詳細は営業パイプラインの可視化）。
- レビューの設計によって、データが「報告」ではなく「改善の材料」として機能します（詳細はパイプラインの改善と売上予測の精度向上）。
現在、売上予測の精度が低い・ボトルネックがどこにあるか分からない・マネージャーが個別ヒアリングで状況把握しているという課題を感じているなら、まずフェーズ定義と移行条件の見直しから着手することを勧めます。設計の見直しは大規模なツール変更なしに始められ、既存のデータ収集の質を改善する最初の一歩になります。
SFA/CRMの活用によるパイプライン管理の高度化を検討している場合は、Mazrica Salesのような案件管理・AI受注予測・停滞案件の可視化機能を持つSFA/CRMの資料を確認し、自社の課題と照らし合わせることが出発点になります。特に商談数はある程度確保できているが受注率の向上に課題を感じている場合、Mazrica SalesとMazrica Targetを組み合わせたSales Enablementパッケージのような、営業情報の整備と提案精度の向上を組み合わせる選択肢も検討に値します。
よくある質問
Q 営業プロセスの「パイプライン」と「ファネル」は何が違いますか？
パイプラインとファネル（漏斗）は似た概念ですが、視点が異なります。ファネルは主にマーケティング領域で、多くのリードが上から入り、下に進むにつれて絞り込まれていく「量の変化」を表す図です。パイプラインは営業領域で、案件が各フェーズをどのように流れているかを管理する手法です。ファネルは「どこで何人が離脱しているか」という漏れの把握に使われるのに対し、パイプラインは「現在どのフェーズに何件の案件があり、次のフェーズへ移行するために何が必要か」という個別案件の管理と流れの最適化に使われます。実務では両方の視点を組み合わせることが多く、上流はファネル指標で管理し、商談以降はパイプライン管理で運用するという形が一般的です。
Q パイプライン管理はいつから始めるべきですか？営業担当者が何人以上になったら導入を検討すべきですか？
担当者数よりも「マネージャーが個別ヒアリングなしに案件の状況を把握できなくなった時点」が導入のサインです。また担当者数に関係なく、「売上の着地が月末にならないと分からない」「特定の担当者に案件が偏っているかどうかが見えない」という状態があれば、パイプライン管理を始める価値があります。Excelから始めて規模に応じてSFAに移行する段階的なアプローチも有効です。
Q ExcelとSFAのパイプライン管理で、使い分けの決め手は何ですか？
主な判断軸は3つです。まず「リアルタイムの共有が必要か」です。マネージャーと担当者が常に同じデータを見て判断する必要がある場合、Excelの手動更新では限界があります。次に「データを分析・改善に使いたいか」です。フェーズ転換率・滞留日数・担当者別の指標を自動集計したい場合、SFAの方が運用負荷が低くなります。3つ目は「入力の継続性を担保できるか」です。SFAはモバイル対応や外部ツールとの連携により、入力の自動化・省力化が進めやすいという利点があります。試験的に始めたい・担当者が3〜5名・分析よりまず可視化を優先したいという段階ではExcelが合理的で、それ以外はSFAへの移行を検討する価値があります。
Q パイプラインのフェーズ数はいくつが適切ですか？
5〜7フェーズが運用しやすい目安です。この範囲を外れたときに生じる問題は異なります。フェーズが4以下になると、問題のある箇所を特定する粒度が不足します。8以上になると、担当者がフェーズの区別を判断するコストが上がり、入力が止まります。適切なフェーズ数を決めるには「このフェーズが終わったと客観的に判断できる事実が定義できるか」という問いを各フェーズに当てはめます。この問いに答えられないフェーズは、統合するか削除することを検討します。業種・商材・平均商談期間によって最適なフェーズ数は変わるため、まず5フェーズで始め、実際の運用データを見ながら調整するアプローチが現実的です。
Q マネージャーがパイプラインレビューで陥りやすいミスは何ですか？
最も多いのは「進捗報告を聞くだけで終わる」ことです。担当者が今週何をしたかを報告し、マネージャーが聞いてレビューが終わる形では、次のアクションが決まらないまま週が終わります。もうひとつは「数字が悪い案件を叱責する場にする」ことです。これが続くと、担当者は実態よりも楽観的な数字を入力するようになり、データが歪みます。有効なレビューは、「この案件が止まっている原因は何か」を一緒に考え、「今週誰が何をするか」を決める場です。マネージャーが支援者として機能するかどうかが、レビューの質を決めます。
Q インサイドセールスをパイプラインに含める場合、どのようにフェーズを設計しますか？
インサイドセールスとフィールドセールスが分業している組織では、パイプラインの「上流」と「下流」でフェーズの担当が変わる設計が一般的です。インサイドセールスが担当するフェーズ（リード獲得→初回接触→ニーズ確認→商談設定）と、フィールドセールスが担当するフェーズ（初回商談→提案→見積→クロージング）を、同一のパイプラインの中で連続して設計します。引き渡しの条件（どの状態になったらフィールドセールスに渡すか）を移行条件として明確に定義することが重要で、「商談設定が完了した段階で引き渡す」だけでなく「ニーズヒアリングが完了し、決裁者が初回商談に参加する意向を確認した」という顧客側のアクションを条件に含めることで、引き渡し後の商談の質が安定します。