sales-pipeline-hygiene

パイプラインの健全性

現在アクティブなパイプラインにある案件を監査します。停滞案件、クローズ日の変更に関する異常、予測に不可欠なフィールドの欠落を確認し、フラグが付いた案件ごとに処置の決定を1つずつ定め、是正およびコミュニケーション計画と、測定可能な合格基準を添えた例外リストにまとめます。オーナーシップは共有ではなく、3者に分かれています（ORM）。

• RevOps は定義、スナップショット、自動化、公開前のデータパッケージを担当します。
• 現場のマネージャーは案件ごとの処置決定とコーチングの会話を担当します。
• 担当者は更新と証拠を担当します。

この分担によって議論の余地がなくなります。マネージャーは、具体的なルールに違反した具体的なレコードを手にして臨むのであり、漠然とした不満を伝えるわけではありません。別の分け方をすると、時間どおりに終わるだけで何も変わらない会議が生まれます。

監査の根幹となる定義の選択は、まずここから始まります。意味のある活動とは、Stage、Close Date、またはAmountの変更を指し、記録された通話やメールではありません（ORM）。記録された接点はCRM上の活動ではありますが、案件が前進したことを示すものではありません。そのため、これを基準にしたルールは、進展がなくても満たすことができ、まさにそのせいで停滞したパイプラインがレビューを何度もすり抜けます。これは実務者の間で現在も意見が分かれている点です（多くのツールは最終活動日を基準にします）。フィールド変更の定義をデフォルトとし、最終活動日を独立した第2のトリガーとして使用してください。2つを併用しますが、相互に置き換えてはいけません。

対象範囲の境界

監査の範囲が広がらないよう、成果物に次の点を明記してください。

• これは、現在パイプラインにある案件を対象とする定期監査です。停滞を防ぐための常設の自動リマインダー／ナッジシステムを設計するのは別の仕事です。監査では、定期チェックの自動化を推奨し、引き継ぎ先を説明してもかまいませんが、アラートのタイミング、チャネル、通知疲れへの対策は設計しません。
• ステージの定義や終了基準の監査または書き換えは行いません。それは mbfinotti/revops-skills@pipeline-stage-definition-audit の対象です。健全性監査では既存のステージ構成を前提とし、その中にある案件を調べます。
• 予測全体の信頼性の診断は行いません。それは mbfinotti/revops-skills@sales-forecast-diagnostic の対象です。健全性監査はクリーンなデータを提供しますが、予測手法を修正するものではありません。
• 全社的なフィールドのオーナーシップや信頼できる情報源のポリシーは定めません。それは mbfinotti/revops-skills@crm-data-governance の対象です。健全性監査では、既存フィールドの入力状況を確認します。
• ファネルにおける収益漏れの追跡は行いません。それは mbfinotti/revops-skills@revenue-leakage の対象です。

インタビュー

監査を始める前に質問します。1メッセージにつき1つの質問とし、可能な場合は選択式にします。すでに回答済みの項目は省略します。

