pipeline-review

パイプラインレビュー

ユーザーがパイプラインの管理に使っているシステムから商談とミーティングのデータを取得し、選択した期間について分析して、創業者、セールスリーダー、AEが実際に知りたい疑問に答えるレポートを作成します。十分な数の商談を獲得できているか。商談の質は十分か。商談が停滞しているのはどこか。何がうまくいっていて、何がうまくいっていないか。

2つの出力モード：

• エグゼクティブサマリー： 1ページの概要です。数値、傾向、警告事項をまとめます。創業者が朝のコーヒーを飲みながら読むレポートです。
• 詳細な診断： データテーブル全体、ステージごとの内訳、流入元の分析、停滞している商談の一覧、具体的な推奨事項をまとめます。

どちらも必ず作成します。エグゼクティブサマリーはレポートの先頭に配置します。

自動読み込みの条件

次の場合に、この複合ワークフローを読み込みます。

• ユーザーが「パイプラインをレビューして」「パイプラインレポート」「パイプラインの状況はどう？」「商談レビュー」と言った場合
• ユーザーが「1:1の準備」「取締役会の準備」「週次のセールスレビュー」と言った場合
• 上流のワークフロー（Pipeline Ops、日次のBDR業務リズム）が期間終了時のレビューを起動した場合
• ユーザーがミーティングの質、コンバージョン率、パイプラインの健全性について質問した場合

---

ステップ 0：設定（初回のみ）

初回実行時に、以下の設定を確認して保存します。2回目以降は省略します。

データソースの設定

質問	選択肢	保存先
パイプラインの管理には何を使っていますか？	Salesforce / HubSpot / Pipedrive / Close / Supabase / Google Sheets / CSV / Notion / その他	crm_tool
どのようにアクセスしますか？	API / CSV エクスポート / MCP ツール / 直接クエリ	access_method
お使いのシステムで「商談」を表すオブジェクトは何ですか？	Opportunity / Deal / Lead / Meeting / カスタム	deal_object

パイプラインのステージ定義

質問	目的	保存先
パイプラインのステージを順番に教えてください。	データを標準的なファネルに対応付ける	pipeline_stages
どのステージを「適格」とみなしますか？	適格率の計算	qualified_stage
どのステージを「受注」とみなしますか？	受注率の計算	won_stage
どのステージを「失注」とみなしますか？	失注分析	lost_stage
想定するセールスサイクルの長さは何日ですか？	停滞している商談の特定	expected_cycle_days

ステージ対応付けの例：

pipeline_stages: [
  "Lead",
  "Meeting Booked",
  "Meeting Held",
  "Qualified (Discovery Done)",
  "Proposal Sent",
  "Negotiation",
  "Closed Won",
  "Closed Lost"
]
qualified_stage: "Qualified (Discovery Done)"
won_stage: "Closed Won"
lost_stage: "Closed Lost"
expected_cycle_days: 30

フィールドの対応付け

CRMによってフィールド名は異なります。ユーザーのフィールドを標準的な分析フィールドに対応付けます。

標準フィールド	目的	保存先	例
商談名	識別	field_deal_name	"Name"、"Deal Name"、"Opportunity Name"
企業	アカウントのグループ化	field_company	"Company"、"Account"、"Organization"
ステージ	ファネル内の位置	field_stage	"Stage"、"Pipeline Stage"、"Status"
担当者	担当者ごとの分析	field_owner	"Owner"、"Assigned To"、"Rep"
流入元	チャネルのアトリビューション	field_source	"Lead Source"、"Source"、"Channel"、"UTM Source"
作成日	期間の絞り込み	field_created_date	"Created Date"、"Created At"、"Date Added"
成約日	商談の進捗速度の追跡	field_close_date	"Close Date"、"Expected Close"、"Closed At"
金額	売上分析	field_amount	"Amount"、"Deal Value"、"ARR"、"MRR"
最終アクティビティ日	古い商談の検出	field_last_activity	"Last Activity"、"Last Modified"、"Last Touched"
ミーティング日	ミーティング分析	field_meeting_date	"Meeting Date"、"Call Date"、"Demo Date"
適格性ステータス	適格率	field_qual_status	"Qualified"、"ICP Fit"、"BANT Score"
失注理由	失注分析	field_loss_reason	"Loss Reason"、"Closed Lost Reason"、"Disqualification Reason"

