セールスファネル（営業ファネル）とは？営業パイプラインとの違いと商談ステージ設計

セールスファネルという言葉は、認知から購入までを指す場合もあれば、営業が受け入れた案件から受注までを指す場合もあります。範囲を決めないまま部門ごとに別の意味で使うと、マーケティングは「リード数」、営業は「案件金額」、経営は「売上予測」を見て、同じファネルを話しているつもりでも数字が一致しません。

結論：セールスファネル（営業ファネル）は、一般に見込み客が認知・接点から購入・受注へ進み、途中で離脱または次段階へ転換する流れを表します。本記事では移行率を再現できるよう、各段階へ入った見込み客や商談の通過数を期間単位で集計します。営業パイプラインは、現在進行中の個別案件について、金額、受注予定日、次アクションを営業側が管理する見方です。BtoBで実装するときは、ファネルの入口と測定単位を決め、営業受入後の商談ステージを「営業が行った活動」ではなく「顧客と確認できた退出条件」で定義します。

---

本記事のポイント

1. 買い手の進行・離脱を表すセールスファネルは、実装時に一定期間の通過数を集計し、現在の個別案件を管理する営業パイプラインと分けます。
2. 商談ステージは「提案した」などの活動名ではなく、課題、要件、決裁、契約条件など次へ進める証拠で定義します。
3. CRMではステージ、次アクション、受注予定日、予測カテゴリ、失注理由を分け、週次の案件判断と月次のファネル分析を使い分けます。

---

セールスファネルとは｜通過数と減少を見る「フロー」

セールスファネルは、見込み客が接点を持ち、検討し、商談になり、受注または購入へ進む過程を段階に分け、各段階の件数と移行を捉える考え方です。入口では対象が多く、条件が合わない、検討をやめる、競合を選ぶなどの理由で次第に件数が減るため、漏斗の形で表現されます。

ただし、用語の範囲は統一されていません。Zoho CRMのセールスファネルの公式解説は認知から購入までを扱い、Salesforceの営業パイプラインの公式解説は進行中の商談、金額、成約見込みなどの管理に焦点を置いています。製品や組織によって呼び方が違うからこそ、自社では対象、入口、出口、期間を定義表に残す必要があります。

営業ファネル・売上ファネル・パイプライン・営業プロセスを分ける

営業ファネルや売上ファネルは、実務ではセールスファネルとほぼ同じ意味で使われることがあります。一方、営業パイプライン、営業プロセス、売上予測は目的が違います。次の四つを一つの図や項目へ押し込まず、連携する別の見方として扱うと混乱を減らせます。

見方	管理単位	答える問い	主な情報
セールスファネル	一定期間に各段階へ入った見込み客・企業・案件の集計	どこで次段階への移行が止まっているか	流入数、移行数、移行率、受注率、所要期間
営業パイプライン	現在進行中の個別案件	どの案件に、誰が、いつ、何をするか	担当者、金額、ステージ、次アクション、受注予定日
営業プロセス	営業担当が再現する標準手順	案件を前へ進めるために何を確認・実行するか	ヒアリング、提案、社内審査、契約などの手順と役割
売上予測	特定期間に着地すると見込む案件・金額	いつ、いくら受注する見通しか	予測カテゴリ、金額、受注予定日、延期、判断根拠

移行率を管理する本記事の実装では、ファネルを「一定期間に何件が次へ進んだか」という流れ、パイプラインを「今この瞬間に何件がどこにあるか」という残高として分けます。現在の案件一覧で各ステージの件数を数えても、移行率にはなりません。例えば、提案中の案件が多いのは、流入が増えた結果か、提案後に滞留している結果か、一覧だけでは判別できないためです。

本記事では広い定義を踏まえたうえで、営業が受け入れた時点または案件を作成した時点から、受注・失注・再育成へ出るまでを実装範囲にします。