• 信頼できる唯一の記録システムから、何をエクスポートまたは照会できますか？オープン案件のステージ、金額、クローズ予定日、担当者、最終活動日、作成日、次のステップは取得できますか？ステージ変更履歴はありますか？クローズ予定日の変更履歴はありますか？特定時点のスナップショットはありますか？
• このパイプラインを構成する営業モデルとセグメントは何ですか？SMB／高頻度、中堅企業、大企業、B2C／トランザクション型、PLGの営業支援型、混合型などですか？セグメントごとの一般的な営業サイクル期間と案件規模はどのくらいですか？
• すでにどのような定例会議がありますか？週次の予測会議、パイプラインレビュー、QBR、ディールデスクなどですか？監査はこれらに組み込んで行います。新たな会議を追加してはいけません。
• 予測やパイプラインの判断で、実際に参照されるフィールドはどれですか？（完全性の確認対象となるのはすべてのフィールドではなく、これらのフィールドです。）
• 「停滞」の定義や、データの衛生管理ルールを書面で定めていますか？運用されていますか？誰が徹底させていますか？
• 結果をいつまでに出す必要がありますか？QBR、予測会議、取締役会向け数値などが期限でしょうか？週の途中に期限がある場合、同日中に実施できる改善策（入力規則、リマインダーなど）が優先され、インテグレーションが必要なものは後回しになります。
• 今回は一度限りのクリーンアップ（QBR前、予測前、新任リーダーの着任時など）ですか？それとも定期的な運用の開始ですか？自動取得のコストに見合うのは、定期運用がある場合です。一度限りの実施では自動取得は構築されず、次の四半期に同じ手作業を繰り返すことになります。
• 労力の上限はどのくらいですか？担当者が案件ごとに受け入れられる追加の負担、管理者が設定に使える時間、マネージャーが週ごとのレビューに使える時間はどのくらいですか？すでに負担の限界に達しているチームでは、完全性の不足状況にかかわらずリマインダーは対象外になります。また、レビューに使える時間が少ない場合、バルク対応と会話による対応の配分はバルク側に傾きます（references/disposition-and-communication.mdを参照）。
• 担当者と一緒に例外リストを確認するマネージャーは誰ですか？対応結果の処理を完了させる責任者は誰ですか？
• 大規模なクリーンアップを実施したことはありますか？その際、担当者はどのような反応をしましたか？アカウントを確保するためだけに登録された、初期段階の「口約束だけ」の案件はありますか？
• CRMのデータ衛生、フィールドの入力完了率、または予測精度に連動する報酬は現在ありますか？

ワークフロー

1. インタビューを実施します。監査範囲を確定します。基準日を明示し、その時点でオープン中のすべての商談を対象とします。そのスナップショットを固定し、処置は変動する案件一覧ではなく、そのスナップショットに基づいて決定します。

2. データを抽出します。パイプラインデータを直接照会できる場合は、オープン中の商談に加え、ステージ変更履歴、クローズ日の変更履歴、アクティビティレコードを取得します。できない場合は、これらの列名を指定してエクスポートを依頼します。その後、測定を始める前にデータをクレンジングして標準化します（Umbrex の監査順序）。

   • カスタムステージを標準の順序に対応付けます。
   • テストレコードを削除します。
   • 欠落しているステージ到達日を補完します。
   • 通貨とタイムゾーンを統一します。

3. まず停滞層の規模を把握します。停滞の4区分（最後の意味のある変更（ORM）から90日未満／90～180日／180～365日／365日超）を使います。365日超の区分を除外してカバレッジを再計算します。その値と公表カバレッジとの差が、報告によって四半期の実績がどれほど誇張されていたかを示す正確な指標です。パイプライン価値の20～30％を超える部分が停滞している場合は、何らかの強制措置を講じる前に、パイプラインの一斉整理を予定します（references/disposition-and-communication.md を参照）。

4. 停滞層を除外したうえで、12～18か月分の受注済み履歴からセグメントごとのベースラインを導き出します。測定前にクレンジングします。大量の死に体の案件を抱える案件グループは、実際の有望案件よりも成約曲線が長く平坦になり（ORM）、監査の基礎となる中央値そのものが歪むためです。ステージごと、セグメントごとにステージ滞在日数の中央値を算出します（平均値ではなく中央値）。

5. セグメントごとにしきい値を設定します。SMB／成約速度の速いセグメントでは中央値の約1.5倍から、エンタープライズでは2.0倍までを目安にします。あわせて鮮度の期間と再設定のトリガーも定めます（以下の「検出ルール」を参照。導出方法と代替策はreferences/detection-rules.md を参照）。

6. スナップショットに3つのルール群を適用します。該当したルールごとに商談1件あたり1行を出力し、該当の根拠を記載します。

7. フラグを商談ごとの例外リストにまとめ、パイプライン価値を付記します。再設定が2回目の商談と、複数のフラグが付いた商談を上位に配置します。

