リード数も商談数も増えているのに、受注見込みが読めない。営業会議では案件が「進んでいる」と報告される一方で、翌月には失注や停滞が増える。この状態は、営業力だけの問題ではなく、案件ステージの定義が顧客の意思決定と結び付いていないことが原因かもしれません。
結論からいうと、BtoB営業パイプラインは「初回商談」「提案書提出」といった自社の行動ではなく、顧客側で確認できた課題・関係者・評価条件・合意を基準に設計します。これにより、売上予測の精度だけでなく、マーケティング、インサイドセールス、営業が次に何をすべきかも揃えやすくなります。
この記事では、BtoBの案件ステージを顧客起点で定義し、CRMやSFAで運用可能な形に落とし込む7ステップを解説します。
結論：パイプラインは「顧客の旅」そのものではなく、営業判断のための運用モデル
パイプラインとカスタマージャーニーは似ていますが、同じものではありません。カスタマージャーニーは、顧客が課題を認識し、情報を集め、社内で比較・調整し、導入後に利用するまでの実態を捉えるものです。一方のパイプラインは、売り手側が案件の優先順位、見込み、次の行動を管理するための運用モデルです。
BtoBの購買は、複数の関係者が異なる目的で関わり、購入前だけでなく導入・利用段階ともつながります。そのため、一直線の漏斗として顧客の行動を決めつけるのではなく、顧客の意思決定に関する証拠をそろえて案件を管理する必要があります。BtoBカスタマージャーニー研究でも、購買・利用に関わる複数人の目標や接点、既存の取引関係を含めて捉える重要性が示されています。［1］
| 見る対象 | 顧客側で起きていること | 自社が管理すること |
|---|---|---|
| 顧客の検討 | 課題の優先順位付け、関係者の調整、比較、稟議、導入準備 | カスタマージャーニー、購買委員会、必要な判断材料 |
| 営業パイプライン | 顧客の意思決定がどこまで確かになったか | 案件ステージ、金額、受注見込み、滞留、次回合意 |
| 行動シグナル | 資料閲覧、ウェビナー参加、メール反応、サイト再訪 | 優先順位付け、ナーチャリング、仮説の更新 |
重要なのは、行動シグナルだけで案件ステージを進めないことです。たとえば、同じ企業から資料ダウンロードが3件あっても、顧客が導入課題を認識しているとは限りません。逆に、閲覧履歴は少なくても、現場責任者と決裁者が参加する具体的な打ち合わせが決まっているなら、優先すべき案件である可能性があります。
マーケティングの反応を見る指標と、営業案件の進捗を見る指標を混ぜないことが、BtoBパイプライン設計の出発点です。
BtoB営業パイプラインを設計する7ステップ
ステップ1：受注として管理したい単位を決める
最初に決めるのは、何を1件の案件として扱うかです。ここが曖昧だと、案件数、受注率、営業期間のすべてが比較できなくなります。
たとえば、同じ会社でも「新規導入」「追加導入」「更新」「別部門展開」は、検討の起点も意思決定者も異なります。これらを1本のパイプラインに混在させると、受注率や滞留日数の平均が意味を持ちにくくなります。
- 新規顧客の初回導入
- 既存顧客へのアップセル・クロスセル
- 更新・契約更改
- 入札・コンペ型の大型案件
まずは、購買プロセスと収益構造が大きく異なるものだけを分けましょう。細かく分けすぎると比較できる案件数が減り、運用負荷も上がります。
ステップ2：受注から逆算して5〜7個程度の案件ステージを置く
ステージ数に唯一の正解はありません。ただし、少なすぎるとボトルネックが見えず、多すぎると入力が形骸化します。立ち上げ時は、受注までの重要な意思決定を区別できる5〜7段階程度から始めると扱いやすいでしょう。
ステージ名は、社内の作業ではなく顧客の状態が想像できる言葉にします。「初回訪問済み」より「課題・対象範囲を確認済み」、「見積提出済み」より「提案条件を評価中」のほうが、案件の確度を判断しやすくなります。
CRMでは取引ステージごとに確度や必須項目を設定できますが、設定機能を先に触るのではなく、先に自社の判断基準を決めることが重要です。［3］
ステップ3：各ステージで顧客が終えるべき「意思決定タスク」を書き出す
案件ステージは、自社が何をしたかではなく、顧客が何を判断できる状態になったかで定義します。そのために、各段階で顧客が終えるべきタスクを書き出します。
たとえば、提案前の段階であれば、単にヒアリングが終わった状態では不十分です。課題の優先度、対象部署、導入時期の仮説、次回の検討アクションについて、顧客と最低限の認識がそろっているかを確認します。
BtoBでは、担当者だけを見て判断すると誤ります。利用部門、現場責任者、情報システム、購買、決裁者など、誰がどの判断に関与するのかを分けて整理してください。関係者の整理方法は、BtoBの購買委員会マップを作る方法も参考になります。
ステップ4：ステージ定義書を「証拠・必須情報・責任」で作る
ステージ名だけをCRMに登録しても、営業担当者ごとに解釈が分かれます。そこで、各ステージに「何をもって進んだと判断するか」を定義書にします。特に重要なのは、主観的な表現を避け、確認できる証拠に変換することです。
| 項目 | 定義する内容 | 記載例 |
|---|---|---|
| 顧客の状態 | 顧客がどの判断まで進めたか | 対象課題と対象部門を特定し、解決の検討に合意している |
| 移行条件 | 次のステージへ進める客観的な根拠 | 顧客との会話で、現状課題・対象範囲・次回検討日を確認した |
| 必須情報 | 案件レビューに必要な項目 | 想定金額、導入時期、利用部門、主要関係者、競合状況 |
| 担当・SLA | 誰が何日以内に何をするか | 営業が次回アクションを登録し、必要に応じてマーケティングへ支援依頼する |
| 差し戻し・終了条件 | 案件として維持しない条件 | 検討停止が明確、失注、または育成対象へ戻す判断ができた |
「温度感が高い」「前向き」といった言葉は、補足情報にはなっても移行条件にはなりません。「決裁者が誰か分かった」「評価項目を顧客と確認した」「見積条件について返信を得た」のように、第三者が記録を見ても判定できる表現に直しましょう。
ステップ5：シグナル、案件、受注見込みを3階層で管理する
中級者以上のBtoBマーケティングで特に重要なのは、個人の反応、企業アカウント、案件を同じものとして扱わないことです。
- 個人レベル：メールクリック、資料閲覧、イベント参加など。関心の変化を捉える。
- アカウントレベル：対象企業内で複数部門・複数人の関与があるか。購買委員会のカバー状況を捉える。
- 案件レベル：課題、優先度、条件、関係者、次の合意がそろっているか。営業資源と売上予測を管理する。
個人のスコアが高くても、企業としての案件が生まれているとは限りません。反対に、営業が把握している重要案件にデジタル接点が少ないこともあります。この3階層を分けることで、マーケティングは「誰を育成するか」、営業は「どの案件を前へ進めるか」をそれぞれ判断できます。
MQLとSQLの受け渡し基準は、この設計の一部です。個人の属性・行動・営業確認を分けた設計については、MQLとSQLの違いと営業へ渡す基準で詳しく解説しています。
ステップ6：マーケティング・営業・インサイドセールスの引き渡しを設計する
パイプラインが止まる原因は、案件定義よりも「誰が次に動くか」が曖昧なことにあります。そこで、ステージごとにオーナーと支援内容を決めます。
たとえば、まだ案件化していない企業にはマーケティングが比較資料や事例を届け、課題確認の段階ではインサイドセールスがヒアリングを行い、評価条件や提案範囲が固まった段階から営業が主担当になる、といった分担です。大切なのは部門で機械的に分けることではなく、顧客の次の判断を進めるのに最も適した役割を置くことです。
ファネルごとにKPIを設け、営業活動と連動させる考え方は、マーケティングの量だけでなく商談・受注につながる質を見るうえで有効です。［2］
ステップ7：転換率だけでなく「滞留」と「証拠の欠落」をレビューする
パイプラインレビューで見るべき数字は、案件数や金額だけではありません。次の4つを並べると、改善論点を見つけやすくなります。
| 見る指標 | 分かること | 悪化したときに確認すること |
|---|---|---|
| ステージ別案件数・金額 | 案件の偏りと将来の供給量 | 入口不足か、特定ステージへの滞留か |
| ステージ間転換率 | 次の意思決定へ進めているか | 移行条件、提案内容、対象企業の適合性 |
| ステージ別滞留日数 | 意思決定が止まっている場所 | 次回アクション、関係者不足、稟議・予算上の障壁 |
| 必須情報の充足率 | 予測の根拠がそろっているか | 導入時期、金額、関係者、失注理由、競合情報の未入力 |
特に見落とされやすいのが、滞留日数です。転換率が高く見えても、案件が長期間止まっていれば、当月・当四半期の売上計画にはつながりません。ステージごとの平均だけでなく、中央値や「次回アクション未設定の案件数」も確認すると、少数の大型案件に数字が引っ張られにくくなります。
なお、受注見込みは、設定済みの確度を機械的に合計するだけでは不十分です。案件タイプ、単価帯、獲得チャネル、営業期間などで受注率が異なる場合は、完了案件の実績を比較しながら確度を見直してください。KGIから必要な件数や転換率へ落とし込む方法は、WebマーケティングのKPI設計方法もあわせて確認すると整理しやすくなります。
顧客起点で設計する案件ステージ例
ここでは、新規顧客への無形サービス・SaaS・業務支援などを想定した例を示します。自社の商材、契約形態、購買プロセスに合わせて名称や条件を調整してください。
| ステージ | 顧客の状態 | 次へ進める証拠 |
|---|---|---|
| 案件候補 | 対象企業との接点があり、適合仮説がある | 担当者との対話機会、または確認すべき仮説が設定されている |
| 課題確認 | 課題・対象範囲・現状の影響を確認している | 顧客が検討すべき課題と対象部署を認め、次回の確認事項に合意している |
| 案件化 | 解決プロジェクトとして検討する意思がある | 想定時期、関係者、評価の進め方のうち重要事項を確認できている |
| 提案評価 | 自社案を比較・評価している | 顧客の評価基準に沿った提案内容を共有し、確認・回答の場が設定されている |
| 条件合意 | 契約・予算・稟議に必要な論点を調整している | 金額、範囲、開始時期、契約上の論点について具体的な合意形成が進んでいる |
| 受注・失注・育成戻し | 今回の案件として結論が出ている | 契約締結、失注理由の確認、または再検討条件を記録している |
この例でのポイントは、「提案書を送った」だけでは提案評価へ進めないことです。顧客が何を評価し、誰がその評価に関わり、いつ確認するのかまで分かって、初めて案件の前進を判断できます。
パイプライン設計で起きやすい5つの失敗
1. 営業担当者の行動をステージにしている
「アポ取得」「初回訪問」「見積送付」は、営業側の実施記録です。顧客の意思決定が前に進んだことを保証しません。活動履歴やタスクとして記録し、案件ステージとは分けましょう。
2. 提案提出で確度を上げてしまう
提案書を提出した案件は目立つため、実態以上に確度を高く見積もりがちです。しかし、顧客の評価基準、比較対象、決裁者、予算のいずれかが不明なら、提案は単なる情報提供で終わることもあります。提案提出後に「何を評価し、次に誰が判断するか」を確認する設計が必要です。
3. 失注と育成戻しを一括りにしている
予算消失や競合決定は失注ですが、優先度が下がっただけ、導入時期が先送りになっただけの企業は、将来の再検討候補です。失注理由と再開条件を分けて記録しないと、営業が追うべき案件とマーケティングが育成すべき企業が混ざります。
4. 新規・更新・大型案件を同じ確度で予測している
既存顧客の更新と新規の大型導入では、関係性、検討期間、失注要因が異なります。少なくとも分析時には案件タイプを分け、同じステージ名でも受注率や滞留日数を比較できる状態にしてください。
5. 数字のためにステージを動かしている
月末にパイプラインを良く見せるため、根拠の弱いまま案件を進めると、翌月以降の予測が崩れます。これを防ぐには、月次で完了案件と進行案件を数件ずつ抽出し、「記録された証拠だけでステージ判定に合意できるか」を営業責任者と確認するレビューが有効です。
一歩深く：改善対象は「案件数」ではなく、案件の進む条件である
パイプラインのボトルネックを見つける際、「案件数が足りない」と結論づけるのは早すぎます。案件数が多くても、決裁者が不明、比較基準が不明、次回アクションがない案件ばかりなら、営業資源を分散させるだけです。
改善は、次の2つのループに分けて考えると整理しやすくなります。
- 案件内のループ：個別案件で、顧客の判断を一つ進める。例：利用部門の課題確認から、決裁者を交えた評価条件の合意へ進める。
- ポートフォリオのループ：案件群として、量・転換率・滞留・構成を見直す。例：特定チャネル由来の案件だけが提案評価で止まっていないかを確認する。
前者は営業・インサイドセールスの実行課題であり、後者は戦略・オペレーションの課題です。両者を分けないと、「リードを増やす」「商談を増やす」といった抽象的な打ち手に流れやすくなります。
まずは直近の受注・失注案件を10件程度並べ、各ステージで本当に確認できていた証拠、長く止まった理由、受注に至った際にそろっていた関係者情報を確認してください。完璧なCRM設計よりも、実際の案件から定義を検証し、小さく更新するほうが定着します。
まとめ：案件ステージは、顧客との合意を残すためにある
BtoB営業パイプラインの目的は、案件をきれいに並べることではありません。顧客の意思決定がどこまで進んでいるかを共通言語にし、限られたマーケティング・営業資源を優先配分することです。
- パイプラインとカスタマージャーニー、行動シグナルを混同しない
- 案件ステージは営業の行動ではなく、顧客の意思決定で定義する
- 移行条件は「前向き」ではなく、確認可能な証拠に変換する
- 個人・アカウント・案件の3階層でデータを管理する
- 転換率に加え、滞留日数、次回アクション、必須情報の充足率を見る
- 完了案件を使って定義と確度を定期的に見直す
最初からすべての項目をそろえる必要はありません。まずは、受注に最も影響する案件タイプを一つ選び、ステージごとの「顧客の状態」と「移行の証拠」を1枚にまとめるところから始めましょう。