認知、コンテンツ、複数の購買関与者と稟議を含む全体像は、BtoBファネルの設計で確認できます。

MQLの判定と営業引き渡しは、リードスコアリングの設計で分けて確認できます。

BtoBでは測定単位と開始地点を先に決める

段階名を決める前に、何を一件として数えるかを固定します。個人を単位にすると、同じ企業の三人が反応しただけで三件に見えます。企業だけを単位にすると、同じ会社で別部門が別の商材を検討している二つの案件を一件へまとめてしまいます。営業受入後の管理では、原則として「企業×購買テーマまたは商材×検討時期」で分けた案件を単位にすると、金額、担当、予定日、結果を対応させやすくなります。

定義項目	決めること	曖昧な場合に起きること
測定単位	人、企業、案件のどれを一件とするか	同一企業の複数人や複数商材を重複・混同する
開始地点	SAL、SQL、初回商談、案件作成のどこから数えるか	部門や月によって分母が変わり、移行率を比較できない
終了地点	受注、失注、対象外、保留、再育成をどう分けるか	追う予定のない案件が残り、パイプライン金額が膨らむ
集計期間	案件の作成月、各段階への入場月、結果月のどれで見るか	新規案件と長期案件を混ぜ、最近の施策を過小評価する
責任者	定義、入力、レビュー、変更承認を誰が持つか	担当者ごとにステージの意味が変わる

入口は一つに固定し、前工程との受け渡しを別に測る

例えば、マーケティングがMQLとした件数を入口にすると、営業が未確認のリードまで営業ファネルへ入ります。営業が受け入れたSALを入口にすると、マーケティングから営業への受入率はファネル外の連携KPIになります。案件作成を入口にすると、商談前の初回対応は別工程です。どれが正しいかではなく、同じ定義を継続し、前工程との受け渡しを欠落させないことが重要です。

定義変更が必要な場合は、変更日、旧定義、新定義、対象範囲を残します。過去データを一律に新定義へ読み替えられないなら、変更前後を同じグラフで単純比較しません。件数が改善したように見えても、入口を狭めただけということがあるためです。

同一企業の別案件を無理に一つへまとめない

同じ企業でも、対象部門、課題、予算、時期、商材が異なれば、進み方と結論が違います。会社レコードは共通でも、案件は分けて関連付けます。反対に、同じ検討を担当者ごとに別案件へ分けると金額が重複します。案件を新規作成する条件と、既存案件へ担当者を追加する条件を決めてください。

商談ステージは「確認できた退出条件」で設計する

「初回商談」「デモ実施」「提案書送付」は営業が行った活動です。活動を完了しても、顧客の課題、判断基準、決裁経路、時期が不明なら案件は前へ進んでいません。商談ステージは、次の判断へ進める顧客側の事実や合意を退出条件として定義します。

Microsoft Dynamics 365のビジネスプロセスフローの公式説明は、各段階で収集する情報や必要な手順を定義する考え方を示しています。HubSpotのパイプライン設定の公式説明にも、ステージごとに表示・必須とするプロパティを設定する方法があります。これらは製品固有の機能ですが、「次へ進むために必要な証拠を段階ごとに決める」という設計の参考になります。

ステージ例	この段階で確かめること	段階を確定・退出する証拠	進めない場合
案件発生	営業が追うべき課題・テーマが存在するか	対象企業、課題仮説、担当者、次回確認日がある	情報不足は初回確認、対象外は理由を付けて終了
適格性確認	課題、期待成果、対象範囲、検討時期が実在するか	顧客と課題・成果・時期を確認し、検討関係者を把握した	時期未定は保留期限を置き、育成へ戻す
提案・合意	要件、成功条件、提案範囲、比較軸が合っているか	顧客が提案範囲と判断基準を確認し、次の意思決定日が決まった	要件の未確認箇所と担当・期限を残す
契約判断	決裁、購買、法務、セキュリティ、契約条件に未解決事項があるか	受注は契約書署名・発注書受領などの成立証拠、失注は顧客の不採用・延期決定または追跡終了判断がある	条件差し戻しは前段へ戻し、変更理由を残す
終了（受注／失注）	契約・発注が成立したか、追跡を終了するか	受注金額・日付、または失注・対象外・見送りの理由と確定日が記録された	再検討の可能性がある場合も、再確認日を置いて一度閉じる

