Dashboard Data Sources¶

定义 Dashboard 每个 tab 展示的数据从哪个表取、怎么算。每个指标标注来源表、SQL 逻辑和参考值。

数据架构：新表（contacts、calls、messages）直写 Neon PostgreSQL 作为写入层兼查询层；已有表（call-analysis、LeadTracking-v2）仍以 DDB 为主，Neon 读取侧迁移是 Phase 三目标。跨表聚合（如联系次数、员工维度指标）通过 Neon SQL JOIN 实现。

状态图例：以下图例适用于全文所有表格。

状态	含义
✅ Auto	数据可用，系统自动计算（含 Neon SQL 聚合）
⚠️ Inferred	系统可推断（基于规则或关联数据，需积累）
🔘 Manual	V1 可做，但需员工手动输入
🤖 AI	需 AI 分析输出
❌ 无数据	V1 无数据支撑，无法实现

一、Lead 数据与指标计算¶

本节定义前端 Lead Tracker 页面和 Dashboard Leads tab 展示的所有数据及其来源和计算方式。

1.1 数据来源¶

前端 Lead 相关数据来自 3 个表：

数据	来源表	说明
9 个 Lead Status 当前值	contacts	`leadStatus` 字段
Lead 状态变更历史	contact_timeline	`event_type='contact.lifecycle_changed'`，`oldValue` / `newValue` 记录每次状态流转
Lead Temp（Hot / Warm / Cold / N/A）	contacts + API 计算	基于 `createdAt` + `leadStatus` 实时计算
Incoming Leads 总数	leads	`COUNT(*)`
Excluded（Malformed / Duplicated）	leads	phone 格式无效或重复，未进入 contacts 表
Valid Leads	leads - Excluded	Incoming - Malformed - Duplicated

1.2 Lead Status 定义（前端展示 9 个）¶

#	状态	English	值	Lifecycle State	V1 就绪	定义
1	新线索	New	`new`	Active	✅ Auto	Lead 进入系统时自动设置
2	联系中	Attempted	`attempted`	Active	✅ Auto	call-analysis 检测到外呼记录后自动更新
3	已触达	Connected	`connected`	Active	✅ Auto	call-analysis 检测到接通后自动更新
4	已预约	Booked	`booked`	Active	🤖 AI	AI 从通话内容识别预约意图后更新
5	条件性拒绝	Bad Timing	`bad_timing`	Frozen	🤖 AI	AI 从通话内容识别条件性拒绝
6	绝对拒绝	Not Interested	`not_interested`	Terminal	🤖 AI	AI 从通话内容识别明确拒绝
7	无法触达	Unreachable	`unreachable`	Terminal	⚠️ Inferred	温度冷掉 + 从未接通（系统规则推断）
8	失联	Lost Contact	`lost_contact`	Terminal	⚠️ Inferred	温度冷掉 + 曾接通后完全失联（系统规则推断）
9	漏跟	Neglected	`neglected`	Terminal	⚠️ Inferred	温度冷掉 + 活跃状态跟进未完成（系统规则推断）

后端存储但前端不展示的 3 个状态：showed、trialed、converted — 依赖线下数据（门店签到、课程管理、POS），V1 暂不支持。

1.3 Lead Tracker Pipeline 页面¶

顶栏汇总¶

前端展示名	计算方式	来源表
INCOMING LEADS	`COUNT(*) FROM leads`	leads
VALID LEADS	Incoming - Excluded	leads
INCOMING → BOOKED	`COUNT(leadStatus='booked') ÷ COUNT(*) FROM leads`	contacts + leads

Active 行（当前仍在漏斗中）¶

直接读 contacts.leadStatus 当前值。

前端展示名	计算方式	来源表
Active（汇总）	New + Attempted + Connected + Booked	contacts
New	`COUNT(leadStatus='new')`	contacts
Attempted	`COUNT(leadStatus='attempted')`	contacts
Connected	`COUNT(leadStatus='connected')`	contacts
Booked	`COUNT(leadStatus='booked')`	contacts

Drop-off 行（已掉出漏斗）¶

前端展示名	总数计算	来源表
Drop-off（汇总）	Unreachable + Neglected + Lost Contact + Bad Timing + Not Interested	contacts
Unreachable	`COUNT(leadStatus='unreachable')`	contacts
Neglected	`COUNT(leadStatus='neglected')`	contacts
Lost Contact	`COUNT(leadStatus='lost_contact')`	contacts
Bad Timing	`COUNT(leadStatus='bad_timing')`	contacts
Not Interested	`COUNT(leadStatus='not_interested')`	contacts

