#仪表盘数据源完整列表

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

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

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

#一、Lead 数据与指标计算

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

#1.1 数据来源

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

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

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

#1.3 Lead Tracker Pipeline 页面

#顶栏汇总

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

直接读 contacts.leadStatus 当前值。

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

#Excluded 行（未进入 contacts）

#占比计算

#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 归属阶段）。

从 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 个卡片：

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

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

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

详见 Lead Funnel 与 Status 汇总。

#二、Tasks 指标

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

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

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

#2.1 数据来源

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

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（完成率） — 同心圆图

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

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

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

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

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

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

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

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

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

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

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

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

跨表查询：需要关联 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（分钟和小时混在一起无意义）。

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

#2.2.2 暂不展示指标

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

#三、Revenue & Staff Performance 指标

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

#3.1 营收计算（Revenue Attribution）

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

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

数据流：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 的计算：type_category → 理想 close_result 映射

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

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

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

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

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

非正向的 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，差额来自：

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

#汇总行

详见 任务与营收归因。

#3.3 Staff Performance tab 指标

按 closed_by_staff_name（tasks 表字段）聚合：

#四、Contacts 指标

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

#3.2 互动活跃度 (Engagement)

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

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

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

#五、V1 就绪度统计

#全指标就绪度总表

#就绪度统计

总计 69 个指标

#按章节可用度

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

#参考文档

• Lead 指标详解（P0-P3 + P3 下钻）
• Lead Outreach 流程
• Lead Follow-up 流程
• Lead Temperature
• Contacts 数据来源与字段设计
• Tasks Overview
• Follow-up Task 生命周期
• 任务与营收归因
• 角色化仪表盘设计
• Rules Feature
• 下钻分析设计