すべてのフィールドが必須ではありません。 分析は、利用可能なデータに合わせて調整されます。最低限必要なのは、商談名、ステージ、作成日です。

ベンチマーク（任意）

質問	目的	保存先
週／月あたりの目標ミーティング件数は？	実績と目標を比較します	target_meetings
目標の有資格率は？	目標を下回っている場合に通知します	target_qual_rate
目標の受注率は？	目標を下回っている場合に通知します	target_win_rate
目標のパイプライン金額は？	売上ギャップを分析します	target_pipeline_value

設定の保存先： clients/<client-name>/config/pipeline-review.json または同等の場所。

---

ステップ 1：パイプラインデータを取得する

目的： 指定された期間について、設定済みの CRM から案件／ミーティングのデータを抽出します。

入力契約

period: {
  type: "weekly" | "fortnightly" | "monthly" | "quarterly" | "custom"
  start_date: string              # ISO date (auto-calculated from type, or user-specified)
  end_date: string                # ISO date (default: today)
  comparison_period: boolean      # Include prior period for trend comparison (default: true)
}
crm_tool: string                  # From config
access_method: string             # From config
field_mapping: { ... }            # From config

処理

crm_tool と access_method に基づきます。

CRM	アクセス方法	取得方法
Salesforce	API ／ CSV エクスポート	SOQL クエリを実行するか、ユーザーが CSV エクスポートをアップロードします
HubSpot	API ／ CSV エクスポート	Deals API を使用するか、ユーザーが CSV エクスポートをアップロードします
Pipedrive	API ／ CSV エクスポート	Deals API を使用するか、ユーザーが CSV エクスポートをアップロードします
Close	API ／ CSV エクスポート	Leads／Opportunities API または CSV を使用します
Supabase	直接クエリ	deals／outreach_log テーブルにクエリを実行します
Google Sheets	Sheets API ／ CSV	シートを読み込むか、ユーザーが CSV をエクスポートします
Notion	Notion MCP	データベースにクエリを実行します
CSV	ファイルの読み取り	ユーザーがファイルパスを指定します

2 つのデータセットを取得します：

1. 現在の期間： 指定された日付範囲内に作成された、または有効なすべての案件
2. 比較期間： 同じ長さの直前の期間（例：直近 2 週間を確認する場合、その前の 2 週間のデータも取得します）

データの標準化

データソースにかかわらず、すべてのデータを標準的な構造に正規化します。

deals: [
  {
    id: string
    name: string
    company: string
    stage: string                   # Mapped to pipeline_stages
    owner: string | null
    source: string | null           # Lead source / channel
    created_date: string            # ISO date
    close_date: string | null       # ISO date
    last_activity_date: string | null
    meeting_date: string | null
    amount: number | null
    qualification_status: string | null
    loss_reason: string | null
    days_in_current_stage: integer  # Calculated
    total_age_days: integer         # Calculated from created_date
  }
]

出力契約

pipeline_data: {
  current_period: {
    start_date: string
    end_date: string
    deals: [...]                    # Standardized deal records
    deal_count: integer
  }
  comparison_period: {
    start_date: string
    end_date: string
    deals: [...]
    deal_count: integer
  } | null
}

人による確認ポイント

## Data Pulled

Source: [CRM name]
Current period: [start] to [end] — X deals
Comparison period: [start] to [end] — Y deals
Fields available: [list of mapped fields]
Fields missing: [any unmapped fields — analysis will adapt]

Data looks correct? (Y/n)

---

ステップ 2：パイプラインを分析する

目的： 7 つの観点から包括的な分析を実行します。純粋な計算と LLM による推論であり、特定のツールには依存しません。

入力契約

