revenue-funnel

収益ファネルの設計

RevOps部門の責任者と戦略的パートナーとなり、会社の収益ファネルモデルをゼロから設計します。成果物はスライドではなく、バージョン管理された一連の成果物（以下の「出力形式」）です。オーナーを定めたステージ群、出典情報を添えたコンバージョン登録簿、そしてマーケティング、セールス、CSをつなぐハンドオフ／SLAのレイヤーを作成します。モデルを設計し、モデル内で実行することはありません。

基本ルール

• マクロレベルに限定してください。どのステージを設けるか、何を単位として進めるか、誰の数値を計画に反映するか、各ハンドオフを誰が担うかを設計します。個々のステージの退出条件の文言、リードのルーティングルール、ハンドオフの実行手順書は決して作成せず、「リファレンス」にある関連スキルに委ねてください。
• ステージ数を数える前に、2つの判断を行います。モデルの用途（プロセス、計画、予測のどれか）と、モデル内を進む単位（リード、コンタクト、購買グループ、商談、アカウントのどれか）です。この3つの用途を1つのステージ群に混同することが、ファネル設計の失敗の大半の根本原因です。
• コンバージョンの想定はコホートを優先します。受注率は期間指標、成約率はコホート指標、パイプラインコンバージョン率はスナップショット指標です。同じ事業でも、どの指標と分析タイプを選ぶかだけで、1つの事例から、受注率50％、成約率30％または20％という数値が読み取れます。
• モデル内のすべての率について、その基準を明記してください。明記されていなければ、公開してはいけません。
• 公表されているベンチマークは、調査のきっかけにしてください。目標設定には使いません。ステージの定義が一致しないため情報源によって数値が異なり、サンプルの区分も非常に小さいからです。広く引用されているあるレポートでは、回答者約106社を5つに分けており、各区分の企業数は約20社です。公表範囲から大きく外れたステージは、埋めるべきギャップではなく、調査すべき疑問です。
• ファネルは、キャパシティとリソース配分のための手段であり、買い手の心理をモデル化するものではありません。目標達成に必要なSDRの人数、需要創出予算、クォータを達成できるキャパシティなどを示します。成長ループモデルでは答えられない問いです。ループはチャネル戦略の成果物として分けて扱い、どちらかがもう一方の問いに答えられるかのように扱ってはいけません。
• MQLは目標としては不適切ですが、状態としては許容できます。購買グループによる適格性評価への移行は、データモデルに大きなコストを伴う変更です。現在の議論の流行がどうであれ、1件の商談につき関係者がおよそ3～4人未満なら推奨しないでください。
• このモデルの定義、計測基盤、変更管理を担うのはRevOpsです。セグメンテーション、ICP、オファーの賭け、価格設定の方針は決して担いません。それらはコマーシャル部門のリーダーが担う領域です。エンゲージメントがその領域に逸れた場合は、その旨を伝えてください。
• 実際の業務上の必要に迫られた場合にのみ、ステージを追加してください。初期段階で最もよくある失敗は、会社がまだ実現していないエンタープライズプロセスを10段階のパイプラインでモデル化することです。ステージが1つ増えるごとに、恒久的な管理負荷が増えます。
• すべての数値に出典を明記してください。ユーザー自身のデータ、注意事項を添えた固有名の公表情報源、または明示的な推定のいずれかです。
• 以下の優先順位付きメニューはすべて、デフォルトの順序を示すものであり、絶対的なルールではありません。状況や実行担当者によって順序は変わります。「インタビュー」の回答と、会社にすでにあるもの（コホート分析のSQLをすでに実行できるアナリスト、稼働していない管理者の余力、すでに参加しているエグゼクティブスポンサーなど）を踏まえて順序を入れ替えてください。並べ替えを提示する際は、どの回答によってどの選択肢が移動したのかを明記してください。

インタビュー

設計に入る前に質問してください。1メッセージにつき1問とし、可能な場合は選択式にしてください。すでに回答済みの内容は省略してください。