Excluded 行（未进入 contacts）¶

前端展示名	计算方式	来源表
Excluded（汇总）	Malformed + Duplicated	leads
Malformed Number	leads 中 phone 格式无效，未创建 contact	leads
Duplicated Number	leads 中 phone 重复	leads

占比计算¶

占比	分母	说明
Active/Drop-off 各项 "% of valid"	Valid Leads	进入 contacts 表的有效 Lead 总数
Excluded 各项 "% of incoming"	Incoming Leads	leads 表总数

1.4 Dashboard Leads tab¶

Dashboard → Leads tab 页面从上到下由 4 个区域组成：

① Lead Funnel（流图）¶

5 阶段漏斗流图（Incoming → Validation → Outreach → Reached → Booking），展示 Active / Excluded / Dropped 三色带。

每个阶段的数字 = 经过该阶段的 Lead 总数（当前仍在该阶段的 Active + 从该阶段掉出的 Drop-off）。计算依赖 leads 表（Incoming/Excluded）、contacts 表（当前 leadStatus）和 contact_timeline 表（判断 Drop-off 归属阶段）。

漏斗阶段	计算方式	来源表
Incoming	`COUNT(*) FROM leads`	leads
Validation	Incoming - Excluded	leads
Outreach	Validation - 从 Validation 掉出的 Drop-off	leads + contacts + timeline
Reached	Outreach - 从 Outreach 掉出的 Drop-off	contacts + timeline
Booking	Reached - 从 Reached 掉出的 Drop-off	contacts + timeline

从 Validation 掉出 = leadStatus='neglected' 且 timeline oldValue.leadStatus='new'（从未尝试联系）

从 Outreach 掉出 = timeline oldValue.leadStatus='attempted' 的 Unreachable / Neglected / Not Interested

从 Reached 掉出 = timeline oldValue.leadStatus='connected' 的 Bad Timing / Not Interested / Lost Contact / Neglected

从 Booking 掉出 = timeline oldValue.leadStatus='booked' 的 Bad Timing / Not Interested / Lost Contact

详细的 Drop-off 按阶段归属规则见 §1.2 Pipeline 页面。

② KPI Bar（指标卡片栏）¶

当前展示 2 个卡片：

前端展示名	公式	参考值	来源
Median Response Time	`Median(firstAttemptedAt − createdAt)`	< 5 min	contacts.createdAt + calls 派生 firstAttemptedAt
Booking Rate by Response Time	按响应时间分桶（≤5min / 5–30min / 30min–1h / >1h），算每桶的 Booking Rate	—	同上 + contacts.leadStatus

隐藏但数据就绪：Reach Rate、Booking Rate、Neglect Rate — 后端可计算，暂不在 KPI Bar 展示。

为什么用 Median 而不是 Average

响应时间容易出现极端值（如周末进来的 Lead 周一才联系），Average 会被少数 outlier 拉高，不能真实反映团队执行水平。Median（中位数）取排序后正中间的值，不受极端值影响。

示例：5 个 Lead 响应时间 2min, 3min, 5min, 8min, 45min → Average = 12.6min（被 45min 拉高），Median = 5min（真实水平）。

firstAttemptedAt 从 calls 表派生：MIN(start_time) WHERE contact_phone=? AND direction='Outbound'。

③ Bad-Timing Reason Breakdown（条件性拒绝原因分布）¶

横向条形图，展示 leadRejectionReasons 各标签的频次分布。

前端展示名	公式	来源
Bad-Timing Reason Breakdown	contacts 中 `leadStatus='bad_timing'` 的 `leadRejectionReasons` 各标签 COUNT	contacts

详见 Lead Funnel 与 Status 汇总。

二、Tasks 指标¶

行动产生了什么结果？ Task 连接"员工行动"与"业务结果"。两种类型：Lead Outreach（Lead 进入时即时生成）和 Follow-up（Cross-Call AI 每日凌晨批量生成）。

完整设计见 Tasks Overview，场景规则见 Follow-up Task 生命周期。

Task 生成机制与去重规则

两个生成入口：

