revenue-leakage

収益漏出

特定のファネルインスタンスからレコードと売上が気付かれないままどこで抜けていくのかを追跡し、それぞれの損失が実在することを証明し、回収可能額を見積もり、担当者ごとに修正策の優先順位を付けます。

• ライフサイクルの視点： Winning by Design の Bowtie（winningbydesign.com/bowtie）。漏出は、営業ステージだけでなく、顧客獲得からオンボーディング、更新、拡大まで広がります。多くのチームは前半を過剰に精査し、後半を一度も照合しません。
• 後期ステージの漏出： MEDDPICC の「Paper Process」要素（meddicc.com/meddpicc）は、後期ステージにおける典型的な漏出、つまり口頭での合意から署名までの間に失注する案件を示しています。
• 作業方法： Celonis が普及させたアプローチである、ファネル独自のイベントログにプロセスマイニングを適用します。文書化されたフローチャートではなく、タイムスタンプから実際に進行したプロセスを再構成します。

基本ルール

• トレースに徹し、再設計はしません。ステージの構成、ルーティングルール、スコアリングモデル、引き継ぎプロセスは入力として扱います。そのいずれかに欠陥がある場合は、1行で指摘し、Reference の該当スキルへ案内してください。ここでは再構築しません。

• 成果物は漏出登録簿であり、データ衛生チェックリストではありません。停滞案件数、未入力フィールド、プッシュ回数は漏出箇所を特定するための入力シグナルです。これらを調査結果として報告するのは別のスキルの役割です（mbfinotti/revops-skills@sales-pipeline-hygiene）。漏出分析では、説明のつかない理由でレコードと売上がどこから抜けたのか、そしてその価値はいくらなのかを明らかにします。

• 以下の三者分類を通過するまでは、何も漏出とはみなしません。健全な失格判定を漏出として数えるのは、この種の分析で最もよくある誤認です。データ取得の欠落をファネルからの脱落と取り違えるのは、2番目によくある誤認です。

• 総額ではなく、回収可能額を算出します。停滞案件のファネル総額を「漏出売上」として提示するのは、こうしたレポートが財務部門からの信頼を失う典型的な原因です。

• 1つの期間、1つの流入コホートについて、1つのファネルインスタンスだけを対象にします。チーム、ファネル、四半期をまたぐプログラムレベルのパターンは対象外です。

• すべての数値しきい値に、その根拠を明記します。公開されている実務、実務家のコンセンサス、またはユーザー自身のデータから導出したもののいずれかです。ベンダーの経験則を業界共通の定数として提示してはいけません。

• 以下に挙げる、広く流通しているリード対応速度の統計には注意を促してください。これらを掲載しているベンダーのページには、出典が記載されていません。

  • 「5分以内に返信すると、可能性が100倍になる」
  • 「適格と判断される可能性が21倍になる」
  • 「B2Bの平均返信時間は42時間」
  • 「リードの38％は一度も返信しない」
  • 「391％／60秒ルール」

  HBR の2011年の論文「The Short Life of Online Sales Leads」（Oldroyd、McElheran、Elkington）は、返信の遅延が重要であることを示す、実在する引用可能な証拠です。しかし、一般にこの論文と結び付けられている具体的な倍率は検証できませんでした。ユーザー自身の返信時間とコンバージョンの関係を示す曲線を測定し、そこからしきい値を導出してください。

保存則テスト

ファネルの各ステップに入ったすべてのレコードは、カウント可能な次のいずれか1つの結果を経て、そのステップを離れる必要があります。

• 次のステップへ進んだ
• 記録済みの理由により失注
• 記録済みの理由により不適格と判定／再循環
• そのステップの想定滞留期間内で、引き続きオープン

遷移ごとに照合を行います。

entered  =  advanced + lost(reason) + disqualified(reason) + still-open(in window)  +  residual

残差がゼロでない場合は、すべて説明が必要です。漏れと呼ぶ前に、次の3分類を適用してください。

1. 実際の漏れ - レコードには見込みがあったものの、プロセス、システム、または担当に関する理由で動きが止まりました（連絡なし、受け入れなし、期間を超えて停滞、請求なし）。規模を算定して優先順位を付けるのは、これらだけです。
2. 適切な不適格判定 - 正当な理由でレコードが離脱し、その離脱が記録されています。漏れではありません。不適格判定がゼロのファネルは健全ではなく、ふるいにかけられていない状態です。
3. データ記録の欠落 - レコードは実際には進んだものの、システムに記録されませんでした。追跡されていないステップ、受信トレイやスプレッドシート上で行われている作業、タイムスタンプの欠落、書き戻しを行わないシステムで完了するコンバージョンなどが該当します。落ちているのはファネルではなくデータです。必要なのは計測機能の追加であり、ここで「ファネルを改善」しても何も解決しません。

