pipeline-review

Pipeline 评审

从用户用于跟踪 Pipeline 的系统中提取交易和会议数据，按所选时间段进行分析，并生成一份报告，解答创始人、销售负责人或 AE 真正关心的问题：我们的签约量够吗？这些交易符合要求吗？交易卡在哪个环节？哪些做法有效，哪些无效？

两种输出模式：

• **执行摘要：**1 页概览，展示数据、趋势和风险信号。适合创始人在晨间喝咖啡时阅读。
• **详细诊断：**完整数据表、逐阶段分析、来源分析、停滞交易列表和具体建议。

始终同时生成两种模式。执行摘要置于报告顶部。

自动加载时机

在以下情况加载此组合：

• 用户说“评审我的 Pipeline”“Pipeline 报告”“我们的 Pipeline 情况如何”“交易评审”
• 用户说“准备 1:1”“准备董事会会议”“每周销售评审”
• 上游工作流（Pipeline Ops、每日 BDR 工作节奏）触发周期末评审
• 用户询问会议质量、转化率或 Pipeline 健康状况

---

步骤 0：配置（一次性设置）

首次运行时，收集并保存以下偏好。后续运行时跳过。

数据源配置

问题	选项	保存为
你在哪里跟踪 Pipeline？	Salesforce / HubSpot / Pipedrive / Close / Supabase / Google Sheets / CSV / Notion / 其他	crm_tool
我们如何访问？	API / 导出 CSV / MCP 工具 / 直接查询	access_method
在你的系统中，哪个对象代表“交易”？	商机 / 交易 / 潜在客户 / 会议 / 自定义	deal_object

Pipeline 阶段定义

问题	用途	保存为
你的 Pipeline 阶段按顺序分别是什么？	将数据映射到标准漏斗	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

将配置存储在当前工作目录中，或存储在用户指定的位置。

---

步骤 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	读取文件	用户提供文件路径

提取两组数据：

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：分析销售管道

目的： 从七个维度进行全面分析。纯计算 + 大模型推理，天然与工具无关。

输入约定

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)

分析维度

针对当前周期数据完成全部七项分析。如果存在对比周期，则计算周期环比趋势。

---

分析 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
加权销售管道	对每笔交易计算（金额 × 阶段概率）并求和

默认阶段概率（如果有实际数据，则以实际数据为准）：

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：生成报告

目的： 将原始分析转化为两种报告格式：执行摘要和详细诊断。纯大模型推理。

输入约定

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

执行摘要格式

一页。展示数字和趋势，让创始人或销售负责人在 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 定向——我们接触了太多不合格的潜在客户。最常见的不合格原因是 [X]。考虑收紧 [来源/标准]。”
未出席率 >20%	“实施会议确认流程——提前 24 小时和 1 小时发送提醒。目前 X% 的未出席率导致每个周期损失 Y 场会议。”
单一来源占管道 >60%	“拓宽潜在客户来源——[来源] 占管道的 X%。如果该渠道表现不佳，管道就会崩溃。测试 [替代渠道]。”
高质量来源但数量较少	“扩大 [来源]——其资格认定率为 X%（管道中最高），但仅占总量的 Y%。在此投入更多资源。”
交易卡在特定阶段	“疏通 [阶段]——X 笔交易平均耗时 Y 天（正常时长的 2 倍）。常见模式：[观察结果]。建议：[具体行动]。”
赢单率下降	“赢单率从 X% 降至 Y%。主要输单原因变为 [Z]。建议：[具体应对措施]。”
管道覆盖率 <2x	“管道覆盖率为 [X]x，目标为 [target]。还需要 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 文件	保存到当前工作目录
Google Sheets	将数据表（指标、交易列表、来源细分）导出到工作表
Notion	通过 Notion MCP 推送到 Notion 数据库页面
Slack	将执行摘要发送到频道
电子邮件	通过 AgentMail API (agentmail.dev) 或其他电子邮件 API 发送
stdout	直接显示（默认）

---

执行摘要

步骤	工具依赖	人工检查点	典型耗时
0. 配置	无	仅首次运行	5 分钟（一次性）
1. 拉取数据	可配置（CRM API、CSV、Supabase 等）	确认数据看起来正确	1-2 分钟
2. 分析	无（计算 + 大模型推理）	无——直接用于生成报告	自动
3. 生成报告	无（大模型推理）	查看执行摘要，深入了解详情	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 天	创始人／销售副总裁	全面诊断、赢单／输单、预测
季度业务审查	过去 90 天	领导层／董事会	趋势、单位经济效益、战略建议

报告深度会根据周期长度自动调整。每周审查侧重数量和停滞商机。季度审查侧重趋势、转化率和战略模式。

---

提示

• 按固定频率运行。 价值会不断累积 — 只有积累多个数据点后，趋势才会显现。能够与过去 3 个月对比时，月度审查的价值会高出 10 倍。
• 不要跳过停滞商机部分。 这里蕴藏着即时投资回报。每个被发现并疏通的停滞商机，都会加快收入实现。
• 来源归因是杠杆效应最高的洞察。 如果知道 LinkedIn 带来的资格认定率是冷邮件的 3 倍，就应该调整预算和投入。大多数团队从未进行过这项分析。
• 警惕虚荣指标。 “我们约了 40 场会议”毫无意义，如果资格认定率只有 15%。只有数量而没有质量，就是在浪费所有人的时间。
• 未出席率是一个隐蔽的漏洞。 大多数团队会追踪已预约的会议，却不追踪实际举行的会议。25% 的未出席率意味着每 4 场会议就有 1 场白费力气。通过确认流程来解决。
• 销售管道覆盖率低于 2 倍是危险信号。 如果本季度需要 $100K，而加权销售管道只有 $150K，很可能无法达成目标。健康水平应达到 3 倍以上。
• 只有销售代表确实填写输单原因数据时，这些数据才有用。 如果 80% 的输单原因都是“其他”或空白，输单分析就毫无意义。先改进数据卫生。