入口	触发时机	触发条件
Lead Outreach	Lead 进入系统时即时触发	Lead 从未被联系过
Follow-up	每日凌晨 Cross-Call AI 批量	AI 判定 `actionNeeded` = true

Per-Call Analysis 不直接生成 Task。Per-Call 结果写入 call-analysis 表，供 Daily Batch 综合判断。

去重规则：一个客户同一时间最多一个 active Task。

Task 生成前检查
     │
     ▼  该客户（phone）是否有 active Task？
     │
     ├── 有 → 不生成新 Task
     │       更新现有 Task 的内容：
     │       - suggestedActions（AI 新建议列表）
     │       - 截止时间（根据最高 priority 调整）
     │
     └── 没有 → 生成新 Task

典型生命周期：

Lead 进入 → 生成 Lead Outreach 任务
Daily Batch 发现已有 active Lead Outreach → 不重复生成，可更新建议
员工 Complete Lead Outreach → 次日 Daily Batch 发现无 active Task → AI 判定需跟进 → 生成 Follow-up
员工 Complete Follow-up → 次日 AI 再判 → 如果还需要 → 生成新 Follow-up
AI 判定 actionNeeded = false 且有 active Task → 系统自动 cancel

2.1 数据来源¶

所有 Tasks 指标的数据全部来自 tasks 表（callytics-common/src/db/schema/tasks.ts）。涉及的关键字段：

字段	用途
`status`	`'pending'` / `'closed'` — 任务状态
`task_type`	`'lead_outreach'` / `'follow_up'` — 按类型拆分
`priority`	`'high'` / `'medium'` / `'low'` — 按优先级拆分
`due_at`	截止时间 — 判断 overdue / due soon / on-time
`closed_at`	关闭时间 — 计算 resolution time、on-time 判定
`created_at`	创建时间 — 计算 resolution time
`close_type`	`'auto_closed'` / `'manual_closed'` — 关闭方式分布
`close_result`	11 值枚举 — 营收归因、业务结果分布

Overdue 和 Due Soon 不存 DB，由 API 查询时实时计算：

Overdue = status='pending' AND due_at < NOW()
Due Soon = status='pending' AND due_at BETWEEN NOW() AND NOW() + interval（interval 由店铺配置）

Booking Rate 需要跨表：判定逻辑是 task 存续期间该客户的 contacts.leadStatus 变为 booked，需要关联 contact_timeline 的 contact.lifecycle_changed 事件。

2.2 任务效率 (Task Efficiency)¶

Dashboard → Tasks tab 展示 7 个可视化卡片，每个卡片内按 Overall / Lead Outreach / Follow-up 三层拆分（Avg Resolution Time 按优先级拆分）。

2.2.1 前端展示指标¶

① Completion Rate（完成率） — 同心圆图

衡量团队整体执行力。低 = 任务积压，员工没在关闭任务。

#	子指标	SQL 逻辑	目标
1a	Overall	`COUNT(status='closed') ÷ COUNT(*) FROM tasks`	→ 100%
1b	Lead Outreach	`WHERE task_type='lead_outreach'` 同上	→ 100%
1c	Follow-up	`WHERE task_type='follow_up'` 同上	→ 100%

② On-Time Completion Rate（准时完成率） — 同心圆图

完成率高不代表准时。衡量时效质量 — 任务是否在 deadline 前完成。

#	子指标	SQL 逻辑	目标
2a	Overall	`COUNT(status='closed' AND closed_at <= due_at) ÷ COUNT(status='closed')`	→ 100%
2b	Lead Outreach	`WHERE task_type='lead_outreach'` 同上	→ 100%
2c	Follow-up	`WHERE task_type='follow_up'` 同上	→ 100%

③ Due Soon Completion Rate（临期完成率） — 同心圆图

衡量预警机制的有效性 — 收到 Due Soon 警告后是否及时处理。

#	子指标	SQL 逻辑	目标
3a	Overall	触发过 Due Soon 且 `closed_at <= due_at` 的 ÷ 触发过 Due Soon 的总数	→ 100%
3b	Lead Outreach	`WHERE task_type='lead_outreach'` 同上	→ 100%
3c	Follow-up	`WHERE task_type='follow_up'` 同上	→ 100%

Due Soon 触发记录需要通过 contact_timeline 的 task.due_at_changed 或 API 层标记来追踪。

④ Overdue Completion Rate（逾期恢复率） — 同心圆图

