レベニューファネルステージ: リードから拡大までの全ライフサイクルマップ

著者: Tracy N · 更新日: 2026年6月9日

レベニューファネルステージは、人物、アカウント、案件、顧客がレベニューシステムの中をどう進んでいくかを定義するものです。

営業パイプラインは、そのマップのほんの一部にすぎません。RevOpsには、リード獲得、クオリフィケーション、セールス承認、案件作成、クローズドウォン、オンボーディング、更新、拡大までを含む完全なライフサイクルが必要です。

Forresterのレベニューオペレーションズ責任範囲モデルは、RevOpsを営業レポートだけでなく商業エンジン全体として捉えている点で参考になります。McKinseyのB2B成長に関する調査も、購買行動と成長モーションが複雑化するなかで、連携した商業システムがなぜ必要かを裏付けています。

ファネルステージマップは、そのシステムのための運用言語です。

押さえておくべき運用の事実

• レベニューファネルステージは、需要、クオリフィケーション、案件、顧客オンボーディング、更新、拡大までの全ライフサイクルをカバーすべきです。
• ステージを追加すべきなのは、それが所有権、必要なアクション、レポート、顧客の状態、あるいは経営判断を変える場合だけです。
• すべてのステージには、参入基準、卒業基準、所有者、想定滞留期間、必須データ、例外時の対応経路が必要です。
• ステージ名そのものよりも根拠が重要です。あるレコードがそのステージに本当に属しているかをマネージャーが点検できて初めて、そのステージは意味を持ちます。

実践的なステージマップ

すべてのステージには、参入基準、卒業基準、所有者、必須フィールド、SLAが必要です。それがなければ、ステージは単なるラベルにすぎません。

ライフサイクルステージが重要な理由

ライフサイクルステージは単なるCRMのステータスではありません。誰がそのレコードを所有するのか、次に何をすべきか、そしてリーダーがどの指標を信頼できるのかを定義するものです。

ライフサイクルステージが弱いと:

• マーケティングと営業がリードの質について言い争う。
• SDRがどのレコードに取り組むべきか分からない。
• 営業が早すぎる段階で案件を作成してしまう。
• 予測レポートに根拠の薄い案件が含まれる。
• CSが成果の文脈なしに顧客を引き継がれる。
• 財務がファネルの前提を収益プランニングに結びつけられない。

ライフサイクルステージが明確であれば、各チームはそのレコードが何を意味し、次に何をすべきかを理解できます。

ステージ設計の原則

マップを設計する際は、次の原則を使いましょう。

目標はあらゆる細部をモデル化することではありません。目標は、意思決定を支えるステージを作ることです。

ステージを追加・削除すべきタイミング

チームがより詳細なレポートを望んでいるという理由だけでステージを追加しないでください。ビジネスが異なる運用上のアクションを必要とするときにステージを追加しましょう。

ステージを追加する良い理由:

• チーム間で所有権が変わる。
• SLAや対応時間の期待値が変わる。
• 必須データが変わる。
• 予測やプランニングの扱いが変わる。
• 顧客の状態が変わる。
• マネージャーの点検に、明確なチェックポイントが必要になる。

弱い理由:

• チームがもっと多くの活動ラベルを見たがっている。
• CRMのテンプレートにそのステージが含まれている。
• リーダーがワークフローの変更を伴わないダッシュボードの切り口だけを望んでいる。
• 担当者が所有権に影響しない非公式な言葉を使っている。

ステージは削除もされるべきです。あるステージがもはやアクションを変えず、混乱を生み、データの質が低いなら、よりシンプルなモデルに統合しましょう。マネージャーが徹底できるシンプルなライフサイクルの方が、誰も信頼していない詳細なライフサイクルより優れています。

ステージ所有権モデル

複数のチームが関与する場合でも、各ステージには一人の主たる運用所有者を置くべきです。

この所有者モデルにより、ライフサイクルステージが行動を伴わないラベルになることを防げます。誰も移動を所有していなければ、放置されたレコードは放置されたままです。誰も基準を所有していなければ、ステージの変更が主観的になります。誰もレポートへの影響を所有していなければ、ダッシュボードはずれていきます。

RevOpsは、ステージマップとともに所有者モデルを公開すべきです。マネージャーは、どのチームが動くのか、どのフィールドが重要なのか、そしてレコードが標準フローに合わない場合にどの例外経路が適用されるのかを知っておくべきです。

リードと需要のステージ

リードステージは、未加工の需要とクオリファイ済みの需要を分けるべきです。

一般的なステージ:

最も重要なルールは、MQLが「マーケティングが気に入ったリード」を意味してはいけないということです。それは、そのレコードが営業レビューのための合意されたしきい値を満たしていることを意味すべきです。

より詳しい引き継ぎ設計については、リードから案件へのプロセスを参照してください。

営業パイプラインステージ

案件ステージは、営業担当者の活動ではなく、購買の進捗を描くべきです。

弱いステージの例:

• コンタクト済み
• フォローアップ
• デモ実施済み
• 提案送付済み

これらは有用な活動かもしれませんが、必ずしも案件の質を証明するものではありません。

より強いステージは根拠を使います。

企業ごとにステージの名称は異なるでしょう。重要なのは、移動に根拠が必要であるということです。

顧客ライフサイクルステージ

継続収益型の企業は、クローズドウォン以降のステージも必要とします。

一般的な顧客ステージ:

これは、レベニューステージをRevOpsとカスタマーサクセスに結びつけます。これらのステージがなければ、企業は新規ブッキングを喜びながら、顧客基盤内のリスクを見逃してしまうかもしれません。

アカウント vs 人物 vs 案件のステージ

多くのチームがオブジェクトごとのステージを混同しています。

人物はリードになり得ます。アカウントはターゲット、アクティブ、顧客、あるいは解約済みになり得ます。案件はクオリファイ済み、後期ステージ、クローズドウォン、クローズドロストになり得ます。顧客はオンボーディング中、アクティブ、更新リスク、拡大候補になり得ます。

RevOpsは、どのオブジェクトがどのステージを所有するのかを定義すべきです。

これが重要なのは、チームがオブジェクトを混同するとレポートが破綻するからです。リードコンバージョンレポートを、アカウント進捗レポートとして使うべきではありません。案件予測を、更新の健全性の代わりに使うべきではありません。

ステージ別必須フィールド

各ステージには、少数の必須フィールドがあるべきです。

例:

必須フィールドは絞り込んでおきましょう。必須フィールドが多すぎると悪いデータを生みます。フィールドガバナンスには必須フィールド vs 有用なフィールドを活用してください。

ステージレビューの頻度

ステージは四半期ごと、またはGTMモーションが変わったときに見直しましょう。

見直しのきっかけ:

• 新しいセグメントまたはプロダクトライン
• 営業主導からプロダクト主導へのモーション転換
• 新しい更新または拡大モーション
• 大きなCRMまたはマーケティングオートメーションの変更
• 定義をめぐる繰り返しの論争
• 予測や取締役会向け報告との不一致

ステージマップは、レポートに使えるほど安定していて、かつビジネスに合わせられるほど柔軟であるべきです。

準備チェックリスト

ライフサイクルマップを公開する前に、次を確認しましょう。

• すべてのステージに一人の主たる所有者がいる。
• すべてのステージに参入基準と卒業基準がある。
• すべてのステージに、意思決定に結びついた必須フィールドがある。
• ステージの移動が監査可能である。
• 販売後のステージが含まれている。
• どのステージがプランニングに影響するか財務が理解している。
• ダッシュボードが同じ定義を使っている。
• マネージャーが例外への対応方法を知っている。

いずれかが「いいえ」なら、そのステージマップはまだガバナンスの準備ができていません。

新しいステージの展開方法

ライフサイクルステージの変更は、レポート、ワークフロー、自動化、ダッシュボード、習慣に影響するためリスクを伴います。

実践的な展開には次を含めるべきです。

1. 現行のステージをマッピングし、それぞれが何に使われているかを特定する。
2. 新しいステージモデルと、各変更の理由を定義する。
3. 旧ステージを新ステージに対応付ける。
4. ステージの値に依存するダッシュボード、ワークフロー、連携を確認する。
5. マーケティング、営業、CS、財務、システム担当と影響をレビューする。
6. 参入基準と卒業基準についてマネージャーを研修する。
7. レコードを慎重に移行し、前提を文書化する。
8. 最初の1か月はステージの移動を監視する。

ステージを気軽に名前変更しないでください。小さなラベル変更でも、レポートの履歴を壊したりチームを混乱させたりすることがあります。

ステージ滞留期間

すべてのステージには、想定される滞留期間の範囲があるべきです。

ステージ滞留期間は、レコードがどこで停滞しているかをマネージャーが把握するのに役立ちます。

適切なしきい値はモーションによって異なります。高速なインバウンドリードは数時間で滞留と見なされるかもしれません。エンタープライズ案件は数週間かかることもあります。重要なのは、放置されたレコードを普通のことと見なす代わりに、しきい値を定義することです。

クローズドロストと失格ステージ

完全なライフサイクルマップには、ネガティブな結果も含まれます。

失格、却下、クローズドロスト、解約、縮小のステージは、隠すべき失敗ではありません。学びのポイントです。

RevOpsは理由コードを標準化すべきです。

• フィット不良
• 予算なし
• 決裁権なし
• 明確な課題なし
• タイミング
• 競合
• 機能不足
• 重複
• 連絡不能
• 導入リスク

これらの理由は、今後の意思決定に反映されるべきです。フィット不良のリードが多いなら、ターゲティングを変えましょう。タイミングが多いなら、ナーチャリングを改善しましょう。機能不足が多いなら、その洞察をプロダクトに伝えましょう。決裁権なしが多いなら、ディスカバリーを改善しましょう。

正とするソースのルール

