pipeline-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Pipeline Review

销售管道回顾

Pulls deal and meeting data from whatever system the user tracks their pipeline in, analyzes it over a chosen time period, and produces a report that answers the questions a founder, sales leader, or AE actually cares about: Are we booking enough? Are they qualified? Where are deals getting stuck? What's working and what isn't?

Two output modes:

Executive summary: 1-page snapshot. Numbers, trends, red flags. What a founder reads over morning coffee.
Detailed diagnostic: Full data tables, stage-by-stage breakdown, source analysis, stuck deal list, and specific recommendations.

Both are always produced. The executive summary sits at the top of the report.

从用户用于跟踪销售管道的任意系统中拉取交易和会议数据，在选定的时间段内进行分析，并生成一份能解答创始人、销售负责人或客户经理真正关心的问题的报告：我们的会议预约量足够吗？客户是否合格？交易卡在了哪个环节？哪些策略有效，哪些无效？

两种输出模式：

执行摘要： 1页快照，包含数据、趋势和风险预警，适合创始人在晨间浏览。
详细诊断报告： 完整的数据表格、分阶段拆解、渠道分析、停滞交易列表以及具体建议。

两种报告将同时生成，执行摘要位于报告顶部。

When to Auto-Load

自动加载场景

Load this composite when:

User says "review my pipeline", "pipeline report", "how's our pipeline looking", "deal review"
User says "1:1 prep", "board meeting prep", "weekly sales review"
An upstream workflow (Pipeline Ops, daily BDR rhythm) triggers an end-of-period review
User asks about meeting quality, conversion rates, or pipeline health

在以下场景下加载此组合工具：

用户提及“回顾我的销售管道”、“销售管道报告”、“我们的销售管道情况如何”、“交易回顾”
用户提及“1对1会议准备”、“董事会会议准备”、“每周销售回顾”
上游工作流（如管道运营、BDR日常节奏）触发周期末回顾
用户询问会议质量、转化率或销售管道健康度

Step 0: Configuration (One-Time Setup)

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

On first run, collect and store these preferences. Skip on subsequent runs.

首次运行时，收集并存储以下偏好设置，后续运行可跳过此步骤。

Data Source Config

数据源配置

Question	Options	Stored As
Where do you track your pipeline?	Salesforce / HubSpot / Pipedrive / Close / Supabase / Google Sheets / CSV / Notion / Other	`crm_tool`
How do we access it?	API / Export CSV / MCP tools / Direct query	`access_method`
What object represents a "deal" in your system?	Opportunity / Deal / Lead / Meeting / Custom	`deal_object`

问题	选项	存储字段
你使用什么系统跟踪销售管道？	Salesforce / HubSpot / Pipedrive / Close / Supabase / Google Sheets / CSV / Notion / 其他	`crm_tool`
我们如何访问该系统？	API / 导出CSV / MCP工具 / 直接查询	`access_method`
你的系统中哪个对象代表“交易”？	Opportunity / Deal / Lead / Meeting / 自定义	`deal_object`

Pipeline Stage Definitions

销售管道阶段定义

Question	Purpose	Stored As
What are your pipeline stages in order?	Map data to a standard funnel	`pipeline_stages`
Which stage means "qualified"?	Qualification rate calculation	`qualified_stage`
Which stage means "closed won"?	Win rate calculation	`won_stage`
Which stage means "closed lost"?	Loss analysis	`lost_stage`
What is your expected sales cycle length? (days)	Identify stuck deals	`expected_cycle_days`

Example stage mapping:

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