逾期后最终被补救完成的比例。低 = 逾期任务被遗忘。

#	子指标	SQL 逻辑	目标
4a	Overall	`COUNT(status='closed' AND closed_at > due_at) ÷ COUNT(closed_at > due_at OR (status='pending' AND due_at < NOW()))`	→ 100%
4b	Lead Outreach	`WHERE task_type='lead_outreach'` 同上	→ 100%
4c	Follow-up	`WHERE task_type='follow_up'` 同上	→ 100%

⑤ Overdue Rate（逾期率） — 同心圆图

衡量执行纪律。最直接的负面信号。

#	子指标	SQL 逻辑	目标
5a	Overall	`COUNT(status='pending' AND due_at < NOW()) ÷ COUNT(*)`	→ 0%
5b	Lead Outreach	`WHERE task_type='lead_outreach'` 同上	→ 0%（> 5% 预警）
5c	Follow-up	`WHERE task_type='follow_up'` 同上	→ 0%（> 10% 预警）

⑥ Booking Rate（预约转化率） — 同心圆图

衡量销售能力。在成功联系到客户的基础上，有多少转化为预约。

#	子指标	SQL 逻辑	目标
6a	Overall	task 存续期间客户 `leadStatus` 变为 `booked` 的 task 数 ÷ reached task 总数	40%+
6b	Lead Outreach	`WHERE task_type='lead_outreach'` 同上	10%+
6c	Follow-up	`WHERE task_type='follow_up'` 同上	50%+

跨表查询：需要关联 contact_timeline WHERE event_type='contact.lifecycle_changed' AND newValue.leadStatus='booked' AND occurred_at BETWEEN task.created_at AND task.closed_at。Lead Outreach 天然低（首次接触），Follow-up 应该高（已有关系）。

⑦ Avg Resolution Time（平均解决时间） — 横向进度条

按 Lead Outreach + Follow-up 三个优先级拆分，不做 Overall（分钟和小时混在一起无意义）。

#	子指标	SQL 逻辑	目标
7a	Lead Outreach	`AVG(closed_at - created_at) WHERE task_type='lead_outreach' AND status='closed'`	< 5 min
7b	Follow-up (High)	`WHERE task_type='follow_up' AND priority='high' AND status='closed'` 同上	< 4h
7c	Follow-up (Medium)	`WHERE priority='medium'` 同上	< 24h
7d	Follow-up (Low)	`WHERE priority='low'` 同上	< 72h

注： Lead Outreach 处理时长与 §1.4 ② Median Response Time 是同一个指标，此处从 Task 视角呈现（Avg vs Median 区别见 §1.4 说明）。

2.2.2 暂不展示指标¶

数据已有但暂不在 Dashboard 可视化展示，后续根据需求开放。

#	指标	SQL 逻辑	来源
8	Task Type Distribution	`GROUP BY task_type` 各占比	tasks
9	Priority Distribution	`GROUP BY priority` 各占比	tasks
10	Auto-Close Rate	`COUNT(close_type='auto_closed') ÷ COUNT(status='closed')`	tasks

三、Revenue & Staff Performance 指标¶

数据全部来自 tasks 表（close_result 字段）+ 店铺配置（假设价格/系数）。Dashboard → Revenue & Staff Performance tab 展示。

3.1 营收计算（Revenue Attribution）¶

tasks 表没有金额字段 — 营收金额由 API 层在查询时实时计算：读取 close_result → 匹配店铺配置的假设价格 → 算出金额。

计算公式：营收金额 = f(close_result, 店铺配置)

close_result	DB 字段（tasks 表）	API 层计算逻辑	默认金额
`converted`	`close_result='converted'`	× 店铺配置.新客平均客单价	$149/mo
`upgraded`	`close_result='upgraded'`	× 店铺配置.升级增量单价	$40/mo
`complaint_resolved`	`close_result='complaint_resolved'`	× 店铺配置.会员月均消费 × 店铺配置.投诉归因系数	$149 × 0.60 = $89/mo
`payment_recovered`	`close_result='payment_recovered'`	× 店铺配置.会员月均消费 × 店铺配置.支付恢复系数	$149 × 0.75 = $112/mo
`cancel_saved`	`close_result='cancel_saved'`	× 店铺配置.会员月均消费	$149/mo
`freeze_recovered`	`close_result='freeze_recovered'`	× 店铺配置.会员月均消费 × 店铺配置.冻结恢复系数	$149 × 0.70 = $104/mo
`win_back`	`close_result='win_back'`	× 店铺配置.新客平均客单价	$149/mo
`event_signed_up`	`close_result='event_signed_up'`	× 店铺配置.活动平均报名费	$30（一次性）
`promotion_converted`	`close_result='promotion_converted'`	× 店铺配置.推广活动客单价	$129/mo/人（一次性）