• きっかけは何ですか？ファネルモデルが存在しない、誰も信頼していないモデルを引き継いだ、営業手法や製品の変更で旧モデルが使えなくなった、または経営陣から収益計画を求められた、のいずれでしょうか？
• モデルが最初に答えるべき質問は何ですか？各段階で何をすべきか（プロセス）、目標達成に必要なインプット数はいくつか（計画）、それとも今四半期に何が成約するか（予測）でしょうか？主目的を1つ選んでください。ほかの項目は追加のステージではなく、派生ビューとして扱います。
• どのGTM手法を採用していますか？ノータッチ／PLGのセルフサービス、ロータッチの支援型、ミッドタッチ（SDRが適格性を確認してからAEに引き継ぐ）、ハイタッチのエンタープライズ、チャネル／パートナー主導のいずれでしょうか？複数の手法を同時に運用していますか？
• 収益モデルは何ですか？サブスクリプション、使用量／消費量ベース、マーケットプレイス／テイクレート、買い切りのいずれでしょうか？
• 通常の商談には何人のステークホルダーが関わりますか？1～2人、3～4人、5人以上でしょうか？これによって、単位を個人リードと購買グループのどちらにするかが決まります。
• 企業の成長段階はどこですか？PMF前／シード、シリーズA～B、シリーズC以降、または上場企業でしょうか？
• 新規収益のうち、既存顧客（更新、アップセル、クロスセル）からの割合はおおよそどのくらいですか？これによって、モデルにどの程度の販売後ファネルを含める必要があるかが決まります。
• どのようなデータがありますか？CRMまたはデータウェアハウスに、コホート率を計算できるほどクリーンなステージ履歴が何四半期分ありますか？古いパイプラインは最近整理されましたか？
• すでにどのような定義が使われていますか？MQLの定義は1つですか、それとも地域やチームによって複数ありますか？現在、定義の責任者は誰ですか？変更を承認できる定例の場はありますか？
• B2B、B2C、または両方ですか？B2Cの場合、営業支援型の高関与商材（保険、不動産、入学手続きなど）ですか、それとも取引型／セルフサービスの大量販売ですか？
• モデルの導入期限はいつですか？年次計画や取締役会など、計画サイクルに影響しますか？厳しい期限がある場合は、加重平均レートでモデルを導入し、セグメンテーションは後続対応として予定します。
• これは一度限りの計画インプットですか、それとも継続的に運用するモデルですか？一度限りなら、ガバナンスは担当者の指名とレビュー日の設定に簡略化します。継続的に積み上げる前提なら、ファネル協議会と再ベンチマークの実施頻度は必須です。
• 工数の上限はどのくらいですか？コホート分析に割けるアナリストの時間、新しい定義を計測可能にする管理者の対応能力、マーケティングと営業の双方を拘束力のあるSLAのもとに置くための社内調整力はどの程度ありますか？部門横断のスポンサーがいない場合は、SLAの適用を文書上の合意にとどめ、その旨を成果物に明記します。

ワークフロー

1. インタビューを実施します。対象範囲を確認します。モデル設計であり、既存のステージ定義の監査でも、モデル内での実行でもありません。
2. 先行する2つの判断と収益の境界を確定します（以下の「先行する2つの判断」を参照）。ユーザーが3項目すべてを承認するまで、ステージ数の検討に進まないでください。
3. フレームワークの用語を選択します（以下の「フレームワークの用語」を参照。詳細は references/framework-selection.md を参照）。
4. 明示的にブレインストーミングを行います。「候補設計」に従って、ステージセットの候補を2～3案提示し、それぞれのトレードオフと推奨案を示します。その案を基に何かを構築する前に、ユーザーに選択してもらいます。
5. 「コンバージョンの前提」に従ってコンバージョン登録簿を作成します。手法については references/conversion-methodology.md を参照してください。
6. 「オーナーシップと引き継ぎ」に従って、オーナーシップと引き継ぎのレイヤーを設計します。仕組みについては references/handoff-sla-design.md を参照してください。
7. ガバナンスの枠組みを定めます。定義変更を承認する担当者、再ベンチマークの頻度区分、モデル自体のバージョン管理を決めます。
8. references/worked-examples.md の対応する実例に基づき、成果物（以下の「出力形式」を参照）を1つずつ提示し、その都度ユーザーの承認を得ます。モデル全体を既成事実として提示してはいけません。
9. 合格基準を確認し、満たされるまで反復します。あるいは、残る課題をすべて明示的に予定に組み込みます（例：データ量が十分になるまでコホート分解を保留する）。
10. ハーネスに永続メモリがある場合は、確定した目的、単位、境界、ステージセット、前提登録簿を保存します。これにより、後続の計画や報告では、再インタビューせずに決定済みのモデルを起点にできます。