追跡されていないステップの検出が、特に重要な手法です。 隣接するシステムまたは担当者の各ペアについて、その間に何が起きるのか、また人が手作業で行うのかを確認してください。受信トレイ、スプレッドシート、チャットスレッドで実行されるステップにはタイムスタンプがないため、測定可能な離脱率がありません。計測されるか、単に通過するだけだと証明されるまでは、そのようなステップはすべて漏れの疑いがある箇所として扱います。レコードが発生しないステップには、測定可能な漏れはありません。数値を推測するのではなく、計測機能の欠落として明示してください。

B2BとB2C／セルフサービス

• B2Bの営業主導型： 漏れが生じる箇所は、人のアクションポイントです。対応、振り分け、受け入れ、次のステップへの移行、署名の催促などが該当します。担当者が所有するパイプラインがあるため、残差は担当者に紐づきます。
• B2C／セルフサービス／PLG： ファネルの大部分には担当者が所有するパイプラインがありません。仕組みは人ではなく技術に起因します。トライアルやチェックアウトのステップでの離脱、決済失敗や督促の欠落、非自発的チャーン、自動更新の失敗などが該当します。非自発的チャーンはサブスクリプション全体のチャーンの20～40％を占めます（Paddleの調査を引用したBaremetricsのデータ）。B2B SaaSでは2～5％です（Baremetrics自社プラットフォームのデータ。ベンダー集計値であり、独立した調査ではありません）。
• 両者に共通し、変更せずに適用するもの： 保存則に基づく照合、3分類、回収可能な金額の算定ルール、そして計測機能が追加されるまで追跡されていないステップは測定できないというルールです。異なるのは、漏れが生じる箇所の一覧と、証拠の種類だけです。

インタビュー

分析を始める前に質問してください。1つのメッセージにつき質問は1つにし、可能な場合は選択式にしてください。すでに回答済みの項目は省略してください。

• どのファネルと販売方式ですか：B2B の営業主導型、営業支援型 PLG、完全セルフサービス型／B2C のどれですか？対象にするファネルは1つだけです。どれですか？
• この調査のきっかけは何ですか：減少した数値、取締役会での質問、消えた商談、直感のどれですか？
• 実際に運用しているファネルのステップは何ですか（公式の図ではなく）、記録の各部分はどのシステムに保存されていますか：マーケティングツール、営業システム、請求システム、スプレッドシートのどれですか？
• 実際にエクスポートまたはクエリできるのは何ですか：タイムスタンプ付きのステージ変更履歴、担当者履歴、失注理由と不適格理由のコード、請求書の記録、支払い失敗イベントなどですか？
• 現在、手作業のステップはどこで行われていますか。受信トレイ、スプレッドシート、チャットメッセージを介して行われる引き継ぎはどれですか？
• ファネルの各部分の責任者は誰で、各部分の間の領域の責任者は誰ですか？
• 分析対象にする期間と流入コホートはどれですか？（1つのコホートを追跡します。異なる時期のコホートを混ぜたスナップショットは使いません。）
• 平均商談額またはサブスクリプション価値と、わかっていれば過去のステップ間コンバージョン率はどれくらいですか？
• 各遷移で、説明できない残差をどれだけまで許容し、承認できますか？合格基準はこの数値によって決まり、スキル側ではなく、あなた自身が設定する必要があります。一般的な実務上の目安は、各遷移で流入したレコードの5％です。これは実務者による数値であり、公表された基準ではありません。より適切な根拠がない場合に限り、5％を仮の値として使い、1回の実行で照合履歴が得られたら、できるだけ早くファネル独自の照合履歴に基づいて厳しくしてください。
• 回収した収益を実際に計上しなければならない期限はいつですか：今四半期の締め日、取締役会の日程、特に固定の期限なし、のどれですか？（厳しい期限がある場合、今回の対応項目からプロセス再設計を外し、アラート、ルーティングのフォールバック、すでに漏出したレコードの再処理を優先します。）
• すでに漏出したレコードを一度だけ回収したいですか。それとも、漏出の再発を防ぐ修正を望みますか？（一度だけの対応では再処理を優先し、継続的な改善ではアラート、ルーティングのフォールバック、回収シーケンスを優先します。）
• 工数の上限はどれくらいですか：アナリストの作業時間のみ、エンジニアリングの対応が可能、または部門横断のプロセス変更も検討可能、のどれですか？
  • アナリストのみの場合、計測と再設計による修正は対象外になります。
  • エンジニアリングの対応が可能な場合、回収シーケンスと計測を優先します。
  • プロセス再設計を優先対象にできるのは、部門横断の権限がある場合のみです。