数据流：tasks 表只存 close_result（枚举值）+ close_type（auto/manual）+ closed_by_staff_name（谁关闭的）。金额不存 DB，每次查询时 API 用 close_result 查店铺配置表拿到对应价格/系数，实时算出营收金额。店铺配置的默认值可在 Rules → Revenue Benchmarks 中编辑。

3.2 前端 Revenue tab — Impacted Revenue 表格¶

表格每行对应一个营收类型，展示 5 列：

列名	含义	计算方式
Expected	如果所有 task 都达成理想结果，能产生的最大营收	按 `type_category` 统计所有 task 数 × 该类型对应的理想营收金额（见下方映射表）
Actual	已关闭 task 实际达成的正向 close_result 对应的营收	按 `close_result` 统计已关闭 task 数 × 该结果对应的配置金额（见下方金额表）
Tasks	该营收类型相关的已关闭 task 数	按 `close_result` 统计 `status='closed'` 的数量
Leakage	营收泄漏 = Expected - Actual	红色展示，代表未达成理想结果的损失
Description	该营收类型的说明	静态文案

Expected 的计算：typecategory → 理想 closeresult 映射¶

Expected 基于 type_category（11 个）计算 — 每个 task 创建时就知道它的理想结果是什么（API 层固定映射，不存 DB）：

type_category	理想 close_result	Expected 金额	说明
`lead_outreach`	—	不计入 Expected	目标是接通，不直接产生营收
`lead_follow_up`	—	不计入 Expected	目标是推动预约，不直接产生营收
`booked_not_converted`	`converted`	$149	理想：预约后到店签约
`cancellation_risk`	`cancel_saved`	$149	理想：挽留成功
`complaint_retention`	`complaint_resolved`	$149 × 0.60 = $89	理想：投诉解决后留存（× 投诉归因系数）
`win_back`	`win_back`	$149	理想：前会员重新签约
`upgrade`	`upgraded`	$40	理想：升级套餐
`payment_recovery`	`payment_recovered`	$149 × 0.75 = $112	理想：会员更新 credit card 成功（× 支付恢复系数）
`freeze_recovery`	`freeze_recovered`	$149 × 0.70 = $104	理想：冻结会员恢复活跃（× 冻结恢复系数）
`event_promotion`	`event_signed_up`	$30	理想：会员报名活动（一次性）
`special_promotion`	`promotion_converted`	$129	理想：特别推广签约（一次性）

lead_outreach 和 lead_follow_up 不计入 Expected — 它们的目标是推动 Lead 往漏斗下一步走（接通、预约），不直接产生营收。

Expected 计算：SUM( COUNT(type_category) × 理想金额 ) — 只统计有营收归因的 9 个 typecategory（排除 leadoutreach 和 leadfollowup），包含 pending + closed，代表"如果全部完美执行"的理论上限。

Actual 的计算：close_result → 实际营收¶

Actual 基于 close_result（13 个中的 9 个正向结果）计算 — 只算已关闭且达成正向结果的 task：

close_result	营收类型	Actual 金额
`converted`	Conversion MRR	$149
`upgraded`	Upgrade MRR	$40
`complaint_resolved`	Complaint Retention MRR	$149 × 0.60 = $89
`payment_recovered`	Payment Recovery MRR	$149 × 0.75 = $112
`cancel_saved`	Cancel Save MRR	$149
`freeze_recovered`	Freeze Recovery MRR	$149 × 0.70 = $104
`win_back`	Win-back MRR	$149
`event_signed_up`	Event Revenue（一次性）	$30
`promotion_converted`	Promotion Revenue（一次性）	$129

非正向的 4 个 close_result（lead_outreached / wrong_number / do_not_contact / other）不产生 Actual。

Actual 计算：SUM( COUNT(status='closed' AND close_result IN 正向 9 个) × 配置金额 )

Leakage 来源¶

Leakage = Expected - Actual，差额来自：