先行する2つの判断

モデルの目的。 プロセスモデル（営業担当者が何をするか）、計画モデル（目標達成に必要なインプット数）、予測モデル（今四半期に何が成約するか）では、最適なステージセットが異なります。開始時点のパイプラインは、過去1～4四半期に創出された商談の混合です。そのため、コホートベースの成約率と当四半期のコンバージョン率は異なる指標です。1つのステージセットから両方を無理に算出するのではなく、別々に追跡してください。

分析単位。 リード、コンタクト、購買グループ、商談、またはアカウントのいずれかを選ぶ、この1つの決定が後続のすべてを左右します。また、名前のあるフレームワークの世代を分ける実質的な違いでもあります。フレームワークの流行ではなく、インタビューで確認した案件あたりの関係者数への回答に基づいて決定してください。

販売前の終了地点。 それぞれに実質的なコストが伴う、妥当な境界は3つあります。

• 契約締結：標準的で監査しやすい一方、消費ベースの収益には適しません。
• 初回価値の提供：経済的には実態に即していますが、製品テレメトリが必要です。
• オンボーディング完了：便利ですが、買い手のマイルストーンではなく、デリバリーのマイルストーンです。

推奨されるデフォルト：境界を2つ設けます。財務向けには、コミット時点を会計上の境界として記録し、初回インパクトまでの時間はCAC回収の別指標として扱います。この2つを1つにまとめると、オンボーディングに指標もオーナーもないまま、企業が受注を祝いつつ1年目に顧客を失うことになります。

フレームワークの用語

このメニューは、効率性の順位を意図的につけていません。名前のあるフレームワークの違いは、マーケティング上の説明ほど大きくありません。「Engaged Demand」、「Detected」、「Awareness」は、それぞれ異なる後援者のもとで呼ばれている同じ段階であり、フレームワーク間の実質的な違いは、分析単位、販売後の対象範囲、終了条件の厳格さに集約されます。選択は、販売の動きと単位を対応づけ、取締役会がすでにどのベンチマーク母集団や用語を使っているかを判断することです。順位づけは、実態以上の精密さを装うことになります。

• ミッドタッチ、個別リードの適格性確認 -> 2012年頃のデマンドウォーターフォール用語。
• アカウントベース、購買グループの適格性確認（3～4人以上の関係者） -> デマンドユニットウォーターフォール（2017年）、または商談タイプごとに更新／アップセル／クロスセルの構成をモデル化する必要がある場合は、B2Bレベニューウォーターフォール（2021年以降）。
• 拡大による収益が大きい継続収益型 -> ボウタイ（販売後の半分にも同じ比重を置く。拡大分は新規ARRのうち5,000万ドル超で40％以上、5,000万～1億ドルで約58％、1億ドル超で約67％）。
• TOFU/MOFU/BOFU -> コンテンツと需要創出の計画に限った視点であり、パイプラインの段階としては決して使わないでください。
• マーケットプレイス／テイクレート -> 公開されているフレームワークに適合するものはありません。2つのファネル（供給側、需要側）を構築し、その間に流動性の制約を設け、独自のモデルであることを明示してください。

名前のあるフレームワークをそのまま全面的に採用することには、あまり認識されていない利点が1つあります。標準化された段階の定義があって初めて、外部とのピアベンチマークが意味を持ちます。選択肢を提示する前に、references/framework-selection.mdを読んでください。