问题	目的	存储字段
你的销售管道阶段按顺序是哪些？	将数据映射到标准漏斗模型	`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

Field Mapping

字段映射

Different CRMs use different field names. Map the user's fields to standard analysis fields.

Standard Field	Purpose	Stored As	Examples
Deal name	Identification	`field_deal_name`	"Name", "Deal Name", "Opportunity Name"
Company	Account grouping	`field_company`	"Company", "Account", "Organization"
Stage	Funnel position	`field_stage`	"Stage", "Pipeline Stage", "Status"
Owner	Rep-level analysis	`field_owner`	"Owner", "Assigned To", "Rep"
Source	Channel attribution	`field_source`	"Lead Source", "Source", "Channel", "UTM Source"
Created date	Period filtering	`field_created_date`	"Created Date", "Created At", "Date Added"
Close date	Velocity tracking	`field_close_date`	"Close Date", "Expected Close", "Closed At"
Amount	Revenue analysis	`field_amount`	"Amount", "Deal Value", "ARR", "MRR"
Last activity date	Stale deal detection	`field_last_activity`	"Last Activity", "Last Modified", "Last Touched"
Meeting date	Meeting analysis	`field_meeting_date`	"Meeting Date", "Call Date", "Demo Date"
Qualification status	Qual rate	`field_qual_status`	"Qualified", "ICP Fit", "BANT Score"
Loss reason	Loss analysis	`field_loss_reason`	"Loss Reason", "Closed Lost Reason", "Disqualification Reason"

Not all fields are required. The analysis adapts to whatever data is available. Minimum viable: deal name + stage + created date.

不同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"

并非所有字段都是必需的，分析会根据可用数据自适应调整。最低要求：交易名称 + 阶段 + 创建日期。

Benchmarks (Optional)

基准指标（可选）

Question	Purpose	Stored As
What's your target meeting volume per week/month?	Compare actuals to goals	`target_meetings`
What's your target qualification rate?	Flag if below target	`target_qual_rate`
What's your target win rate?	Flag if below target	`target_win_rate`
What's your target pipeline value?	Revenue gap analysis	`target_pipeline_value`

Store config in:

clients/<client-name>/config/pipeline-review.json

or equivalent.

问题	目的	存储字段
你每周/每月的目标会议量是多少？	对比实际数据与目标	`target_meetings`
你预期的客户合格率是多少？	若低于目标则发出预警	`target_qual_rate`
你预期的赢单率是多少？	若低于目标则发出预警	`target_win_rate`
你预期的销售管道金额目标是多少？	收入缺口分析	`target_pipeline_value`

配置存储位置：

clients/<client-name>/config/pipeline-review.json

或等效路径。

Step 1: Pull Pipeline Data

步骤1：拉取销售管道数据

Purpose: Extract deal/meeting data from the configured CRM for the specified time period.

目的： 从已配置的CRM中提取指定时间段内的交易/会议数据。

Input Contract

输入约定

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

period: {
  type: "weekly" | "fortnightly" | "monthly" | "quarterly" | "custom"
  start_date: string              # ISO日期（根据类型自动计算，或由用户指定）
  end_date: string                # ISO日期（默认：今日）
  comparison_period: boolean      # 是否包含对比周期以分析趋势（默认：true）
}
crm_tool: string                  # 来自配置
access_method: string             # 来自配置
field_mapping: { ... }            # 来自配置

Process

处理流程

Based on

crm_tool

and

access_method

CRM	Access Method	How to Pull
Salesforce	API / CSV export	SOQL query or user uploads CSV export
HubSpot	API / CSV export	Deals API or user uploads CSV export
Pipedrive	API / CSV export	Deals API or user uploads CSV export
Close	API / CSV export	Leads/Opportunities API or CSV
Supabase	Direct query	Query deals/outreach_log tables
Google Sheets	Sheets API / CSV	Read sheet or user exports CSV
Notion	Notion MCP	Query database
CSV	File read	User provides file path

Pull two datasets:

Current period: All deals created or active within the specified date range
Comparison period: Same-length prior period (e.g., if reviewing last 2 weeks, also pull the 2 weeks before that)

根据

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周，则同时拉取之前2周的数据）

Data Standardization

数据标准化

Regardless of source, normalize all data into a standard structure:

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
  }
]

无论数据源是什么，将所有数据归一化为标准结构：

deals: [
  {
    id: string
    name: string
    company: string
    stage: string                   # 映射到pipeline_stages
    owner: string | null
    source: string | null           # 线索来源/渠道
    created_date: string            # ISO日期
    close_date: string | null       # ISO日期
    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  # 计算得出
    total_age_days: integer         # 根据created_date计算得出
  }
]

Output Contract

输出约定

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
}

pipeline_data: {
  current_period: {
    start_date: string
    end_date: string
    deals: [...]                    # 标准化交易记录
    deal_count: integer
  }
  comparison_period: {
    start_date: string
    end_date: string
    deals: [...]
    deal_count: integer
  } | null
}

Human Checkpoint

人工检查点

undefined

undefined

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)

---

来源: [CRM名称] 当前周期: [开始日期] 至 [结束日期] — X条交易对比周期: [开始日期] 至 [结束日期] — Y条交易可用字段: [已映射字段列表] 缺失字段: [未映射字段列表 — 分析将自适应调整]

数据是否正确？(Y/n)

---

Step 2: Analyze Pipeline

步骤2：分析销售管道

Purpose: Run the full analysis across seven dimensions. Pure computation + LLM reasoning — inherently tool-agnostic.

目的： 从七个维度进行全面分析，结合纯计算与LLM推理，天生具备工具无关性。

Input Contract

输入约定

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)

pipeline_data: { ... }               # 来自步骤1
pipeline_stages: string[]            # 来自配置
qualified_stage: string              # 来自配置
won_stage: string                    # 来自配置
lost_stage: string                   # 来自配置
expected_cycle_days: integer         # 来自配置
benchmarks: { ... } | null           # 来自配置（可选）

Analysis Dimensions

分析维度

Run all seven analyses on the current period data. Where comparison period exists, calculate period-over-period trends.

对当前周期数据执行全部七项分析。若存在对比周期，则计算环比趋势。

Analysis 1: Volume Metrics

分析1：数据量指标

Questions answered: How many meetings/deals did we book? Is the volume going up or down?

Metric	How to Calculate
Total deals created	Count deals with `created_date` in period
Meetings booked	Count deals that reached "Meeting Booked" stage or have a `meeting_date`
Meetings held	Count deals at or past "Meeting Held" stage
No-show rate	(Meetings booked - Meetings held) / Meetings booked
Period-over-period change	Compare to comparison period
vs. Target	Compare to `target_meetings` if set
Weekly run rate	Total / weeks in period

Output:

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
}

解答问题： 我们预约了多少会议/创建了多少交易？数据量是上升还是下降？

指标	计算方式
总创建交易数	统计 `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%" 或 "-8%"
    meetings_change: percentage
  } | null
  vs_target: {
    target: integer
    actual: integer
    gap: integer                      # 正数 = 超额，负数 = 缺口
  } | null
}