还没关闭的 task（pending） — 贡献了 Expected 但还没有 Actual
关闭了但不是正向结果的 task（close_result = lead_outreached / wrong_number / do_not_contact / other） — 贡献了 Expected 但 Actual = 0
typecategory 与 closeresult 不匹配（如 cancellation_risk task 最终 close_result = other 而非 cancel_saved）— Expected 算了 $149 但 Actual = 0

汇总行¶

前端展示名	Expected	Actual	Leakage
Recurring Revenue (MRR) Subtotal	8 种 MRR type_category 的 Expected 之和	8 种 MRR close_result 的 Actual 之和	Expected - Actual
One-Time Revenue Subtotal	Event type_category 的 Expected	Event close_result 的 Actual	Expected - Actual
Total	MRR + One-Time Expected	MRR + One-Time Actual	Expected - Actual
Impacted Revenue（顶部大数字）	—	= Total Actual	—
vs previous period（趋势）	—	当前周期 Total Actual - 上一周期 Total Actual	—

详见任务与营收归因。

3.3 Staff Performance tab 指标¶

按 closed_by_staff_name（tasks 表字段）聚合：

#	前端展示名	DB 查询（tasks 表）	API 层计算
1	员工任务完成数	`SELECT closed_by_staff_name, COUNT(*) FROM tasks WHERE status='closed' GROUP BY closed_by_staff_name`	直接展示
2	员工 MRR 贡献	`SELECT closed_by_staff_name, close_result, COUNT(*) FROM tasks WHERE status='closed' AND close_result IN (7 种 MRR) GROUP BY closed_by_staff_name, close_result`	每个员工的每种 close_result COUNT × 配置金额，求和
3	员工 One-Time 贡献	同上，`close_result IN ('event_signed_up','promotion_converted')`	同上
4	员工关闭结果分布	`SELECT closed_by_staff_name, close_result, COUNT(*) FROM tasks WHERE status='closed' GROUP BY closed_by_staff_name, close_result`	每个员工的 13 种结果各占比

四、Contacts 指标¶

3.1 客户资产概览 (Customer Asset Overview)¶

#	指标	English	计算逻辑	角色	V1 就绪	作用
1	总客户数	Total Customers	Contacts 记录数	O / M	✅ Auto	客户基础规模

3.2 互动活跃度 (Engagement)¶

按时间桶统计有互动（通话或短信）的客户占比。

#	指标	English	定义	计算	角色	V1 就绪	作用
1	1 月活跃率	30-Day Active Rate	30 天内有通话/短信	`lastActivityAt` ≥ now − 30d	O	✅ Auto	近期互动客户占比
2	3 月活跃率	90-Day Active Rate	90 天内有通话/短信	`lastActivityAt` ≥ now − 90d	O	✅ Auto	中期互动客户占比
3	6 月活跃率	180-Day Active Rate	180 天内有通话/短信	`lastActivityAt` ≥ now − 180d	O	✅ Auto	长期互动客户占比
4	沉默客户占比	Silent Customer Rate	超过 6 个月无互动	`lastActivityAt` < now − 180d	O	✅ Auto	发现完全失联的客户

lastActivityAt 已在 V1 Contacts 中定义。Neon SQL 可直接按时间桶聚合查询。

DNC、手动里程碑、AI 增强字段、AI 衍生指标等暂不在前端展示的 Contacts 指标，见 Contacts 扩展指标。

五、V1 就绪度统计¶

全指标就绪度总表¶