8. 以下の分類に基づき、フラグが付いた商談ごとに処置案を提示します。RevOps が提案し、マネージャーと担当者が決定します。フラグ付けを自動削除にしてはならず、担当者が自分の仕事を自分で評価することも認めません。決定した処置にはすべて、担当者を明記し、理由を記録します。

9. 何かを強制したり自動化したりする前に、コミュニケーション計画を作成します。例外リストは、その内容を検討する会議の少なくとも12時間前に公開します。レポートの取得から始まる会議は、すでに失敗しています（ORM）。詳細はreferences/disposition-and-communication.md を参照してください。

10. 監査レポートを（以下の「出力形式」に従って）セクションごとに出力し、ユーザーの検証を受けます。

11. KPI を計算して合格基準を確認します。基準を満たすまで、または未達分を次回の監査に回すまで、処置と是正措置を繰り返します。

12. 定期監査を既存の定例業務に組み込み（以下の「実施頻度」を参照）、定期チェックの自動化を提案します。監査から引き継ぐ予防レイヤーは、通知からエスカレーションへ進むシステムです。参考となる仕組みは、Jeff Ignacio（RevOps Impact）の方式です。

    • クローズ予定日を過ぎたら、担当者にメッセージを送ります。
    • リマインダーの回数を加算します。
    • 3回目のリマインダーでマネージャーを加えます。

    この引き継ぎ内容の説明は対象範囲に含まれますが、システムの設計は含まれません（「範囲の境界」を参照）。

13. ハーネスに永続メモリがある場合は、ベースライン、しきい値、各区分の規模、例外の件数を保存し、次回の監査で再度インタビューするのではなく、傾向を把握した状態から開始できるようにします。

ケイデンス — 既存の習慣を活用し、会議を増やさない

• 週次フォーキャストコール：過去14日間に意味のある活動がないコミット済み案件をRevOpsが提示し、担当者が買い手のエンゲージメントを示す証拠を提示します。提示できない場合、その案件はコミットから外れます（ORM）。
• 担当者ごとの隔週パイプラインレビュー。四半期最終月は週次で実施し、事前公開された例外リストに基づいて、経過期間の長い案件、初期段階の案件、停滞案件に対応します。
• 四半期ごとのテリトリー見直しは、期間終了のおよそ2週間前に行い、次の四半期のカバレッジを測定する前に整理を完了します。
• 後期段階の案件、標準外の案件、またはフラグ付き案件（ステージの再設定、案件の分割）にはディールデスクを設けます。通常の整理には使いません。
• 経営幹部を担当者レベルのパイプラインレビューに参加させないでください。経営幹部がいると、担当者はリスクを明らかにするのではなく、パイプラインを弁護するようになります（ORM）。担当者はマネージャーとのセッションに参加し、経営陣には集約結果を共有します。

検知ルール

上記で定義した「意味のある活動」を読み取るルールは、3つのファミリーに分かれます。各しきい値には必ず根拠を明記してください。数値は実務者向けの出発点であり、ユーザー自身のデータを使って調整します。

• 停滞案件 - 独立した2つのトリガーを組み合わせて使います。

  • ステージ滞在期間：該当セグメントのステージ滞在日数の中央値の1.5～2.0倍を超えた案件にフラグを立てます。この倍率は好みの問題ではなく、セグメントによって異なります。SMB／高回転型では約1.5倍、ミッドマーケットでは1.5～2.0倍、エンタープライズでは2.0倍です（Umbrex、Outreach、DealHubで見解が一致）。
  • 最終活動からの経過日数：ミッド／後期ステージで14日間活動がない場合にフラグを立てます（Umbrex、Outreach）。非活動の経験則として、SMBでは14～21日、ミッドマーケットでは30～45日、エンタープライズでは60～90日でフラグを立てます。ただし、法務および調達のレビューは明示的に除外します（DealHub）。
  • 次のステップの日付が過去になっている場合や、今後予定されているミーティングがない場合もフラグを立てます。

  停滞案件はすべて4つのバケットに分類します。ORMの12か月ルールは真に失注した層を示す指標です。受注曲線では、52週間を過ぎると意味のある期待値が残らないことはほとんどありません。