Analysis 2: Qualification Breakdown

分析2：客户合格情况拆解

Questions answered: How many meetings were qualified? Unqualified? What's our qualification rate?

Metric	How to Calculate
Qualified deals	Deals at or past `qualified_stage`
Unqualified deals	Deals that were closed lost before reaching `qualified_stage` , or deals marked as unqualified
Qualification rate	Qualified / (Qualified + Unqualified)
Pending qualification	Deals still between "Meeting Held" and `qualified_stage`
Disqualification reasons	Group `loss_reason` for deals lost pre-qualification
vs. Prior period	Compare qualification rate
vs. Target	Compare to `target_qual_rate` if set

Output:

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 }
  ]
}

解答问题： 多少会议对应的客户是合格的？不合格的有多少？我们的客户合格率是多少？

指标	计算方式
合格交易数	处于或超过 `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 }
  ]
}

Analysis 3: Source / Channel Attribution

分析3：来源/渠道归因

Questions answered: Where are leads coming from? Which sources produce the most qualified meetings?

Metric	How to Calculate
Deals by source	Group by `source` , count
Meetings by source	Group by `source` , count meetings
Qualification rate by source	For each source: qualified / total
Best source (volume)	Source with most deals
Best source (quality)	Source with highest qualification rate (min 5 deals for statistical relevance)
Source with highest conversion to won	Source with best close rate
Source trends	Compare to prior period

Output:

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
}

解答问题： 线索来自哪里？哪些渠道产生的合格会议最多？

指标	计算方式
按来源划分的交易数	按 `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   # 若单一渠道占比>60%则发出预警
}