章节	指标	English	角色	V1 就绪	作用
§二 Lead 店铺漏斗（18）
	12 状态分布	Status Distribution	O / M	✅ Auto	了解漏斗各阶段客户分布
	温度分布	Temperature Distribution	O / M	✅ Auto	了解客户活跃度分层
	整体转化率	Overall Conversion Rate	O	🔘 Manual	衡量从获客到成交的整体效率
	单客获客成本	CAC	O	❌ 无数据	评估获客投入产出比
	6 步乘法链	6-Step Funnel Chain	O	前 4 步 ✅ / 后 2 步 🔘	定位漏斗瓶颈环节
	有效率	Validity Rate	O / M	✅ Auto	衡量 Lead 来源质量
	结果产出率	Result Output Rate	O / M	✅ Auto	衡量员工跟进覆盖面
	触达率	Reach Rate	O / M	✅ Auto	衡量电话接通能力
	预约率	Booking Rate	O / M	✅ Auto	衡量沟通转化说服力
	到店率	Show Rate	O / M	🔘 Manual	衡量预约到店履约
	到店转化率	Show-to-Close Rate	O / M	🔘 Manual	衡量到店后成交能力
	拨打预约率	Response-to-Book Rate	O / M	✅ Auto	衡量从发起联系(可能联系到也可能联系不到)到最终预约的端到端效率
	分段预约率	Response Time Booking Rate	M	✅ Auto	量化响应速度对预约转化的因果影响
	漏跟率	Neglect Rate	M	⚠️ Inferred	衡量店铺整体跟进完成度
	平均响应时间	Avg. Speed to Lead	M	✅ Auto	衡量店铺对新 Lead 的整体响应速度
	Lead Outreach 合规率	Lead Outreach Compliance Rate	M	✅ Auto	衡量新 Lead 首联达标率
	平均联系次数	Avg. Contact Attempts	M	🔘 Manual	评估成交所需沟通资源
	预约成交周期	Book-to-Close Cycle	O / M	🔘 Manual	评估预约转化效率
§三 Lead 员工执行质量（10，V1 暂不实现）
	今日已处理数	Today's Processed	S	✅ Auto	员工当日工作量实时看板
	个人响应时间	Personal Speed to Lead	M / S	✅ Auto	监控新 Lead 首次联系速度
	个人漏跟率	Personal Neglect Rate	M / S	⚠️ Inferred	发现员工遗漏的跟进任务
	个人触达率	Personal Reach Rate	S	✅ Auto	衡量该员工电话接通能力
	个人预约率	Personal Booking Rate	S	✅ Auto	衡量该员工沟通转化能力
	沟通质量趋势	Communication Quality Trend	S	🤖 AI	员工话术改进趋势
	触达率排行	Reach Rate Ranking	M	✅ Auto	对比员工电话接通能力
	预约率排行	Booking Rate Ranking	M	✅ Auto	对比员工沟通转化能力
	沟通质量评分	Communication Quality Score	M	🤖 AI	AI 评估员工话术水平
	Lead 处理量排行	Lead Volume Ranking	M	✅ Auto	对比员工工作量
§四 Tasks 指标（17）
	任务完成率	Task Completion Rate	M / S	✅ Auto	衡量员工任务执行力
	任务逾期率	Task Overdue Rate	M	✅ Auto	发现超时未处理的任务
	平均处理时长	Avg. Resolution Time	M	✅ Auto	评估任务处理效率
	Lead Outreach 完成率	Lead Outreach Completion Rate	M	✅ Auto	衡量 Lead Outreach 任务执行力
	Lead Outreach 逾期率	Lead Outreach Overdue Rate	M	✅ Auto	发现超时未处理的 Lead Outreach 任务
	Follow-up 任务完成率	Follow-up Completion Rate	M	✅ Auto	衡量 Follow-up 任务执行力
	Follow-up 任务逾期率	Follow-up Overdue Rate	M	✅ Auto	发现超时未处理的 Follow-up 任务
	Follow-up 平均处理时长	Follow-up Avg. Resolution Time	M	✅ Auto	评估 Follow-up 任务处理效率
	跟进预约率	Follow-up Booking Rate	M	✅ Auto	衡量 AI 跟进任务推动预约的效果
	任务类型分布	Task Type Distribution	M	✅ Auto	了解 Lead Outreach vs Follow-up 结构
	优先级分布	Priority Distribution	M	✅ Auto	了解任务紧急程度结构
	自动关闭率	Auto-Close Rate	M	✅ Auto	衡量 AI 自动关闭任务的比例
	Due Soon 命中率	Due Soon Completion Rate	M	✅ Auto	衡量临期预警的提醒效果
	影响营收	Influenced Net MRR	O	🔘 Manual	量化员工行动与 AI 带来的营收
	平台 ROI	Platform ROI	O	❌ 无数据	量化平台投入产出比
	关闭方式分布	Close Type Distribution	O / M	✅ Auto	了解人工 vs AI 关闭的结构
	业务结果分布	Business Outcome Distribution	O / M	✅ Auto	了解任务关闭后的业务成果结构