pipeline_data: { ... }               # From Step 1
pipeline_stages: string[]            # From config
qualified_stage: string              # From config
won_stage: string                    # From config
lost_stage: string                   # From config
expected_cycle_days: integer         # From config
benchmarks: { ... } | null           # From config (optional)

分析項目

現在の期間のデータに対して、7 つすべての分析を実行します。比較期間がある場合は、期間ごとの推移を算出します。

---

分析 1：件数指標

回答する質問： ミーティング／案件を何件獲得しましたか？件数は増加していますか、それとも減少していますか？

指標	算出方法
作成された案件の総数	期間内に created_date がある案件を数えます
予約されたミーティング	「Meeting Booked」ステージに到達した案件、または meeting_date がある案件を数えます
実施されたミーティング	「Meeting Held」ステージ以降の案件を数えます
無断欠席率	（予約されたミーティング数 - 実施されたミーティング数）/ 予約されたミーティング数
前期間比の変化	比較期間と比較します
目標との比較	設定されている場合、target_meetings と比較します
週あたりの実績ペース	総数 / 期間の週数

出力：

volume: {
  deals_created: integer
  meetings_booked: integer
  meetings_held: integer
  no_show_count: integer
  no_show_rate: percentage
  weekly_run_rate: float
  vs_prior_period: {
    deals_change: percentage          # "+15%" or "-8%"
    meetings_change: percentage
  } | null
  vs_target: {
    target: integer
    actual: integer
    gap: integer                      # Positive = ahead, negative = behind
  } | null
}

---

分析 2：適格性の内訳

回答する質問： ミーティングのうち、適格なものと不適格なものは何件ですか？適格率はどのくらいですか？

指標	算出方法
適格案件	qualified_stage 以降のステージにある案件
不適格案件	qualified_stage に到達する前に失注した案件、または不適格とマークされた案件
適格率	適格 / （適格 + 不適格）
適格性の判定待ち	「Meeting Held」と qualified_stage の間にある案件
不適格理由	適格と判定される前に失注した案件について、loss_reason をグループ化します
前期間との比較	適格率を比較します
目標との比較	設定されている場合、target_qual_rate と比較します

出力：

qualification: {
  qualified_count: integer
  unqualified_count: integer
  pending_count: integer
  qualification_rate: percentage
  vs_prior_period: percentage_change | null
  vs_target: { target: percentage, actual: percentage } | null
  top_disqualification_reasons: [
    { reason: string, count: integer, percentage: percentage }
  ]
}

---

分析 3：ソース／チャネルの帰属

回答する質問： リードはどこから来ていますか？ 最も多くの有望な商談を生み出しているソースはどれですか？

指標	計算方法
ソース別の案件数	source でグループ化して件数を数える
ソース別のミーティング数	source でグループ化してミーティング数を数える
ソース別の適格率	ソースごとに、適格な件数／合計件数
最良のソース（量）	案件数が最も多いソース
最良のソース（質）	適格率が最も高いソース（統計的な関連性を確保するため、最低 5 件の案件が必要）
成約率が最も高いソース	成約率が最も高いソース
ソースの傾向	前の期間と比較する

出力：

source_attribution: {
  by_source: [
    {
      source: string
      deals_created: integer
      meetings_booked: integer
      meetings_qualified: integer
      qualification_rate: percentage
      deals_won: integer
      win_rate: percentage
      revenue: number | null
      vs_prior_period: percentage_change | null
    }
  ]
  best_volume_source: string
  best_quality_source: string
  best_conversion_source: string
  source_concentration_warning: string | null   # Flag if >60% from one source
}

---

分析 4：ステージ分布と進行速度

回答する質問： 案件はパイプラインのどこにありますか？ ステージをどのくらいの速さで進んでいますか？

指標	計算方法
ステージ別の案件数	アクティブな案件を現在の stage でグループ化する
ステージ別の売上	ステージごとに amount を合計する
各ステージの平均滞在日数	各ステージを通過した案件について、days_in_current_stage の平均を計算する
ステージ間の転換率	あるステージから次のステージに進む案件の割合
パイプラインの進行速度	（案件数 × 成約率 × 平均案件規模）／平均サイクル期間
パイプラインの合計金額	すべてのアクティブな案件の amount を合計する
加重パイプライン	各案件の（amount × ステージ確率）を合計する