この五段階は例であり、最適な段階数ではありません。隣り合う段階で退出条件、責任者、必要な対応が同じなら統合できます。反対に、セキュリティ審査と契約交渉で担当部門や滞留原因が異なるなら分ける価値があります。段階を増やす目的は管理画面を細かくすることではなく、次に誰が何を判断するかを変えることです。

飛ばし・後戻り・保留・失注のルールも同時に決める

• ステージの飛ばし：途中の退出証拠をすでに確認できる場合だけ認め、飛ばした理由と証拠を残します。
• 前段階への戻り：要件変更や決裁者変更で証拠が無効になった場合に戻し、変更前の履歴を消しません。
• 保留：「いつか検討」を進行中に残さず、次回確認日と戻し先を置きます。期限がなければ終了候補です。
• 失注・見送り：競合敗退、予算、優先度、要件不一致、連絡不能、意思決定なしを分けます。「その他」だけに集約しません。
• 再開：同じ検討が再開した場合に旧案件を開き直すか、新案件を作って旧案件と関連付けるかを統一します。

「停滞中」を新しいステージにすると、どの実質段階で止まったのかが分からなくなります。停滞は、現在ステージへの入場日、最終活動日、次アクション期限などから判定する状態として持ち、商談ステージとは分けます。

CRMには現在地・次アクション・予測を別項目で残す

全項目を常時必須にすると、更新が止まります。案件を識別し、次の営業行動を決め、集計を再現するための共通項目と、ステージを出る時だけ必要な証拠を分けます。SalesforceのPipeline Inspectionの公式項目でも、所有者、ステージ、金額、受注予定日、予測カテゴリ、次のステップ、最近の活動などが案件点検に使われます。以下はその考え方を踏まえた自社設計の最小例であり、全製品共通の必須仕様ではありません。

情報群	最小項目の例	使う判断	更新時点
識別	案件ID、企業、購買テーマ・商材、担当者	重複を避け、責任者を決める	案件作成時
現在地	ステージ、ステージ入場日時、変更理由	どこで何日止まっているか	ステージ変更時
次の行動	次アクション、期限、相手、実行責任者	案件を前へ進める具体的な約束があるか	顧客接点後
案件規模	金額、数量・契約期間、受注予定日	優先順位と期間別見通しを確認する	根拠が変わった時
退出証拠	課題、期待成果、要件、決裁経路、未解決条件	次段階へ進めてよいか	該当ステージを出る前
予測	予測カテゴリ、判断根拠、マネージャー調整	期内に着地する見通しか	レビュー前と重要変更時
結果	受注・失注日、金額、失注・見送り理由、再確認日	結果分析と再育成を行う	案件終了時

AIによる要約や候補値を使う場合も、CRMの確定値を自動で上書きせず、提案値、確定者、確定日時を分けると復旧と監査がしやすくなります。記録の正本とAIの判断支援を分ける設計は、AI CRMの実務設計で詳しく整理しています。

ステージ確度と売上予測を同一視しない

ステージごとに一律の確度を設定し、金額を掛けて加重パイプラインを出す方法は、全体の傾向を見る初期値には使えます。しかし、同じ提案ステージでも、決裁者の合意、契約期限、競合状況、未解決条件は案件ごとに違います。ステージ確度を、その案件が受注する客観的な確率だと扱うべきではありません。