• クローズ日の延長に関する異常 - 記憶に頼らず、フィールドとして延長回数を追跡します。フィールド履歴から案件ごとのクローズ日の変更回数を数えます。

  • 2回目の延長がエスカレーションのトリガーです（ORMによると、遅延を最もよく予測する単一の指標は、営業担当者がクローズ日を変更することです。対応すべきなのは2回目の延長です）。この時点で案件をマネージャーの確認対象にします。
  • 四半期をまたぐ延長は、同じ四半期内での日程調整より深刻です。期間の境界をまたぐクローズ日変更には、必ず理由の記載を求めます。
  • 延長が3回以上の場合は、失格に値します（SalesOpsClub）。

  クローズ日フィールドではなく、根拠の確認によって遅延と失注を区別します。「この日付が現実的になるまでに、何が起きる必要がありますか？」と尋ねてから、次のシグナルを組み合わせます。

  • 日付と担当者が設定された相互合意型アクションプランの進捗状況。
  • マルチスレッド化の度合い。
  • 経済的購買決定者の関与。
  • 調達／法務プロセスへの移行。
  • 推進者の応答性。

  次のステップが遅れているだけなら問題ない場合もあります。しかし、クローズ日の延長、単一担当者への依存、予算への懸念が重なると、介入が必要であることを説明できる状況になります。延長が確認できたら、根拠を記したメモを添えて、すぐにクローズ日を更新します。最悪なのは、案件に介入しながら予測を更新しないことです。

• フィールドの入力完全性 - スキーマ全体ではなく、予測に不可欠なフィールドだけを確認します。

  • 次のステップとその日付、クローズ日、金額、ステージ、予測カテゴリ、失注クローズ時の失注理由に加え、予測で実際に参照される資格確認フィールドがあれば対象にします。
  • 金額、ステージ、クローズ日は最も価値の高い対象です。これらは「意味のある活動」そのものを表すフィールドです。

  予測に不可欠なフィールドの入力完全性は90～95％を目標とし、最低ラインは80％です。効率性の高い順に、ステージゲート付き入力検証ルール > 担当者へのリマインダー > 自動取得の順で是正します。この順序の根拠となる3つの軸とその数値は、references/detection-rules.mdに記載されています。

  • 最初に検討するのは入力検証ルールです。管理者の作業時間は約1時間で、後期ステージへの進行時にのみ実行されるため、営業担当者の負担は数秒です。予測で参照されるフィールドだけを的確に保護でき、誤作動した場合は無効にできます。必須フィールドは何かが入力されたことを確認するのに対し、入力検証ルールは入力内容が妥当かどうかを確認します。
  • 必須フィールドの増加はこのリストに含めません。順位を最下位にするのではなく、選択肢から除外します。必須項目が多すぎると、「該当なし 該当なし 該当なし」のようなプレースホルダーが大量に作られ、正直な空欄よりも悪い状態になります。シグナルがあるように見えてしまうためです。オブジェクトごとの必須フィールドは5～7個を上限にしてください。
  • 自動取得は、この順序では優先度が最も低くなります。入力の手間を恒久的になくせますが、統合プロジェクトと同意のレビューが必要なため、比較するたびにリマインダーのほうが優先されます。すでにデータ取得ツールが導入されている場合や、営業担当者の負担が限界に達していて、これ以上リマインダーを追加できない場合は、自動取得の優先度を上げてください。

  この順序は既定の指針であり、絶対ではありません。Interviewの回答と、実際に施策を実行する担当者に照らして順位を見直してください。

処置

フラグが付いた案件はそれぞれ、処置、担当者、記録された理由が1つずつ決まった状態でレビューを終えます。停滞案件の作業リストでは、受け入れられる回答は2つだけです。実際の次のステップと検証済みのクローズ予定日を設定して再開するか、案件をクローズする（ORM）かです。