ステージ確率のデフォルト値（利用可能な場合は実際のデータで上書きします）：

Lead: 5%
Meeting Booked: 10%
Meeting Held: 20%
Qualified: 40%
Proposal Sent: 60%
Negotiation: 80%
Closed Won: 100%
Closed Lost: 0%

出力：

stage_analysis: {
  by_stage: [
    {
      stage: string
      deal_count: integer
      revenue: number | null
      weighted_revenue: number | null
      avg_days_in_stage: float
      conversion_to_next_stage: percentage
    }
  ]
  total_pipeline_value: number | null
  weighted_pipeline_value: number | null
  pipeline_velocity: number | null
  avg_cycle_length_days: float
  vs_expected_cycle: string          # "On pace", "X days slower than expected", etc.
}

---

分析 5：停滞案件とリスクのあるパイプライン

回答する質問： 長期間停滞している案件はありますか？ 停滞するリスクがある案件はどれですか？

指標	計算方法
停滞案件	days_in_current_stage がそのステージの平均の 2 倍を超える案件、または合計期間が expected_cycle_days を超える案件
活動のない案件	last_activity_date が 14 日以上前の案件
長期化した案件	total_age_days が expected_cycle_days の 1.5 倍を超える案件
リスクのある売上	停滞案件、活動のない案件、長期化した案件の amount の合計
集中リスク	単一の案件がパイプライン全体の価値の 30% を超えているか

停滞案件のしきい値： 現在のステージに、そのステージでの案件の平均滞在時間の 2 倍を超えて留まっている案件を「停滞」とします。ステージごとの平均を算出するのに十分なデータがない場合は、次のデフォルト値を使用します。

ステージ	想定される最大日数
リード	3 日
ミーティング予約済み	7 日
ミーティング実施済み	5 日
適格	10 日
提案送付済み	14 日
交渉中	14 日

出力：

stuck_and_at_risk: {
  stuck_deals: [
    {
      name: string
      company: string
      stage: string
      days_in_stage: integer
      expected_max_days: integer
      owner: string | null
      amount: number | null
      last_activity: string | null
      recommended_action: string      # "Follow up", "Ask for timeline", "Qualify out"
    }
  ]
  no_activity_deals: [
    {
      name: string
      company: string
      stage: string
      days_since_activity: integer
      owner: string | null
      recommended_action: string
    }
  ]
  at_risk_revenue: number | null
  concentration_risks: [
    { deal_name: string, amount: number, percentage_of_pipeline: percentage }
  ] | null
}

---

分析 6：成約／失注分析

回答する質問： 成約率はどのくらいですか？ 案件を失注する理由は何ですか？

指標	計算方法
成約率	期間中にクローズした案件について、成約数／（成約数＋失注数）
ソース別の成約率	ソースでグループ化する
オーナー別の成約率	担当者でグループ化する
成約案件の平均規模	成約案件の amount の平均
平均成約期間	作成から成約までの日数の平均
主な失注理由	loss_reason でグループ化して件数を数える
ステージ別の失注分布	案件が最も多く失注するステージ
前の期間との比較	成約率を比較する
目標との比較	target_win_rate が設定されている場合、目標と比較する

出力：

win_loss: {
  deals_won: integer
  deals_lost: integer
  win_rate: percentage
  vs_prior_period: percentage_change | null
  vs_target: { target: percentage, actual: percentage } | null
  avg_deal_size_won: number | null
  avg_days_to_close: float
  win_rate_by_source: [ { source: string, win_rate: percentage, count: integer } ]
  win_rate_by_owner: [ { owner: string, win_rate: percentage, count: integer } ] | null
  top_loss_reasons: [
    { reason: string, count: integer, percentage: percentage }
  ]
  loss_by_stage: [
    { stage: string, lost_count: integer, percentage: percentage }
  ]
}