Analysis 4: Stage Distribution & Velocity

分析4：阶段分布与流转速度

Questions answered: Where are deals sitting in the pipeline? How fast are they moving through stages?

Metric	How to Calculate
Deal count by stage	Group active deals by current `stage`
Revenue by stage	Sum `amount` per stage
Average days in each stage	For deals that passed through each stage, average `days_in_current_stage`
Stage-to-stage conversion	What % of deals move from one stage to the next
Pipeline velocity	(Deals × Win Rate × Avg Deal Size) / Avg Cycle Length
Total pipeline value	Sum of `amount` for all active deals
Weighted pipeline	Sum of (amount × stage probability) for each deal

Stage probability defaults (override with actual data if available):

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

Output:

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.
}

解答问题： 交易在销售管道的哪个阶段？它们在各阶段的流转速度如何？

指标	计算方式
按阶段划分的交易数	按当前 `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          # "符合预期", "比预期慢X天"等
}

Analysis 5: Stuck Deals & At-Risk Pipeline

分析5：停滞交易与高风险销售管道

Questions answered: Are there deals that have been sitting too long? What's at risk of going stale?

Metric	How to Calculate
Stuck deals	Deals where `days_in_current_stage` > 2× average for that stage, OR > `expected_cycle_days` total
No activity deals	Deals where `last_activity_date` > 14 days ago
Aging deals	Deals where `total_age_days` > 1.5× `expected_cycle_days`
At-risk revenue	Sum of `amount` for stuck + no activity + aging deals
Concentration risk	Any single deal > 30% of total pipeline value

Stuck deal threshold: A deal is "stuck" if it's been in its current stage for more than 2× the average time deals spend in that stage. If we don't have enough data for stage averages, use these defaults:

Stage	Expected Max Days
Lead	3 days
Meeting Booked	7 days
Meeting Held	5 days
Qualified	10 days
Proposal Sent	14 days
Negotiation	14 days

Output:

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
}

解答问题： 是否有交易停留时间过长？哪些交易有过期风险？

指标	计算方式
停滞交易	`days_in_current_stage` > 该阶段平均停留天数的2倍，或总时长 > `expected_cycle_days` 的交易
无活动交易	`last_activity_date` 超过14天的交易
老化交易	`total_age_days` > `expected_cycle_days` 的1.5倍的交易
高风险收入	停滞交易、无活动交易、老化交易的 `amount` 总和
集中度风险	单一交易金额占总销售管道金额>30%的情况

停滞交易阈值： 若交易在当前阶段的停留时间超过该阶段平均停留天数的2倍，则判定为“停滞”。若阶段平均数据不足，使用以下默认值：

阶段	预期最长停留天数
Lead	3天
Meeting Booked	7天
Meeting Held	5天
Qualified	10天
Proposal Sent	14天
Negotiation	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      # "跟进", "询问时间规划", "标记为不合格"
    }
  ]
  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
}

Analysis 6: Win/Loss Analysis

分析6：赢单/丢单分析

Questions answered: What's our win rate? Why are we losing deals?

Metric	How to Calculate
Win rate	Won / (Won + Lost) for deals closed in period
Win rate by source	Group by source
Win rate by owner	Group by rep
Average deal size (won)	Avg `amount` of won deals
Average time to close	Avg days from created to closed won
Top loss reasons	Group `loss_reason` , count
Loss stage distribution	At which stage are deals most often lost?
vs. Prior period	Compare win rate
vs. Target	Compare to `target_win_rate` if set

Output:

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 }
  ]
}

解答问题： 我们的赢单率是多少？为什么会丢单？

指标	计算方式
赢单率	周期内成交交易数 / (成交交易数 + 丢单交易数)
按来源划分的赢单率	按来源分组统计
按负责人划分的赢单率	按销售代表分组统计
平均成交金额	成交交易的 `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 }
  ]
}