ワークフロー

1. インタビューを実施します。ファネル、対象期間、流入コホートを確定し、対象範囲の境界（再設計ではなく追跡）を確認します。
2. 実際に運用されているファネルをマッピングします。手作業のものも含め、すべてのステップ、システム、担当者、引き継ぎを記録します。追跡されていないステップや手作業で行われているステップには、漏れの疑いがある箇所として印を付けます。調査対象を漏らさないためのチェックリストとして、references/leak-site-inventory.md を使用します。
3. ファネルのシステムに直接クエリを実行できる場合は、イベント履歴から遷移ごとの保存則の照合を作成します。できない場合は、エクスポートデータとユーザーが提供する記録サンプルから導き出し、照合できなかった遷移はすべて、問題がないと仮定せず「未計測」として記録します。
4. ゼロではない残差をすべて、3つの観点から分類し、記録グループごとに証拠を添えます。証拠には、タイムスタンプ、担当者の履歴、理由コード、またはそれらが存在しないことを含めます。分類できない残差には「未説明」のラベルを付けたままにし、「漏れ」へ直ちに分類することは決してありません。
5. 確認済みの実際の漏れはすべて、references/sizing-recoverable-revenue.md に従って回収可能な金額を算出し、各金額に信頼度タグを付けます。
6. 回収可能な金額を修正工数の単位で割った値で順位付けした漏れ登録簿を作成します（スキーマは「出力形式」を参照）。金額だけで順位付けすることは決してありません。references/sizing-recoverable-revenue.md の修正クラスの順序を使い、期限、単発か累積的か、許容される工数に関するインタビューでの回答を踏まえて順位を付け直します。ユーザーの制約によって実施できない修正クラスは順位を下げるのではなく削除し、削除した制約を明記します。データ収集の不足は独立したセクションにまとめ、金額ではなく計測機能の修正を記載します。
7. references/worked-examples.md の該当する例に基づき、ユーザーが検証できるよう、レポートを一度に1セクションずつ出力します。
8. 合格基準を確認し、満たすまで反復します。満たせない場合は、残っている不足をすべて、修正予定日が設定された未計測項目として明記します。
9. ハーネスに永続メモリがある場合は、ファネルマップ、計測の不足、合意済みの残差ベースラインを保存し、再確認時にそれらを起点にします。ない場合は、次回の実行時にユーザーが貼り付けられるよう、この3つすべてをレポートの最終セクションに記載します。

出力形式

すべての基準値と金額に、出所または信頼度のタグを付けます。

REVENUE LEAKAGE REPORT - <funnel>, <cohort/period>, <date>
Funnel map       : steps -> systems -> owners; manual/untracked steps flagged
Reconciliation   : per transition - entered / advanced / lost(reason) /
                   disqualified(reason) / open-in-window / residual (% of entered)
Leak register    : rank | site | evidence | classification | records affected |
                   recoverable $ (confidence) | owner | fix | fix class
                   (fix class carries the effort behind the rank; ranking basis
                   and any deleted fix class stated above the register)
Disqualification : volume left for recorded, legitimate reasons (not leakage)
Capture gaps     : untracked steps + records that progressed unrecorded;
                   instrumentation fix per gap, no dollar figure
Recoverable total: sum of register, by confidence band; never a gross figure
Re-check         : residual baselines agreed, re-run date, gaps scheduled

合格基準

• 照合済みの各遷移における未説明の残差が、事前にユーザーと合意した許容範囲を下回っています。一般的な実務上の目安は、各遷移で流入レコードの5％です（公表された標準ではなく実務上の目安です。ファネル自体の履歴から、より厳しい基準を導き出してください）。
• 漏れ登録簿の各項目に、証拠、分類、信頼度タグ付きの回収可能額、担当者、修正内容、その修正クラスが記載されています。
• 照合できていない遷移と追跡されていないステップはすべて、修正予定日が設定された未計測項目として明記されています。黙って省略することは決してありません。
• 分析対象は、流入後を追跡した1つのコホートのみです。スナップショットの件数とコホートのフローを混在させていません。