候補となる設計

推奨する前に、ブレインストーミングを行ってください。候補となる段階セットの設計を2～3案提示し、それぞれについて次の項目を明記してください。

• 段階の一覧と各段階の担当者
• 分析単位と、その単位が切り替わる箇所（例：リード -> 商談）
• 販売後の対象範囲
• その設計が最適化するもの
• 継続的に発生する運用コスト

続けてトレードオフを比較し、理由を添えて1案を推奨してください。ユーザーが選択または組み合わせられるようにし、その選択を検証してから、それに基づいて変換レジスターを作成してください。

候補は、販売の動きに応じた段階数の範囲内に収めてください。

• ノータッチ／PLG：3～4
• ロータッチ：4～5
• ミッドタッチおよび大半のミッドマーケット／エンタープライズ：5～7
• ハイタッチのエンタープライズ：6～8

法務／セキュリティ審査が長期化する場合に第8段階を設けるのは例外であり、標準ではありません。購買プロセスが実質的に異なる場合（チャネル／パートナー）は、メインのパイプラインに段階を追加するのではなく、別個の対称的なパイプラインを設けてください。複雑さは企業の成長段階に合わせてください（references/framework-selection.mdの表を参照）。PMF前は段階を4～5個にし、推測はガバナンス体制を整えたシリーズC企業のように扱わず、推測として明示してください。

コンバージョンに関する前提

数値の算出元を、アナリスト1時間あたりの計画精度が高い順に示します。ベンダーやCRMの既定ステージ確率は、この候補から完全に除外し、順位を下げるだけにはしません。これらは、このビジネスに基づいて算出されたものではない、きりのよい数値であり、意図的に楽観的です。楽観的な案件価値に掛け合わせると、誤差が積み重なります。

• value: 自社のセグメント別コホート率 > 自社の全体コホート率 > 調整済み外部ベンチマーク
• effort: 自社のセグメント別コホート率 > 自社の全体コホート率 > 調整済み外部ベンチマーク
• efficiency: 自社の全体コホート率 > 自社のセグメント別コホート率 > 調整済み外部ベンチマーク

既定の選択肢は、ユーザー自身の履歴に基づく全体コホート率です。データ量で信頼性を確保できる範囲で、分散が最も大きい2つのディメンションに分けます。より細かなセグメント分け（モーション x セグメント x ソース x 商談タイプ）に進むのは、セルあたりの件数が信頼に足る水準を維持できる場合に限ります。分割の基準は意欲ではなくサンプルサイズです。調整済み外部ベンチマークに切り替えるのは、PMF前、またはトリガーによるリセットで利用可能な履歴が失われた後に限り、そのような数値はすべて明示的な推定値としてラベル付けします。

この順序では、4つのディメンションすべてを使ったセグメント分けが後回しになります。データ量の増加に応じて優先度を上げてください。商談タイプだけでも、多くのチームが想定する以上に率を左右するからです（新規顧客の獲得はコンバージョン率が一桁台前半である一方、更新や拡大ははるかに高い水準です）。

どの段階を採用する場合でも、方法は次のとおりです。

1. まず古いパイプラインを一掃します。あるベンダーの基盤では、パイプラインの10％超が12か月以上放置されており、そのデータがそれを含めて算出したあらゆる率を歪めていました。

2. 4〜8四半期の期間について、ステージごとに計算します。そのステージに入った件数を、最終的に次のステージに到達した件数で割ります。現在のステージにある件数ではなく、ステージへの流入件数を数えます。

3. コンバージョン率ごとに、その根拠（コホートまたはマイルストーン）、分子・分母の定義、サンプルサイズ、ソース、更新トリガーをコンバージョン台帳に記録します。

4. 6〜8個のコホートを使い、成約率を時間軸で分解します。四半期内、第1四半期、第2四半期の割合を算出します。リードタイムの分解がなければ、計画は算術的に正しくても時間軸では誤りになり得ます。リードタイムが30日の場合、四半期のカバレッジ計算はほとんど意味をなしません。四半期に成約するパイプラインのおよそ3分の2は、四半期の開始時点では存在しないからです。