§五 Contacts 指标（24）
	总客户数	Total Customers	O / M	✅ Auto	客户基础规模
	客户生命周期阶段分布	Lifecycle Stage Distribution	O / M	✅ Auto	了解 lead/member/churned 结构
	客户生命周期活跃状态分布	Lifecycle State Distribution	O / M	✅ Auto	了解客户活跃 vs 终止结构
	1 月活跃率	30-Day Active Rate	O	✅ Auto	近期互动客户占比
	3 月活跃率	90-Day Active Rate	O	✅ Auto	中期互动客户占比
	6 月活跃率	180-Day Active Rate	O	✅ Auto	长期互动客户占比
	沉默客户占比	Silent Customer Rate	O	✅ Auto	发现完全失联的客户
	DNC 标记率	DNC Flag Rate	M	✅ Auto	监控不可联系客户占比
	到店（手动标记）	Mark Showed	S / M	🔘 Manual	标记客户到店，驱动到店率计算
	试课（手动标记）	Mark Trialed	S / M	🔘 Manual	标记客户试课，驱动试课率计算
	成交（手动标记）	Mark Converted	S / M	🔘 Manual	标记客户成交，驱动转化率计算
	购买意向	Purchase Intent	M	✅ Auto（AI 写入）	识别高意向客户优先跟进
	状态原因	Lead Status Reason	M	✅ Auto（AI 写入）	解释状态变更的具体原因
	行动建议	Suggested Action	S	✅ Auto（AI 写入）	为员工提供下一步操作指引
	客户画像	Customer Summary	S	✅ Auto（AI 写入）	快速了解客户背景和需求
	条件性拒绝占比	Conditional Rejection Rate	M	✅ Auto	评估可回捞客户比例
	AI Summary 覆盖率	AI Summary Coverage	M	✅ Auto	衡量 AI 画像覆盖面
	决策障碍分布	Objection Distribution	M	✅ Auto（AI 写入）	了解客户顾虑的主要原因
	拒绝原因分布	Rejection Reason Distribution	M	✅ Auto（AI 写入）	了解客户拒绝的主要原因
	客户目标分布	Goal Distribution	M	✅ Auto（AI 写入）	了解客户需求类型结构
	状态变更历史	Lead Status Changelog	M	✅ Auto（AI 写入）	追溯状态变更全链路
	未解决投诉	Open Complaint	M	✅ Auto（AI+代码）	识别当前有未解决投诉的客户
	投诉率	Complaint Rate	M	✅ Auto（AI+代码）	监控当前未解决投诉的客户占比
	取消意向率	Cancel Intent Rate	M	✅ Auto（AI 写入）	监控表达过取消意向的会员占比

就绪度统计¶

总计 69 个指标

状态	数量	占比	说明
✅ Auto	53	77%	系统自动计算，V1 可直接使用
⚠️ Inferred	2	3%	系统可推断，需规则匹配或数据积累
🔘 Manual	9	13%	需员工手动输入或线下数据
🤖 AI	2	3%	需 AI 分析管道
❌ 无数据	2	3%	V1 无数据支撑，无法实现
混合	1	1%	6 步乘法链（前 4 步 ✅ / 后 2 步 🔘）

按章节可用度¶

章节	V1 可用指标	V1 不可用指标	备注
§二 Lead 店铺漏斗（18）	漏斗前 4 步、状态/温度分布、管理预警、效率指标、拨打预约率、分段预约率、Lead Outreach 合规率	到店率/到店转化率/成交周期（🔘）、CAC（❌）	店铺核心数据，大部分可用
§三 Lead 员工执行质量（10）	—	全部（缺 `assignedTo` 分配机制）	V1 暂不实现，待分配机制上线
§四 Tasks 指标（17）	任务效率全部（13 个）、关闭方式分布、业务结果分布	影响营收（🔘）、ROI（❌）	任务侧全量可用，营收侧受限
§五 Contacts 指标（24）	资产概览、活跃度、DNC、AI 字段/衍生（含 Changelog）、风险信号	—	AI 写入字段覆盖面广，新增投诉/取消风险信号

结论：V1 共 69 个指标，其中 53 个（77%）系统自动可用。§二 Lead 店铺漏斗的大部分核心指标和 §四任务效率（13 个）V1 即可落地。§三员工执行质量因缺乏 Lead 分配机制（assignedTo）V1 暂不实现。§五 Contacts 指标依托 AI 写入字段覆盖面广，新增风险信号（投诉/取消意向）。整体来看，店铺级指标 V1 即可落地，员工级指标需等分配机制上线后补齐。