---

分析 7：予測とカバレッジ

回答する質問： 目標を達成できそうですか？ 目標をカバーするのに十分なパイプラインがありますか？

この分析は、target_pipeline_value または売上目標が設定されている場合にのみ実行します。

指標	計算方法
パイプラインカバレッジ率	加重パイプライン／残りのノルマ
コミット予測	交渉中＋提案ステージの案件の合計
ベストケース予測	コミット＋適格案件 × 過去の成約率
目標との差	目標 - ベストケース予測
差を埋めるために必要な成約数	差／平均案件規模
差を埋めるために必要なミーティング数	必要な成約数／過去のミーティングから成約への転換率

出力：

forecast: {
  target: number
  commit_forecast: number
  best_case_forecast: number
  gap_to_target: number
  pipeline_coverage_ratio: float     # 3x+ is healthy, <2x is risky
  deals_needed_to_close_gap: integer
  meetings_needed_to_close_gap: integer
  coverage_assessment: "Healthy (3x+)" | "Adequate (2-3x)" | "At risk (<2x)" | "Critical (<1x)"
} | null

---

出力仕様（全分析）

analysis: {
  period: { type, start_date, end_date }
  volume: { ... }
  qualification: { ... }
  source_attribution: { ... }
  stage_analysis: { ... }
  stuck_and_at_risk: { ... }
  win_loss: { ... }
  forecast: { ... } | null
}

このステップの後に人間によるチェックポイントはありません。分析結果はレポート生成に直接渡されます。

---

ステップ 3：レポートを生成する

目的： 生の分析結果を、エグゼクティブサマリーと詳細な診断の2つの形式にまとめます。LLM による推論のみで行います。

入力仕様

analysis: { ... }                     # From Step 2
benchmarks: { ... } | null            # From config

エグゼクティブサマリーの形式

1ページ。数値と傾向を示します。創業者や営業責任者が60秒で把握する必要がある情報です。

# Pipeline Review — [Period Type]: [Start Date] to [End Date]

## Snapshot
| Metric | This Period | Prior Period | Change |
|--------|------------|-------------|--------|
| Meetings booked | X | Y | +/-Z% |
| Meetings held | X | Y | +/-Z% |
| Qualification rate | X% | Y% | +/-Z pts |
| Win rate | X% | Y% | +/-Z pts |
| Pipeline value | $X | $Y | +/-Z% |
| Avg deal size | $X | $Y | +/-Z% |
| Avg days to close | X | Y | +/-Z |

## Red Flags
- [Any metric trending down significantly]
- [Stuck deals above threshold]
- [Pipeline coverage below 2x]
- [Single source >60% of pipeline]
- [No-show rate above 20%]

## Green Lights
- [Metrics trending up]
- [Sources performing well]
- [Stages moving faster than expected]

## Top 3 Actions
1. [Most impactful thing to do this week]
2. [Second most impactful]
3. [Third most impactful]

詳細な診断の形式

すべてのデータテーブル、グラフ（Markdown テーブル形式）、解説を含みます。

# Pipeline Diagnostic — [Period]

## 1. Volume
[Volume metrics table]
[Commentary: is volume on track? Trending up or down? Meeting goals?]

## 2. Qualification
[Qualification breakdown table]
[Disqualification reasons table]
[Commentary: are we meeting with the right people? Common DQ reasons to address?]

## 3. Source Effectiveness
[Source attribution table — sorted by qualification rate]
[Commentary: which channels are working? Which are wasting time?
 Where should we invest more? Where should we cut?]

## 4. Stage Distribution & Velocity
[Stage breakdown table with counts, revenue, avg days, conversion rates]
[Commentary: where is the pipeline fat? Where is it thin?
 Is velocity healthy or slowing?]

## 5. Stuck Deals
[Stuck deals table with recommended actions]
[No-activity deals table]
[Commentary: total at-risk revenue, common patterns in stuck deals]

## 6. Win/Loss Analysis
[Win rate table — overall, by source, by owner]
[Loss reasons table]
[Loss by stage table]
[Commentary: why are we losing? At which stage? Any patterns?]