5. ボトムアップのファネル計画をトップダウンの売上目標と照合し、差分を明示します。決して平均して差分を消してはいけません。差分を明示することで、MQLが10％不足していることを、売上未達になる2四半期前に把握できます。

6. 再確認の頻度を設定します。

   • 毎週：運用状況を監視します。前提は変更しません。
   • 毎月：コホートを再計算し、ドリフトの兆候を確認します。
   • 毎四半期：再承認とバージョン管理を行います。
   • トリガー発生時：ICP、価格設定、セグメント、モーション、報酬プラン、またはステージ定義が変更された場合、全面的に再ベースライン化します。

   トリガーが発生すると履歴は無効になります。ブレンドせず、リセットしてください。

オーナーシップの引き継ぎ

部門間をまたぐ引き継ぎポイントは3つあります。

• マーケティングから営業：適格リードの受け入れ。
• 営業からCS：受注確定からオンボーディングへの移行。
• CSから営業：更新／拡大。

それぞれについて、双方にオーナーを置き、明確な引き継ぎ基準と双方合意のSLAが必要です。以下の4段階は、投入する労力と政治的資本あたりに得られる連携の向上度で順位付けしています。

• 価値：system-enforced timers > bilateral SLA > standardized definitions > paper mapping
• 労力：system-enforced timers > bilateral SLA > standardized definitions > paper mapping
• 効率：paper mapping > standardized definitions > bilateral SLA > system-enforced timers

1. 紙上でのマッピング - 各引き継ぎの双方が一堂に会し、ファネルの最初の接点から拡大までをマッピングして、すべての引き継ぎについてオーナー、基準、問題が発生する箇所を記します。1〜2時間ほどで、実務担当者によると、連携上の最大のギャップは最初の30分で表面化します。必ず最初に、設計エンゲージメントそのものの中で実施します。
2. 定義の標準化 - 各引き継ぎのトリガー（適格と見なされる条件、引き継ぎが発生する条件）について、書面で定義します。単一のポイントスコアのしきい値ではなく、行動に基づいた定義にします。草案の作成に数時間、その後、承認に数日かかります。
3. 双方合意のSLA - 双方のコミットメント、タイマー、結果を定め、目標値は現在のベースラインに近い値に設定します。一方的なSLAではマーケティングが被告、営業が裁判官になり、本来生み出すはずの連携を損ないます。交渉に数週間かかり、部門横断のスポンサーが必要です。
4. システムで強制されるタイマー - 受け入れ期限、期限切れ時の自動差し戻し、エスカレーション、再割り当てをCRM／自動化レイヤーに組み込み、常設の合同定例で遵守状況を確認します。管理者による構築と再トレーニングが必要です。

効率の順序を優先すると、実効性の担保が後回しになります。しかし、引き継ぎが実際に失敗するのは定義ではなく実効性の部分です。どのシステムも追跡していないSLAは、1四半期もすれば文書に成り下がります。第4段階は後のフェーズに回さず、SLAの批准と同時に進めてください。インタビューで双方合意のSLAを推進するスポンサーが見つからなかった場合は、設計から第3〜第4段階を外し、第1〜第2段階を提供したうえで、紙上の合意が維持されるかのように装うのではなく、そのギャップを成果物に記録してください。仕組み、代表的なタイマー、営業からCSへのデータ契約については、references/handoff-sla-design.mdを参照してください。

出力形式

成果物は、1ファイルずつ提示して検証する一連のファイルとして納品します。

stage-definitions.md   : per stage - name, definition, entry criteria, owner,
                         unit, system-of-record field (exit-criteria wording is
                         drafted downstream by the stage-definition audit skill)
conversion-register.csv: rate, numerator/denominator, cohort-or-milestone basis,
                         sample size, source/provenance, last refreshed,
                         next-refresh trigger
funnel-model           : bottom-up plan with lagged cohort conversion, reconciled
                         against the top-down target, gap named explicitly