ライフサイクルマップには、各ステージがどこに存在するかを明記すべきです。

例えば:

• リードステータスはリードまたはコンタクトのレコードに存在する。
• アカウントライフサイクルはアカウントに存在する。
• セールスステージは案件に存在する。
• 顧客ライフサイクルはアカウントまたは顧客オブジェクトに存在する。
• 更新と拡大のステータスは、システムによって案件、アカウント、またはサブスクリプションオブジェクトに存在する場合がある。

これを書き留めておきましょう。どのオブジェクトが正であるかをチームが知らなければ、ダッシュボードは食い違ってしまいます。

関連するガバナンスについては、レベニューオペレーションズシステムオブレコードを参照してください。

ステージマップの品質レビュー

実際のレコードを使ってマップをレビューしましょう。

直近のリードを10件、案件を10件、クローズドウォンの案件を5件、更新リスクのアカウントを5件、拡大候補を5件選びます。それぞれのレコードが正しいステージにあるか、次のアクションが明確かを確認しましょう。

レビュー担当者の間で意見が割れるなら、定義が十分明確ではありません。次のアクションが不明確なら、そのステージは有用ではありません。必須フィールドが空欄またはでたらめな値で埋められているなら、データモデルには手直しが必要です。

このレコードレベルのレビューは、抽象的にステージ名について議論するよりも優れています。

よくある間違い

ステージが多すぎる。 些細なステータスすべてがライフサイクルステージになると、レポートがノイズだらけになります。

卒業基準がない。 根拠のないステージは主観的になります。

営業だけのライフサイクル。 継続収益型の企業には、顧客ステージと拡大ステージも必要です。

ツール主導のステージ。 CRMのテンプレートに含まれているという理由だけでステージを使わないでください。

放置されたステージに所有者がいない。 レコードが長く留まりすぎているなら、誰が対応すべきか分かっているべきです。

クローズドロストと解約データを無視する。 失注・解約したレコードは、どのステージのクオリフィケーションが不十分だったかを企業に教えてくれます。

チームごとに異なるステージマップ。 ローカルなステージが存在してもよいですが、経営層向け報告には一つの共有ライフサイクルが必要です。

ライフサイクルポリシーの例

シンプルなポリシーは、マップを徹底しやすくします。

ライフサイクルステージは、所有権、必要なアクション、レポート、または顧客の状態を変える場合にのみ追加できる。すべてのステージには、参入基準、卒業基準、所有者、必須データ、想定滞留期間、例外時の対応経路がなければならない。経営層向け報告に使われるステージは、RevOpsガバナンスを通じて承認され、データ辞書に文書化されなければならない。

このポリシーは、ステージの乱立を防ぎます。

ステージ変更チェックリスト

ステージを変更する前に、次を問いましょう。

• どのレポートがこのステージを使っているか。
• どのワークフローや自動化がそれに依存しているか。
• どのチームがそれを入力・更新しているか。
• どの過去データとの比較が壊れるか。
• どのフィールドが必須または任意になるか。
• どの研修やマネージャー点検が変わるか。
• どのダッシュボードの定義を更新する必要があるか。

ほとんどのステージ変更は、見た目以上にコストがかかります。RevOpsは、変更が承認される前にそのコストを可視化すべきです。

実践的な推奨事項

まずはシンプルな全体ライフサイクルマップから始め、意思決定が必要とする箇所にのみ詳細を追加しましょう。

多くのB2B企業にとって、最初のバージョンは次をカバーすべきです。

• 獲得済みリード
• MQL
• SQL
• 案件
• クローズドウォン
• オンボーディング
• アクティブ顧客
• 更新リスク
• 拡大候補

これで、獲得、営業、カスタマーサクセス、プランニングをつなぐには十分です。より細かいステージは、それがレポートの詳細さではなく実際の管理を改善するという根拠を企業が得てから、後で追加できます。

最良のステージマップは、良い意味で退屈です。リーダーはそれを理解し、マネージャーはそれを徹底でき、システムはそれを支えられ、新入社員は個別の説明なしにそれを学べます。マップが常に解釈を必要とするなら、それはまだ完成していません。

ステージガバナンスレビューパケット

ライフサイクルステージのレビューは、ステージの一覧以上のものを示すべきです。

含めるべき項目:

• ステージ名と定義。
• 参入基準。
• 卒業基準。
• 主な所有者。
• 必須フィールド。
• SLAまたはタイミングのルール。
• 例外時の対応経路。
• ダッシュボードへの影響。
• 下流の引き継ぎへの影響。

このパケットにより、ステージの変更が実務的なものであり続けます。提案されたステージが所有権、根拠、タイミング、レポート、顧客の引き継ぎのいずれも変えないなら、それは存在する価値がないかもしれません。追加のステージは、あいまいさを増やすのではなく減らすべきです。

関連記事

• ファネルガバナンス
• リードから案件へのプロセス
• 案件から顧客へのプロセス
• 顧客から拡大へのプロセス