Analysis 7: Forecast & Coverage

分析7：预测与覆盖度

Questions answered: Are we going to hit our number? Do we have enough pipeline to cover the target?

Only run this analysis if

target_pipeline_value

or revenue targets are configured.

Metric	How to Calculate
Pipeline coverage ratio	Weighted pipeline / remaining quota
Commit forecast	Sum of deals in Negotiation + Proposal stage
Best case forecast	Commit + Qualified deals × historical win rate
Gap to target	Target - best case forecast
Required deals to close gap	Gap / average deal size
Required meetings to close gap	Required deals / historical meeting-to-close rate

Output:

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

解答问题： 我们能完成目标吗？我们的销售管道金额足够覆盖目标吗？

仅当配置了

target_pipeline_value

或收入目标时才执行此分析。

指标	计算方式
销售管道覆盖比	加权销售管道金额 / 剩余配额
承诺预测	处于Negotiation和Proposal阶段的交易金额总和
最佳情况预测	承诺预测金额 + 合格交易数 × 历史赢单率
目标缺口	目标金额 - 最佳情况预测金额
填补缺口所需交易数	目标缺口 / 平均交易金额
填补缺口所需会议数	所需交易数 / 历史会议到成交的转化率

输出：

forecast: {
  target: number
  commit_forecast: number
  best_case_forecast: number
  gap_to_target: number
  pipeline_coverage_ratio: float     # 3倍及以上为健康，<2倍为风险
  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

Output Contract (Full Analysis)

输出约定（完整分析结果）

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

No human checkpoint after this step — the analysis feeds directly into report generation.

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

此步骤后无需人工检查，分析结果直接传入报告生成环节。

Step 3: Generate Report

步骤3：生成报告

Purpose: Transform the raw analysis into two report formats: an executive summary and a detailed diagnostic. Pure LLM reasoning.

目的： 将原始分析结果转换为两种报告格式：执行摘要和详细诊断报告，纯LLM推理。

Input Contract

输入约定

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

analysis: { ... }                     # 来自步骤2
benchmarks: { ... } | null            # 来自配置

Executive Summary Format

执行摘要格式

One page. Numbers and trends. What a founder or sales leader needs to see in 60 seconds.

undefined

1页内容，包含核心数据与趋势，创始人或销售负责人可在60秒内快速了解关键信息。

undefined

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

指标	本周期	上一周期	变化
已预约会议数	X	Y	+/-Z%
已举办会议数	X	Y	+/-Z%
客户合格率	X%	Y%	+/-Z个百分点
赢单率	X%	Y%	+/-Z个百分点
销售管道金额	$X	$Y	+/-Z%
平均交易金额	$X	$Y	+/-Z%
平均成交周期	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%]

[任何显著下降的指标]
[停滞交易超过阈值]
[销售管道覆盖度低于2倍]
[单一渠道占比>60%]
[爽约率超过20%]

Green Lights

积极信号

[Metrics trending up]
[Sources performing well]
[Stages moving faster than expected]

[上升的指标]
[表现良好的渠道]
[流转速度快于预期的阶段]

Top 3 Actions

三大优先行动

[Most impactful thing to do this week]
[Second most impactful]
[Third most impactful]

undefined

[本周最具影响力的行动]
[第二具影响力的行动]
[第三具影响力的行动]

undefined

Detailed Diagnostic Format

详细诊断报告格式

Full data tables, charts (as markdown tables), and commentary.

undefined

包含完整的数据表格、图表（以Markdown表格形式呈现）和分析说明。

undefined

Pipeline Diagnostic — [Period]

销售管道诊断报告 — [周期]

1. Volume

1. 数据量

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

[数据量指标表格] [分析说明：数据量是否符合预期？呈上升还是下降趋势？是否达成目标？]

2. Qualification

2. 客户合格情况

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

[客户合格情况拆解表格] [不合格原因表格] [分析说明：我们是否在与正确的客户沟通？有哪些常见的不合格原因需要解决？]

3. Source Effectiveness