処置	該当する状況
失注としてクローズし、実際の理由コードを記録する	買い手側に進行中の購買プロセスを示す証拠がない。実情は「成立しない」
ナーチャリングに移す	将来的な関心は本物だが、現時点で進行中の購買プロセスはない
ステージを前に戻す	案件自体は実在するが、ステージが買い手の実際の状況を誇張している
根拠に基づいて日付を変更する	日付は誤っているが案件は進行中。新しい日付は「最初に何が起きる必要があるか」への回答である
名前付きの次のステップと日付を設定して維持する	フラグの原因はデータ不足であり、失注案件ではない。レコードを修正する

この表では、意図的に順序を付けていません。各行は、同じ結果に至る競合する手段ではなく、買い手側の証拠が裏付ける異なる案件状態です。効率性で並べると、根拠のない精密さを装うことになります。

標準外のステージ変更や案件分割は、ディールデスクを通してください。削除はせず、分類してください。削除すると、次回の監査で学びを得るための記録が失われ、履歴とコンバージョンの基準値が損なわれます。また、一般的なCRMのごみ箱で保持される期間は短いものです。再び戻ってきた買い手には、クローズ済み失注案件にリンクした新しいレコードを作成するのがデフォルトです。元の案件を再オープンしても同じ回復を実現できますが、コストが高く、取り消しもできません。この方針を覆すのは、明示された2つの条件に限ります。詳しくはreferences/disposition-and-communication.mdを参照してください。

B2B と B2C／高回転型／PLG

実質的な違いは閾値ではありません。分析単位、自動化が許容される度合い、そして適格性確認をCRMで行うかどうかです。

• B2B（長期サイクル、高ACV、購買委員会）：パイプラインレビューで案件ごとに確認します。倍率は2.0倍とし、エンタープライズ案件では60～90日まで反応がなくても許容します。適格性確認の詳細はCRMフィールド（推進者、経済的決裁者、契約手続き）に記録します。スリッページでは、プッシュ回数と四半期の境界をまたぐ日付変更に注目します。
• 高回転型／B2C：案件ごとのレビューに代えて、集計ルールと例外ベースの自動化を用います。倍率は約1.5倍、フラグの閾値は14～21日、ステージ数は3～5です。事前に適格性確認された初期ステージに限り、最終活動日を参照して誤検知を避け、営業リーダーの承認を得たうえで自動クローズすることは許容されます。プッシュ回数よりも、回転率とコンバージョン率の閾値が重要です。
• 純粋なPLG：見込み客は利用状況を通じて自ら適格性を示し、セルフサービスの案件はプロダクト内で成約します。そのため、従来型の案件パイプライン、ひいては営業担当者向けのデータ整備監査が、そもそも不要な場合があります。監査を無理に実施せず、その旨を伝えてください。データ整備の重点は、プロダクトシグナルとPQLの振り分けに移ります。

すべての営業形態で共通する点：

• 意味のある活動の定義（記録された接触ではなく、フィールドの変更）。
• 削除せずに分類すること。
• 必須フィールドではなく、検証ルールを使うこと。
• 取り締まるのではなく、コーチングを行う姿勢。

共通のSLAの仕組み：各ステージの最長経過日数を、サイクルの基準期間に比例して設定します。SLA違反時にはマネージャーのレビュー対象として自動タグ付けします。信頼を損なうため、自動クローズは決して行いません。

出力形式

簡潔なひな形です。誤った監査例を含む詳しい記入例は、references/audit-report-examples.mdを参照してください。

PIPELINE HYGIENE AUDIT - <pipeline>, as-of <date>
Definitions   : meaningful activity = stage/close date/amount change;
                per-segment thresholds with provenance
Stale layer   : value by bucket (<90 / 90-180 / 180-365 / >365d);
                headline coverage vs coverage excluding >365 bucket;
                amnesty recommended yes/no
Summary       : deals audited, flagged, % of pipeline value flagged
Exception list: deal | owner | flags | evidence | proposed disposition |
                decided disposition | disposition owner | reason
Field gaps    : field | % complete vs 90-95% target | decision it feeds |
                fix (validation rule / nudge - not new required fields)