sla.md                 : bilateral commitments, timers, consequences, escalation,
                         version history - one per handoff point
data-dictionary.md     : object model, field ownership, allowed values, reason
                         codes for the fields the model depends on
governance-charter.md  : funnel council membership, decision rights, definition
                         change control, re-benchmarking cadence
capacity-model         : headcount and budget implications derived from the
                         funnel model, never independently authored

定義はCRMとマーケティングオートメーションプラットフォームで管理し、測定データはデータウェアハウスで管理します。これにより、定義の変更時に過去のレポートを損なうことなく、履歴を再計算できます。

合格基準

• すべてのステージに、明示されたオーナー、開始条件の定義、分析単位、記録システム上のフィールドがあります。ユーザーが説明できる運用上の必要性がなければ、ステージを設けません。
• コンバージョン登録簿のすべての率に、算出基準（コホートまたはマイルストーン）、分子／分母、サンプルサイズ、出典、更新トリガーが記載されています。ラベルのないデフォルト値は残しません。
• ボトムアップ計画とトップダウン目標を照合し、その差を平均化してごまかすのではなく、数値で明記します。
• 4四半期以上の履歴がある場合、モデルを過去のデータでバックテストし、モデル上の率と実績の率が合意した許容範囲を超えて乖離するステージには、仮説を添えてフラグを立てます。
• 収益の両方の境界（会計上の計上確定と初回価値の実現）をモデル化するか、単一境界を選ぶ理由を成果物に明示します。
• すべての引き継ぎポイントに、双方の責務、タイマー、結果、エスカレーション経路があります。または、どの段階を外したかとその理由を記録します。

6項目すべてを満たすまで反復します。コホートの内訳を信頼できるものにするには、成熟したコホートが6〜8件必要です。その数にまだ達していない場合は、利用可能な基準で出荷し、その旨を明記したうえで、次回の更新トリガーの最初の項目としてアップグレードを予定します。

よくある失敗パターン

あえて順位は付けていません。各行は、1つの目標に対する競合する選択肢ではなく、診断と対策の組み合わせです。該当する行をすべて適用してください。

不備	影響	対策
地域やチーム間で定義にばらつきがある（報告されている事例：MQL のバージョンが3種類、リードのステータスが30種類以上）	部門間でリードが滞留し、報告者によって勝率の報告値が異なる	定義を一元化し、評議会の承認を得てバージョン管理します。地域ごとの差異には評議会の承認が必要です
チームごとに各レイヤーの件数を測定する	マーケティングが質の低いリードを増やし、下流のコンバージョン率が低下して、営業が責任を問われます	レイヤーごとの指標とあわせて、ファネル全体で共通の指標を使い、コンバージョンを共同で確認します
各遷移に対して、コンバージョン率を1つにまとめる	実際の計画を左右するセグメント、流入元、商談タイプごとのばらつきが見えなくなります	件数が十分な範囲で、ばらつきが最も大きい2つの軸に沿ってセグメント化します
ステージを予測カテゴリとしても使う	どちらの概念も劣化し、確信度を示すためにステージが水増しされます	互いに独立した2つのフィールドを設けます。ステージはプロセス上の位置、カテゴリは確信度を表します
直線的な顧客行程を前提とする	後戻りやループがノイズとして記録されるか、完全にブロックされます	再循環や後退の経路を明示的に設計し、後戻りの遷移を主要な指標として測定します
従量課金型の収益で、契約時点だけを売上境界とする	受注が祝われる一方で、実際の収益に至るまでの立ち上がりを誰も管理しません	コミットメントと初回価値の境界を別々にモデル化します
PLG で PQL のみを適格とする	営業のリソースがアカウントではなく、個人のカード決済者に向けられます	プロダクト適格アカウントを追加し、PQL を分類して、問い合わせをしたリードを優先します
チャネル予算の争いを解決するためにアトリビューションを使う	ソフトウェアによるアトリビューションは、構造上、ラストタッチの下流チャネルを優遇します	アトリビューションは方向性を示すものとして扱い、ファネルモデルの対象範囲から予算争いを除外します
古いパイプラインをベースラインに残す	算出されるすべての率がファネルを実態以上に良く見せます	率を算出する前に、データの整理を徹底します