3. 渠道有效性

[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

4. 阶段分布与流转速度

[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

5. 停滞交易

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

[停滞交易表格及建议行动] [无活动交易表格] [分析说明：高风险收入总额，停滞交易的常见模式]

6. Win/Loss Analysis

6. 赢单/丢单分析

[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)

7. 预测与覆盖度（若设置目标）

[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.]

undefined

[基于数据的具体、可落地建议列表，每条建议需引用驱动它的具体数据点]

undefined

Recommendations Logic

建议逻辑

Generate recommendations based on patterns found in the analysis:

Pattern	Recommendation
Qualification rate <40%	"Review ICP targeting — we're meeting with too many unqualified prospects. Top DQ reason is [X]. Consider tightening [source/criteria]."
No-show rate >20%	"Implement meeting confirmation flow — send reminders 24h and 1h before. Current no-show rate of X% is costing Y meetings/period."
One source >60% of pipeline	"Diversify lead sources — [source] drives X% of pipeline. If this channel underperforms, pipeline collapses. Test [alternative channels]."
High-quality source with low volume	"Scale [source] — it has a X% qualification rate (best in pipeline) but only Y% of volume. Invest more here."
Deals stuck in a specific stage	"Unblock [stage] — X deals averaging Y days (2× normal). Common pattern: [observation]. Recommended: [specific action]."
Win rate declining	"Win rate dropped from X% to Y%. Top loss reason shifted to [Z]. Consider: [specific response]."
Pipeline coverage <2x	"Pipeline coverage is [X]x against [target]. Need Z more qualified deals to close the gap. At current conversion rates, that requires W meetings."
Average cycle lengthening	"Deals are taking X days longer to close vs. prior period. Bottleneck is at [stage]. Consider: [specific action to accelerate]."
High loss rate at specific stage	"X% of losses happen at [stage]. This suggests [interpretation]. Consider: [action]."

根据分析中发现的模式生成建议：

模式	建议
客户合格率<40%	"重新审视ICP定位——我们与太多不合格的潜在客户沟通。主要不合格原因是[X]。考虑收紧[渠道/筛选标准]。"
爽约率>20%	"实施会议确认流程——在会议前24小时和1小时发送提醒。当前爽约率为X%，每个周期浪费Y场会议。"
单一渠道占比>60%	"多元化线索来源——[渠道]贡献了X%的销售管道。若该渠道表现不佳，销售管道将面临崩溃风险。测试[替代渠道]。"
高质量渠道但数据量低	"扩大[渠道]投入——其客户合格率为X%（管道内最佳），但仅占Y%的数据量。在此渠道加大投入。"
特定阶段存在停滞交易	"疏通[阶段]——X条交易平均停留Y天（为正常时长的2倍）。常见模式：[观察结果]。建议：[具体行动]。"
赢单率下降	"赢单率从X%降至Y%。主要丢单原因变为[Z]。考虑：[具体应对措施]。"
销售管道覆盖度<2倍	"销售管道覆盖度为[X]倍，目标为[目标金额]。需要Z个更多合格交易来填补缺口。按当前转化率，这需要W场会议。"
平均成交周期延长	"与上一周期相比，交易成交时间延长了X天。瓶颈在[阶段]。考虑：[加速流转的具体行动]。"
特定阶段丢单率高	"X%的丢单发生在[阶段]。这表明[解读]。考虑：[行动]。"

Output Contract

输出约定

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
    }
  ]
}

report: {
  executive_summary: string           # Markdown格式
  detailed_diagnostic: string         # Markdown格式
  recommendations: [
    {
      priority: "high" | "medium" | "low"
      area: string                    # "volume", "qualification", "source", "velocity", "stuck", "win_loss", "forecast"
      recommendation: string
      data_point: string              # 驱动该建议的具体指标
      expected_impact: string         # 解决该问题后的预期效果
    }
  ]
  stuck_deal_actions: [
    {
      deal_name: string
      company: string
      action: string
      owner: string | null
    }
  ]
}

Human Checkpoint