## 7. Forecast & Coverage (if targets set)
[Forecast table]
[Coverage assessment]
[Commentary: will we hit the number? What needs to happen?]

## Recommendations
[Numbered list of specific, actionable recommendations based on the data.
 Each recommendation should cite the specific data point that drives it.]

推奨事項のロジック

分析で見つかったパターンに基づいて推奨事項を生成します。

パターン	推奨事項
適格率が40%未満	「ICP ターゲティングを見直してください。適格でない見込み客との面談が多すぎます。最も多い DQ 理由は[X]です。[流入元／基準]をより厳格にすることを検討してください。」
無断欠席率が20%超	「面談確認のフローを導入してください。24時間前と1時間前にリマインダーを送信します。現在の無断欠席率 X% により、期間あたり Y 件の面談が失われています。」
1つの流入元がパイプラインの60%超を占める	「リードの流入元を多様化してください。[流入元]がパイプラインの X% を生み出しています。このチャネルの成績が落ちると、パイプラインが崩壊します。[代替チャネル]を試してください。」
件数は少ないが質の高い流入元	「[流入元]を拡大してください。適格率は X%（パイプライン内で最高）ですが、ボリュームは Y%にとどまっています。ここへの投資を増やしてください。」
特定のステージで案件が停滞	「[ステージ]の停滞を解消してください。X 件の案件が平均 Y 日滞留しています（通常の2倍）。共通するパターン：[所見]。推奨事項：[具体的な対策]。」
成約率が低下	「成約率が X% から Y% に低下しました。主な失注理由は[Z]に変化しました。次の対応を検討してください：[具体的な対応]。」
パイプラインカバレッジが2倍未満	「パイプラインカバレッジは目標[目標値]に対して[X]倍です。この差を埋めるには、適格な案件がさらに Z 件必要です。現在のコンバージョン率では、W 件の面談が必要です。」
平均営業サイクルが長期化	「案件の成約までに、前期間より X 日長くかかっています。ボトルネックは[ステージ]です。加速するための具体的な対策を検討してください。」
特定のステージで失注率が高い	「失注の X% が[ステージ]で発生しています。これは[解釈]を示唆しています。[対策]を検討してください。」

出力仕様

report: {
  executive_summary: string           # Markdown formatted
  detailed_diagnostic: string         # Markdown formatted
  recommendations: [
    {
      priority: "high" | "medium" | "low"
      area: string                    # "volume", "qualification", "source", "velocity", "stuck", "win_loss", "forecast"
      recommendation: string
      data_point: string              # The specific metric that drove this recommendation
      expected_impact: string         # What fixing this would do
    }
  ]
  stuck_deal_actions: [
    {
      deal_name: string
      company: string
      action: string
      owner: string | null
    }
  ]
}

人間によるチェックポイント

まずエグゼクティブサマリーを提示し、その後、詳細な診断を案内します。

[Executive Summary rendered]

---

Full detailed diagnostic is also available.

Actions from this review:
1. [High priority recommendation]
2. [High priority recommendation]
3. [Medium priority recommendation]

Stuck deals requiring immediate attention:
| Deal | Company | Stage | Days Stuck | Action |
|------|---------|-------|------------|--------|
| ... | ... | ... | ... | ... |

Want to see the full diagnostic? Or take action on any of these recommendations?

---

ステップ 4：エクスポートして共有する（任意）

目的： レポートを保存し、必要に応じてユーザーが指定した場所に送信します。

プロセス

ユーザーの希望に基づきます。

保存先	方法
Markdown ファイル	clients/<client>/reports/pipeline-review-{date}.md に保存します
Google Sheets	データテーブル（指標、案件リスト、流入元の内訳）をシートにエクスポートします
Notion	Notion MCP 経由で Notion データベースページに送信します
Slack	エグゼクティブサマリーをチャンネルに送信します
メール	agentmail 経由で送信します
stdout	そのまま表示します（デフォルト）

---

実行概要