Salesforceの商談項目の公式説明ではステージと確率が関連付けられ、操作や権限により確率を上書きできます。Microsoft Dynamics 365の売上予測の公式説明も、Pipeline、Best Case、Committed、Won、Lostなどの予測カテゴリを区別しています。製品ごとに名称や挙動は異なりますが、工程の現在地はステージ、期内着地の見通しは予測カテゴリとして別軸にする考え方が有効です。

移行率・滞留・失注・予測を、週次と月次で分けて見る

ファネルを改善するには、現在の案件一覧と、一定期間に起きた移行を分けて集計します。週次では個別案件を前へ進める判断、月次ではステージ定義や営業プロセスを直す分析を行います。すべての案件を毎回読み上げるのではなく、証拠不足、期限超過、後戻り、予定日変更などの例外を先に抽出します。

指標	見方	読み違えを防ぐ条件	主な対応
ステージ移行率	ある段階へ入った案件のうち、観測期間内に次へ進んだ割合	入口日と観測期限をそろえ、最近の未完了案件を混ぜない	退出条件、担当、必要資料、顧客確認を見直す
ステージ滞留	入場から退出までの日数の中央値や分布	商材、案件規模、結果別に分け、普遍的な日数を借りない	期限超過の原因と次アクションを確認する
受注率	同じ入口定義の案件のうち受注した割合	分母に対象外や重複案件を含めるか固定する	案件化条件、提案適合、合意形成を見直す
失注・見送り理由	終了理由を選択肢と補足で集計する	競合敗退と意思決定なしを分け、「その他」を定期監査する	商材、営業手順、対象企業、再育成を分けて改善する
予定日の延期	受注予定日が次の期間へ移った回数・金額	変更前の予定日と理由を履歴で保持する	予測カテゴリと未解決条件を更新する
予測差	締め日時点の予測金額と実績の差	後から書き換えた最新値ではなく、締め時点のスナップショットを使う	カテゴリ判断、金額、予定日、除外ルールを校正する

滞留日数の「正解」を業界平均から借りるのは危険です。商材価格、契約期間、法務・セキュリティ審査、顧客規模で必要日数が変わります。まず自社の受注案件と失注案件を、商材・規模・ステージ別に比較し、中央値だけでなく長い側の分布も見ます。滞留だけで自動失注にせず、次アクションがない、期限を過ぎた、顧客合意が失効したなど複数の事実で判断してください。

週次レビューは「報告」ではなく、次の判断を確定する

1. データの鮮度：ステージ、金額、予定日、次アクションに欠損・期限超過がないか。
2. 退出証拠：現在ステージに留める根拠と、次へ進めるために不足する証拠は何か。
3. 次アクション：誰が、誰に、何を、いつまでに行うか。顧客との約束があるか。
4. 終了・戻し：追跡を続ける、前段へ戻す、再育成へ渡す、失注として閉じるのどれか。
5. 予測：期内着地の根拠、未解決条件、前週からの金額・予定日・カテゴリ変更は何か。

案件衛生の異常検知、会議前の論点整理、売上予測へAIを使う場合も、先にステージ、退出条件、項目、集計方法を整えます。元となる案件状態と履歴が曖昧なままでは、AIが示す停滞候補や予測差を人が検証できません。

月次分析では「案件」ではなく「仕組み」を直す

月次では、同じ入口期間の案件群を追うコホートと、各段階へ入った案件の移行を見ます。特定担当者の失敗を探すのではなく、退出条件が曖昧、特定ステージで必要情報が集まらない、失注理由が選べない、受注予定日が月末に偏るといった構造を直します。定義や必須項目を毎週変えると比較不能になるため、例外を記録し、変更は版と適用日を決めて行います。

30日で既存CRMへ最小実装し、例外ルールを試す

最初からCRMを全面改修する必要はありません。対象商材または営業チームを一つに絞り、現在の案件で定義を試します。スプレッドシートで試行する場合は、列・確度・週次レビューを具体化した営業案件管理テンプレートの設計を参照できます。本記事ではツールに依存しない実装順を示します。