人工检查点

Present the executive summary first, then offer the detailed diagnostic:

[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?

先展示执行摘要，再提供详细诊断报告：

[执行摘要渲染结果]

---

同时提供完整的详细诊断报告。

本次回顾的行动项：
1. [高优先级建议]
2. [高优先级建议]
3. [中优先级建议]

需要立即处理的停滞交易：
| 交易 | 公司 | 阶段 | 停滞天数 | 行动 |
|------|---------|-------|------------|--------|
| ... | ... | ... | ... | ... |

是否需要查看完整的诊断报告？或对上述建议采取行动？

Step 4: Export & Share (Optional)

步骤4：导出与分享（可选）

Purpose: Save the report and optionally push it to the user's preferred location.

目的： 保存报告并可选推送到用户偏好的位置。

Process

处理流程

Based on user preference:

Destination	How
Markdown file	Save to `clients/<client>/reports/pipeline-review-{date}.md`
Google Sheets	Export data tables to a sheet (metrics, deal list, source breakdown)
Notion	Push to a Notion database page via Notion MCP
Slack	Send executive summary to a channel
Email	Send via agentmail
stdout	Just display it (default)

根据用户偏好执行：

目标位置	方式
Markdown文件	保存至 `clients/<client>/reports/pipeline-review-{date}.md`
Google Sheets	将数据表格导出到工作表（指标、交易列表、渠道拆解）
Notion	通过Notion MCP推送到Notion数据库页面
Slack	将执行摘要发送到指定频道
邮件	通过agentmail发送
标准输出	直接显示（默认）

Execution Summary

执行摘要

Step	Tool Dependency	Human Checkpoint	Typical Time
0. Config	None	First run only	5 min (once)
1. Pull Data	Configurable (CRM API, CSV, Supabase, etc.)	Verify data looks correct	1-2 min
2. Analyze	None (computation + LLM reasoning)	None — feeds directly to report	Automatic
3. Generate Report	None (LLM reasoning)	Review executive summary, drill into details	5-10 min
4. Export	Configurable (file, Sheets, Notion, etc.)	Optional	1 min

Total human review time: ~10-15 minutes for a full pipeline review that would normally take 30-60 minutes of manual CRM digging.

步骤	工具依赖	人工检查点	典型耗时
0. 配置	无	仅首次运行	5分钟（一次性）
1. 拉取数据	可配置（CRM API、CSV、Supabase等）	验证数据是否正确	1-2分钟
2. 分析	无（计算 + LLM推理）	无 — 直接传入报告生成	自动
3. 生成报告	无（LLM推理）	回顾执行摘要，按需查看详情	5-10分钟
4. 导出	可配置（文件、Sheets、Notion等）	可选	1分钟

人工总审核时间：~10-15分钟，而手动在CRM中挖掘数据完成一次完整的销售管道回顾通常需要30-60分钟。

Adapting to Data Availability

适配数据可用性

Not every CRM has every field. The analysis degrades gracefully:

Missing Field	What Gets Skipped	Analysis Still Works?
`amount`	Revenue metrics, weighted pipeline, forecast	Yes — volume and stage analysis still run
`source`	Source attribution (Analysis 3)	Yes — everything else still runs
`loss_reason`	Loss reason breakdown	Yes — win/loss rate still calculates
`owner`	Per-rep analysis	Yes — aggregate metrics still run
`last_activity_date`	No-activity deal detection	Partially — stuck deals still detected via stage duration
`close_date`	Velocity, avg days to close	Partially — stage distribution still works
Comparison period data	Period-over-period trends	Yes — single period analysis still produces full report

Minimum viable data for a useful report: Deal name + Stage + Created date. Everything else enriches but isn't required.

并非每个CRM都包含所有字段，分析会优雅降级：

缺失字段	跳过的分析内容	分析是否仍可运行？
`amount`	收入指标、加权销售管道、预测	是 — 数据量和阶段分析仍可运行
`source`	渠道归因（分析3）	是 — 其他所有分析仍可运行
`loss_reason`	丢单原因拆解	是 — 赢单/丢单率仍可计算
`owner`	按销售代表分析	是 — 聚合指标仍可运行
`last_activity_date`	无活动交易检测	部分可运行 — 仍可通过阶段时长检测停滞交易
`close_date`	流转速度、平均成交周期	部分可运行 — 阶段分布仍可分析
对比周期数据	环比趋势	是 — 单周期分析仍可生成完整报告

生成有用报告的最低数据要求： 交易名称 + 阶段 + 创建日期。其他字段仅用于丰富分析内容，非必需。

Cadence Guide

周期指南

Review Type	Period	Audience	Focus
Weekly standup	Last 7 days	Sales team	Volume, stuck deals, this week's priorities
Fortnightly review	Last 14 days	Sales leader	Qualification, source effectiveness, trends
Monthly review	Last 30 days	Founder / VP Sales	Full diagnostic, win/loss, forecast
Quarterly business review	Last 90 days	Leadership / Board	Trends, unit economics, strategic recommendations

The report depth automatically scales with the period length. A weekly review emphasizes volume and stuck deals. A quarterly review emphasizes trends, conversion rates, and strategic patterns.

回顾类型	周期	受众	重点
每周站会	过去7天	销售团队	数据量、停滞交易、本周优先级
每两周回顾	过去14天	销售负责人	客户合格情况、渠道有效性、趋势
每月回顾	过去30天	创始人 / 销售副总裁	完整诊断、赢单/丢单分析、预测
季度业务回顾	过去90天	管理层 / 董事会	趋势、单位经济效益、战略建议

报告深度会自动随周期长度调整。每周回顾重点关注数据量和停滞交易，季度回顾则重点关注趋势、转化率和战略模式。

Tips

小贴士

Run this at a consistent cadence. The value compounds — trends only become visible when you have multiple data points. A monthly review is 10x more useful when you can compare to the last 3 months.
Don't skip the stuck deals section. This is where the immediate ROI lives. Every stuck deal surfaced and unblocked is revenue accelerated.
Source attribution is the highest-leverage insight. Knowing that LinkedIn generates 3x the qualification rate of cold email means you should shift budget and effort. Most teams never run this analysis.
Watch for vanity metrics. "We booked 40 meetings" means nothing if qualification rate is 15%. Volume without quality is a waste of everyone's time.
The no-show rate is a hidden leak. Most teams track meetings booked but not meetings held. A 25% no-show rate means 1 in 4 meetings is wasted effort. Fix with confirmation sequences.
Pipeline coverage below 2x is a red flag. If you need $100K this quarter and your weighted pipeline is $150K, you probably won't make it. Healthy is 3x+.
Loss reason data is only useful if reps actually fill it in. If 80% of losses say "Other" or are blank, the loss analysis is meaningless. Fix data hygiene first.

保持固定的回顾周期：价值会持续积累——只有拥有多个数据点时，趋势才会显现。当你可以对比过去3个月的数据时，每月回顾的价值会提升10倍。
不要跳过停滞交易部分：这是即时ROI所在。每发现并疏通一笔停滞交易，就相当于加速了收入到账。
渠道归因是最高杠杆的洞察：如果LinkedIn的客户合格率是冷邮件的3倍，这意味着你应该转移预算和精力。大多数团队从未执行过这项分析。
警惕虚荣指标：“我们预约了40场会议”毫无意义，如果客户合格率只有15%。没有质量的数据量是在浪费所有人的时间。
爽约率是隐藏的漏洞：大多数团队跟踪已预约会议数，但不跟踪已举办会议数。25%的爽约率意味着每4场会议中就有1场是浪费的精力。通过确认流程解决这个问题。
销售管道覆盖度低于2倍是红色预警：如果你本季度需要10万美元，而加权销售管道只有15万美元，你很可能无法完成目标。健康的覆盖度是3倍及以上。
丢单原因数据只有在销售代表如实填写时才有用：如果80%的丢单原因是“其他”或空白，丢单分析将毫无意义。首先解决数据 hygiene 问题。