ステップ	ツールの依存関係	人間によるチェックポイント	目安時間
0. 設定	なし	初回実行時のみ	5分（1回）
1. データを取得	設定可能（CRM API、CSV、Supabase など）	データが正しいことを確認	1～2分
2. 分析	なし（計算＋LLM による推論）	なし。レポートに直接渡されます	自動
3. レポートを生成	なし（LLM による推論）	エグゼクティブサマリーを確認し、詳細を掘り下げます	5～10分
4. エクスポート	設定可能（ファイル、Sheets、Notion など）	任意	1分

人間によるレビューの合計時間：約10～15分。通常なら CRM を手作業で調べるのに30～60分かかる、パイプライン全体のレビューを行えます。

---

データの利用可否への対応

すべての CRM にすべてのフィールドがあるわけではありません。分析は、データが不足していても適切に機能します。

不足しているフィールド	省略される内容	分析は引き続き機能しますか？
amount	売上指標、加重パイプライン、予測	はい — 件数とステージの分析は引き続き実行されます
source	ソースのアトリビューション（分析 3）	はい — それ以外の分析はすべて引き続き実行されます
loss_reason	失注理由の内訳	はい — 受注／失注率は引き続き算出されます
owner	担当者ごとの分析	はい — 集計指標は引き続き算出されます
last_activity_date	アクティビティのない案件の検出	一部 — ステージ滞在期間を基に停滞案件は引き続き検出されます
close_date	成約までの速度、平均成約日数	一部 — ステージ分布は引き続き確認できます
比較期間のデータ	期間ごとの傾向	はい — 単一期間の分析でも完全なレポートを作成できます

有用なレポートを作成するための最低限のデータ： 案件名 + ステージ + 作成日。それ以外の情報は分析を充実させますが、必須ではありません。

---

レビューの頻度ガイド

レビューの種類	期間	対象者	焦点
週次スタンドアップ	過去 7 日間	営業チーム	件数、停滞案件、今週の優先事項
隔週レビュー	過去 14 日間	営業責任者	適格性、ソースの有効性、傾向
月次レビュー	過去 30 日間	創業者 / 営業担当 VP	全体診断、受注／失注、予測
四半期ビジネスレビュー	過去 90 日間	経営陣 / 取締役会	傾向、ユニットエコノミクス、戦略的な提言

レポートの詳細度は、期間の長さに応じて自動的に調整されます。週次レビューでは、件数と停滞案件を重視します。四半期レビューでは、傾向、コンバージョン率、戦略的なパターンを重視します。

---

ヒント

• 一定の頻度で実行してください。 データが蓄積されるほど価値も高まります。複数のデータポイントがあって初めて、傾向が見えてきます。過去 3 か月と比較できれば、月次レビューの有用性は 10 倍になります。
• 停滞案件のセクションを飛ばさないでください。 即効性のある ROI はここにあります。停滞案件を見つけて解消するたびに、収益化を早められます。
• ソースのアトリビューションは、最も大きな効果が期待できる分析です。 LinkedIn の適格化率がコールドメールの 3 倍だと分かれば、予算と労力を振り向けるべきです。ほとんどのチームは、この分析を実施していません。
• 見栄えだけの指標に注意してください。 「40 件のミーティングを設定した」としても、適格化率が 15% なら意味がありません。質を伴わない件数は、関係者全員の時間の無駄です。
• 無断欠席率は見えにくい損失要因です。 多くのチームは設定したミーティングを追跡しますが、実際に開催されたミーティングは追跡していません。無断欠席率が 25% なら、4 件に 1 件のミーティングが無駄になっています。確認メッセージのシーケンスで改善してください。
• パイプラインカバレッジが 2 倍未満なら、危険信号です。 今四半期に 10 万ドルが必要なのに、加重パイプラインが 15 万ドルしかない場合、目標を達成できない可能性が高いです。健全な水準は 3 倍以上です。
• 失注理由のデータは、担当者が実際に入力して初めて役立ちます。 失注の 80% が「その他」または空欄なら、失注分析に意味はありません。まずデータの品質を改善してください。