期間	実施内容	成果物	完了条件
1週目	既存ステージ、案件数、履歴、失注理由、会議の使い方を棚卸しする	現行フロー、データ欠損、重複定義の一覧	測定単位、入口、出口、対象期間を一文で説明できる
2週目	受注・失注案件を使い、各ステージの退出証拠と例外を決める	ステージ定義表、飛ばし・後戻り・保留・再開ルール	複数担当者が同じ案件をほぼ同じ段階に判定できる
3週目	CRM項目、履歴、入力権限、レポートを設定し、進行中案件を整理する	項目辞書、変更履歴、例外一覧、試験レポート	現在地、次アクション、予定日、終了理由を再現できる
4週目	週次レビューと月次集計を試し、入力負荷と判断差を修正する	会議アジェンダ、指標定義、変更版、運用責任者	案件判断とファネル分析を分けて継続できる

実装前に確認する七つの問い

• ファネルの一件は、人、企業、案件のどれか。
• 入口と出口を、日付を含めて同じ条件で再計算できるか。
• 各ステージの退出条件は、営業活動ではなく確認できる証拠になっているか。
• ステージ、次アクション、受注予定日、予測カテゴリを別項目で持っているか。
• 飛ばし、後戻り、保留、失注、再開で履歴が消えないか。
• 週次の個別案件判断と、月次の移行率・所要期間分析を分けているか。
• 定義変更の責任者、適用日、旧版との比較方法が決まっているか。

導入後に営業が更新しない場合、最初に項目を増やすべきではありません。会議で使わない項目、同じ情報の重複入力、営業が確認できない情報を外し、次の判断に必要な項目だけを残します。入力の目的が上司への報告だけなら後回しになります。次アクションの明確化、支援依頼、失注の再発防止など、担当者本人が使う場面へ接続してください。

よくある質問

セールスファネルと営業パイプラインの違いは何ですか？

セールスファネルは、一般に見込み客が認知・接点から購入・受注へ進み、離脱または転換する流れを表します。移行率を分析するときは、一定期間に各段階を通過した件数として集計します。営業パイプラインは、現在進行中の個別案件について、金額、ステージ、受注予定日、次アクションを営業側が管理する見方です。ファネルでボトルネックを見つけ、パイプラインで対象案件の次の行動を決めます。

商談ステージはいくつに分けるべきですか？

固定の最適数はありません。隣り合う段階で退出条件、責任者、必要な対応が同じなら統合し、判断や担当が変わるなら分けます。名称の細かさではなく、複数の営業担当が同じ証拠を見て同じ段階を選べるかで確認してください。

ステージごとの確度をそのまま売上予測に使えますか？

集計の初期値には使えますが、案件固有の受注確率や期内着地を確定する値ではありません。同じステージでも未解決条件や意思決定日は異なります。工程の現在地を表すステージと、期内見通しを表す予測カテゴリを分け、金額、受注予定日、変更履歴、マネージャー判断を合わせて確認します。

失注・保留・前ステージへの戻りはどう記録しますか？

失注は理由と確定日を残して閉じ、意思決定なしは競合敗退と分けます。保留は無期限にせず、再確認日と戻し先を置きます。要件や決裁者の変更で退出証拠が無効になった場合は前段階へ戻し、変更前のステージ履歴と理由を消さないようにします。

関連ページと関連記事

• HubSpotで案件ステージ・活動履歴・営業会議を設計する

営業ステージとCRM運用を一枚に整理する

案件ステージが担当者ごとに違う、受注予定日が月末へ寄る、次アクションのない案件が残る場合は、ツールを増やす前に、入口、退出条件、必須項目、会議の判断順をそろえる必要があります。現在の商談データと営業・マーケティングの受け渡しを確認し、どの定義と運用から直すかを整理できます。

BtoBの営業・マーケティング連携支援を見る