4つすべてを満たすまで反復します。遷移を照合する前に計測機能の構築が必要な場合、レポートにその旨を記載し、再実行の予定を設定します。これは合格となる結果です。推測した数値は合格になりません。

よくある失敗パターン

欠陥	影響	対処法
コホートの時点を混在させる（スナップショット件数とコホートのフロー）	残差が算術上のノイズになり、漏れを捏造したり見落としたりします	1つの流入コホートを追跡し、同じ期間同士でのみ比較します
健全な対象外判定を漏れとして数える	検出結果が過大になり、営業チームがレポートを信用しなくなります	漏れと呼ぶ前に、3種類に分類します
計測の欠落をファネルの離脱と取り違える	壊れていないファネルを「修正」しようとして、何も改善しません	まず隣接するシステムに、進行を示す証拠があるか確認します
2度漏れたレコードを二重計上する	回収可能な合計が実態を上回り、信頼を失います	各レコードは、説明のつかない最初の離脱時に1度だけ数えます
パイプラインの総額を回収可能額として見積もる	財務部門がレポート全体を割り引いて評価します	回収可能額 ＝ レコード数 × 金額 × その時点から先へのコンバージョン率
システムの欠陥を営業担当者のせいにする	政治的な対立が起きて修正されず、漏れが続きます	履歴から別の担当者の責任だと確認できる場合を除き、残差は個人ではなくプロセス／システムの責任者に割り当てます
追跡されていないステップの数値を推測する	作り上げた数値がランキング全体の基準になります	計測されていないことを明記し、まず計測できるようにして、次回の実行で測定します
成果物がデータクレンジングのチェックリストになってしまう	データクレンジングのスキルと重複し、「実際にいくらの価値があるのか」という問いに答えません	すべての検出事項に、影響を受けるレコード数と回収可能額、または計測の修正を明記します

KPI

• 実行のたびに追跡します：
  • 移行ごとの説明のつかない残差の割合（合意した許容範囲に向けて推移していること）
  • 修正した漏れごとの回収額と、見積もった回収可能額との比較
  • タイムスタンプがあるファネルステップの割合（計測カバレッジ）
  • 漏れの確認から修正の責任者決定までの時間
• 回収額と見積額の比較は、見積もり方法自体の妥当性を確認するための指標です。実際の回収額が一貫して見積額を大きく下回る場合は、次回のレポートの前に、先へのコンバージョン率の前提を厳しく見直します。
• 成功指標として「発見した漏れの数」を報告しないでください。漏れのリストを膨らませることが報われてしまいます。

呼び出し例

• 「マーケティングチームは、前四半期に有望なリードを400件営業に渡したと言っていますが、営業側は250件しか受け取っていないと言っています。どこで案件を失っていて、損失はいくらですか？」
• 「トライアル登録数は安定していますが、有料コンバージョンが20％減少したのに、ファネルのどこで起きているのか誰にもわかりません。漏れを追跡してください。」
• 「口頭での合意から契約締結までの間に案件が消え、更新もそのまま期限切れになるようです。漏れを見つけ、実際に回収可能な額を教えてください。」

参考資料

• ファネルをマッピングするときは、references/leak-site-inventory.md をお読みください。流入から意図しない解約に至るまでのリーク箇所のカタログと、各箇所の検出シグナルおよび収集すべき証拠が記載されています。
• 回収可能な収益を見積もり、優先順位を付けるときは、references/sizing-recoverable-revenue.md をお読みください。回収可能額の計算式、後続コンバージョンの推定、信頼度タグ、優先順位付けのルールが記載されています。
• 成果物を作成するときは、references/worked-examples.md をお読みください。B2B の照合例、セルフサービス／PLG の照合例、誤ったレポートの例がそれぞれ 1 つずつ記載されています。
• 表面化している問題が、記録の消失ではなく予測数値の誤りである場合は、mbfinotti/revops-skills@sales-forecast-diagnostic を参照してください。
• リーク箇所の修正に割り当てロジックの再設計が必要な場合は、mbfinotti/revops-skills@lead-routing を参照してください。
• リーク箇所の修正にスコアの再設計が必要な場合は、mbfinotti/revops-skills@lead-scoring を参照してください。
• 引き継ぎに関するリークの修正として、セールスから CS への引き継ぎ自体を設計する必要がある場合は、mbfinotti/revops-skills@sales-to-cs-handoff を参照してください。