B2B と B2C

B2B と B2C は、次の3つのケースに分かれます。

• 営業支援型で、検討期間の長い B2C（保険、不動産、太陽光発電、入学手続き、自動車、住宅ローン）：実際のステージパイプラインを運用し、目的／単位／境界に関する判断をそのまま適用できるため、モデル全体を変更せずに転用できます。通常、単位となるのは購買グループではなく、世帯または申込者です。
• 取引型／セルフサービス型の B2C：取引ごとのステージ状態がありません。適切な手法は、ライフサイクルステージとコホート／イベントファネル分析です。このスキルが作成するモデルは不適切な成果物になります。その旨を伝え、パイプラインを無理に当てはめるのではなく、ライフサイクル／コホートの測定計画を設計してください。
• PLG：両者の中間に位置します。セルフサービス側ではコホート分析を行い、プロダクト認定ゲート以降では圧縮したステージモデルを使います。

KPI

• モデルが存在するかどうかではなく、機能しているかどうかを追跡します。
  • 各四半期の各ステージにおける、初日時点の計画と実績の絶対差
  • 前提がレジスターの許容範囲からどれだけ乖離したか
  • ステージの逆行率
  • 引き継ぎごとの SLA 遵守状況（応答時間、処理率）
  • 計画サイクルを重ねるごとに、明示されたボトムアップとトップダウンの差がゼロに近づいているか
• ガバナンスの健全性：レジスターの最終更新日が最新であり、定義の変更が評議会を迂回せず、評議会を通じて行われていること。
• あくまで方向性を示す背景情報であり、保証ではありません。正式なマーケティングと営業の SLA は、報告されるプログラム ROI の向上と相関し、連携したレベニューオペレーションは成長の加速と相関します。いずれも調査／アナリストの知見であり、特定の企業に対する保証ではありません。

呼び出し例

• 「当社は Series B の SaaS 企業で、SDR から AE へ引き継ぐ営業体制ですが、実用的なファネルモデルがありません。マーケティング、営業、CS でそれぞれ異なるものを数えています。ゼロから設計してください。」
• 「取締役会が、ファネルの計算に基づく収益計画を求めています。CRM の履歴から、ステージモデルと根拠のあるコンバージョン前提を設定するのを手伝ってください。」
• 「当社は大手企業向けの市場へ進出しており、取引に関わるステークホルダーが5人以上になりました。ファネルでは MQL ではなく購買グループを認定すべきでしょうか。モデルがどのようになるかも教えてください。」

参考資料

• 用語とステージ数の範囲を選ぶ際は、references/framework-selection.md を読んでください。
• レジスターを作成する際は、references/conversion-methodology.md を読んでください。
• 引き継ぎレイヤーを設計する際は、references/handoff-sla-design.md を読んでください。
• 成果物を作成する際は、references/worked-examples.md を読んでください。
• 既存のステージセットの終了基準を監査するには、mbfinotti/revops-skills@pipeline-stage-definition-audit を参照してください。このスキルでは、各ステージの買い手が検証可能な表現を作成するのに対し、こちらのスキルでは、そのステージを組み込むモデルを設計します。
• 適格性判定ゲートに適用するスコアリングロジックについては、mbfinotti/revops-skills@lead-scoring を参照してください。
• 適格性判定ゲートに適用する割り当てロジックについては、mbfinotti/revops-skills@lead-routing を参照してください。
• 成約後の引き継ぎを実行する方法については、mbfinotti/revops-skills@sales-to-cs-handoff を参照してください。
• 率の算出前に実施する必要がある停滞案件の確認については、mbfinotti/revops-skills@sales-pipeline-hygiene を参照してください。
• このモデルの KPI が組み込まれる指標階層については、mbfinotti/revops-skills@revenue-kpi-framework を参照してください。