Push report   : push-count distribution; second-push deals at top with
                stacked-signal evidence and "what has to happen" answers;
                quarter-boundary pushes with stated reasons
Remediation   : actions, owners, due dates
Communication : rituals the audit rides on; exception list published >=12h
                ahead; who is told what before enforcement
KPIs          : baseline vs target per KPI, pass/fail, next audit date

よくある失敗

失敗	結果	対策
記録された通話やメールを基準に停滞を判定する	商談が進展しなくてもルールを満たし、停滞したパイプラインがレビューのたびに残る	ステージ／クローズ日／金額の変更を基準にし、最終アクティビティを第2のトリガーにする
すべてのセグメントに単一のしきい値を適用する	エンタープライズでは過剰にフラグが立ち、SMBでは見落としが増える	セグメントごとの中央値と倍率を設定する
データを整理する前に測定する	停滞した案件群がクローズ率曲線を平坦化し、ベースラインが損なわれる	停滞した層を除外してから、中央値とカバレッジを算出する
RevOpsが「CRM警察」になる／自動クローズ、自動削除	不信感が生まれ、実際の活動がCRMの外に移り、正直な報告が罰せられる	マネージャーのレビュー用に自動タグ付けする。取り締まりの前に猶予期間を設け、コーチングを重視する
フラグが立った案件を削除する	次回の監査に役立つはずの記録が失われ、ベースラインと担当者の指標が損なわれる	分類はしても、削除はしない
誰にも知らされていないルールを適用する	担当者はフラグが立って初めてルールを知り、ルールの抜け道を探し始める	まずルールとしきい値を公開し、例外リストは12時間前に共有する
必須フィールドを増やせば入力率が上がると考える	「TBD」／「.」／「123」といった質の低いデータが大量に発生する	必須項目は5〜7個までにする。まずステージに応じた検証ルールを設け、次に入力を促す
フィールドの入力完了に報酬を連動させる	速くて入力漏れはないが、データの質が低い	報酬をデータ衛生に連動させる場合でも、入力完了（インプット）ではなく、予測精度（アウトカム）に連動させる
四半期末にクローズ日を操作する	監査を通過するために日付が大量に編集され、予測が事実とかけ離れる	期間の境界をまたぐ日程変更には理由の明記を必須にし、インセンティブを見直す
目標を意図的に低く設定する	報酬やノルマの都合で商談が保留されたり、タイミングを調整されたりする	四半期末（EOQ）のクローズ集中率が20〜25%なら健全です。1人の担当者で35%を継続的に超える場合は、コンプライアンスの問題ではなく報酬設計について話し合います（Avoma）
楽観視しすぎる	コミット案件が失注したり、判断保留になったりするのを40〜60%まで見過ごし、対応が遅れる	根拠に基づいて予測カテゴリーを設定し、複数のシグナルを組み合わせて検証する
日程変更された案件をすべて停滞案件とみなす	実際に遅れている案件が打ち切られ、法務／調達の遅延が誤って分類される	根拠を確認する。法務／調達の審査期間は対象外とする
「ツバをつけた」まま放置された案件	主張だけで実態のない記録が放置され、マーケティング施策やテリトリーの変更を妨げる	主張だけの案件に対する明確な処理ルールを設ける
データ衛生スコアを見栄えだけのKPI／監査の形骸化に使う	スコアは改善しても予測は改善せず、同じ問題が毎年続く	予測に連動するKPIで評価する。30日を超えて繰り返す例外は、会議を増やすのではなくシステムルールにする

KPI と合格基準

各監査で、また監査をまたいだ傾向として追跡し、それぞれに出典を示します。

• 停滞した案件の金額 ÷ オープンパイプラインの金額：健全な水準は20～30％未満、後半ステージでの停滞は15％未満です（Umbrex）。4つの停滞期間区分ごとの分布も追跡します。
• 実質的なカバレッジ：ヘッドラインのカバレッジと、365日超の区分を除いたカバレッジの差を追跡し、その差が縮小しているか確認します。
• 失注・先送り率（予測対象の案件が期間外に持ち越された割合）：目標は20％未満です。30％を継続的に超える場合、案件の適格性評価や規律にシステム上の問題があることを示します（Revenue.io）。
• 先送り回数の分布：先送り0回／1回／2回以上の案件の割合、ならびに理由が明示された四半期末の先送りと、理由が明示されていないものの割合。
• 予測に重要なフィールドの入力完了率：目標は90～95％、下限は80％です（Saber、Komo/DAMA）。
• 次のステップが将来の日付で設定されているオープン案件の割合：中核指標です。公開されている数値ではなく、ユーザー自身の基準値から目標を設定します。
• クローズ日の正確性：クローズした案件のうち、CRM 上のクローズ日が実際の日付と許容範囲内で一致した案件の割合です（ORM の基準では14日以内です。自社のデータに基づいて許容範囲を狭めます）。
• 担当者ごとの四半期末クローズ集中度：サンドバッギングを監視する指標です。

合格基準 — 最初の監査で基準値を設定し、目標は公開数値ではなく、その基準値をもとに定めます。以下を満たした場合、監査は合格です。

• フラグが付いた案件すべてについて、担当者と理由を明確にした処置が決定されていること — 未解決がゼロであること。
• 監査終了時点で、クローズ日を過ぎたオープン案件がゼロであること。
• 2回目の先送り、または四半期末の先送りがある案件のうち、証拠に基づく回答が記録されていないものがゼロであること。
• 停滞案件の金額の割合、実質的なカバレッジとの差、入力完了率、次のステップの設定率がすべて、基準値と比べて合意した目標に向けて改善していること。

4つすべてを満たすまで繰り返します。関係者に衛生状態に関する統計（「パイプラインの40～60％が停滞している」など）を伝える前に、references/evidence-and-benchmarks.md の信頼性フラグを確認してください。この分野の数値情報の多くは、予測ツールを販売するベンダーに由来します。

任意の連携に関する注記

ユーザーが次のプラットフォームのいずれかを指定した場合を除き、省略してください。

• Salesforce：ごみ箱に削除済みレコードが保持されるのは15日間のみです。そのため、実務上、削除は取り消せません。また、先送り回数を再構成できるようにするには、フィールド履歴の追跡をフィールドごとに事前に有効にしておく必要があります。
• Pipedrive：ステージごとの「腐敗」日数のしきい値は標準機能であり、導出した停滞のしきい値を直接設定できます。

呼び出し例

• 「QBR の前なのに、パイプラインが使い物にならない案件だらけです。この案件の半分は何か月も動いていません。衛生状態を監査して、クローズするもの、維持するもの、ナーチャリングに回すものを教えてください。」
• 「ステージ履歴とクローズ日の変更履歴があるオープン案件の CSV です。停滞しているもの、何度も先送りされているもの、次のステップが欠けているものをすべてフラグ付けしてください。」
• 「私のコミットにある3件の案件は、それぞれクローズ日が2回ずつ先送りされています。案件全体を監査して、先送りの異常を見つけ、マネージャーが担当者と確認できる例外リストを作成してください。」

参考資料

• 基準値の計算とルールの実行時には、references/detection-rules.md を参照してください。意味のある活動の定義、セグメントごとの中央値テーブル、導出方法、履歴がない場合の代替策、プレースホルダーの検出、担当者が決まっているだけの案件の検出が記載されています。
• 処置の決定と展開計画の作成時には、references/disposition-and-communication.md を参照してください。各処置の証拠確認、理由コードの設計、パイプラインの一斉整理期間、レコードの再開と新規作成のデフォルトルールおよびそれを変更する2つの条件、一斉対応と個別対話の使い分け、コミュニケーション計画が記載されています。
• 成果物をまとめる際には、references/audit-report-examples.md を参照してください。B2B の監査、高速回転型の監査、誤った監査の例がそれぞれ1件ずつ記載されています。
• 数値を引用する前に、references/evidence-and-benchmarks.md を参照してください。ベンダーの利害に関する注意点を含め、各しきい値と統計の出典および信頼性フラグが記載されています。