> For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt.

# 2. Dashboard

Dashboard 将单个门店的线索、任务、电话、员工工作和业务结果汇总在一个看板中，帮助管理者发现跟进遗漏、掌握工作进展，并查看具体记录，决定下一步需要关注和处理什么。

店长或门店负责人可以用它安排工作、检查跟进进展和复盘经营情况。使用前先选择门店、日期范围，以及适用的对比期间。跨店汇总和比较由 My Stores 提供。

## 1 Leads 页签

Leads 包含两个模块：**Lead Funnel 看线索转化的整体表现，发现漏斗各环节的推进缺口；Speed to Outreach 看首次联系是否及时。** 两者结合，帮助管理者找到转化和联系时效上的薄弱环节，有针对性地加强跟进，争取更多体验课预约。

### 1.1 Lead Funnel

#### (1) 数据指标

**顶部：整体预约率**

- **Unique → Intros booked：** 整体预约率，即预约体验课人数 ÷ 去重客户人数。
- **pts：** 百分点，表示预约率相对对比期间上升或下降了多少。

**左侧：五个推进阶段**

从上到下回答：**进来了多少条线索记录 → 实际涉及多少位客户 → 尝试联系了多少人 → 联系上了多少人 → 多少人预约了体验课。**

| 名词解释          | 含义                     |
| ------------- | ---------------------- |
| Total         | 进入系统的线索记录总数            |
| Unique        | 系统接受的线索去重后，实际涉及的客户人数   |
| Outreached    | 已有联系行为记录的客户人数，不代表已经联系上 |
| Contacted     | 已有成功联系证据的客户人数          |
| Intros booked | 已预约体验课的客户人数            |
| Email lead    | 通过邮件接入的线索              |
| Call/SMS lead | 通过电话或短信识别的线索           |

**来源与跟进进展：** 目前只有 Total 和 Unique 区分 Email lead、Call/SMS lead；Outreached、Contacted、Intros booked 展示合计人数，尚未按来源拆分。因此可以看各来源带来多少线索，但不能直接比较各来源的联系率或预约率。来源不等于后续联系渠道，例如 Email lead 也可以通过电话或短信跟进。

**右侧：各环节流失**

展示重复记录、未被系统接受的线索记录，以及尚未尝试联系、尝试后尚未联系上、联系后尚未预约的客户数量和比例，帮助定位跟进中断的位置。

| 名词解释             | 含义                                             |
| ---------------- | ---------------------------------------------- |
| Duplicates       | 已接受的线索记录中，同一客户重复进入的记录数                         |
| Rejected         | 因资料不符合处理条件而未被接纳的线索记录数，不是客户拒绝沟通；不计入 Unique 客户人数 |
| No outreach yet  | 尚无联系行为记录的客户人数                                  |
| No contact yet   | 已有联系行为，但尚无成功联系证据的客户人数                          |
| No booking yet   | 已联系上，但尚未预约体验课的客户人数                             |
| Biggest drop-off | 三个跟进环节中，尚未进入下一阶段人数最多的一项，不代表客户已永久流失             |

**Rejected 的原因：** 缺少必要信息（如电话号码、所属加盟商或账号信息），或电话号码无法识别成有效的标准号码。原始记录仍然保留，具体原因需查看该条线索的处理记录。

#### (2) 管理价值

**发现漏斗漏在哪里，有针对性地加强管理。** 结合各环节尚未推进的人数和比例，判断问题集中在未及时联系、联系不上，还是联系后未预约，分别加强首次联系、联系安排或预约沟通。再通过顶部整体预约率及其对比变化，观察管理调整后是否有更多线索转为体验课预约。

#### (3) 使用方法

先看整体预约率，再看各阶段的推进比例和缺口；查看相关客户与任务记录，核对原因、安排跟进，并持续观察变化。

### 1.2 Speed to Outreach

#### (1) 数据指标

**联系耗时与变化**

从线索进入到首次主动联系的中位时间、平均时间，以及相对对比期间变快还是变慢。中位时间反映典型等待情况，平均时间更容易受到长时间等待的影响。

**耗时统计覆盖（Measured / Outreached）**

- **Measured（分子）：** 有有效首次联系耗时、实际参与耗时统计的客户人数。
- **Outreached（分母）：** 直接取自上方 Lead Funnel，表示同一门店、同一统计期间已尝试联系的客户人数，不是 Unique 总人数。

这一项用于说明已尝试联系的客户中，有多少人的时间可供分析。平均时间、中位时间和耗时分布只统计 Measured；已尝试联系但缺少有效时间的客户不参与计算，也不按零耗时计算。

**时间分布与预约表现**

不同首次联系时间的客户占比，以及各区间内的体验课预约率, 看不同首次联系时间下的预约表现。

#### (2) 管理价值

已有研究支持尽早联系新线索，建议将**线索进入后 5 分钟内首次联系**作为门店在可联系时段的跟进目标。该建议参考 2007 年的跨企业线索响应研究，研究衡量的是联系成功和线索推进，并非健身门店体验课预约率的最佳时限。[研究原文](https://content.marketingsherpa.com/heap/DG07SFSlides/LeadResponseManagementReport.pdf)

**识别首次联系延迟带来的预约机会。** 从时间分布中找出跟进较晚的情况。结合联系耗时的对比变化与整体预约率，持续验证跟进是否变快、预约是否改善.

使用Lead Line 可以有效提高首次联系的时间，让原本等待较久的新线索更早得到联系，争取更多体验课预约.

#### (3) 使用方法

管理方式配合 Lead Line 提醒减少遗漏，再对比联系耗时和预约表现。

## 2 Tasks 页签

Tasks 分为两部分：**Task Volume & Backlog** 看工作量与积压，**Task Performance** 看处理效率、业务结果和及时性。

**整体管理价值：反映团队的工作效率和处理效果。** 看清团队能否消化新增工作、是否按时处理，以及处理后是否取得业务成果，帮助管理者找到薄弱环节，调整分工与跟进方式。关闭数量需要结合工作量、及时性和业务结果一起判断。

**趋势图支持自定义：每条线 = 一个任务范围 × 一个指标。** 每条线可独立搭配不同范围与指标。两张趋势图分别设置，可在同一张图中添加多条线进行比较。

| 任务范围           | 可选内容                                                           |
| -------------- | -------------------------------------------------------------- |
| 全部任务           | All Tasks                                                      |
| Lead Tasks     | 整个大类，或 Lead Outreach、Lead Follow-up、Post-Intro Follow-up       |
| Member Care    | 整个大类，或 Cancellation Risk、Member Issue、Renewal、Payment Recovery |
| Revenue Growth | 整个大类，或 Win-back、Upgrade、Referral                               |

点击 **Customize**，为每条线选择任务范围和指标；**Add line** 添加组合，删除按钮移除不需要的线，每张图至少保留一条。**Done** 收起设置，**Reset** 恢复当前图的默认组合。

### 2.1 Task Volume & Backlog

#### (1) 数据指标

| 参数                      | 含义                                         | 能看出什么问题                                       |
| ----------------------- | ------------------------------------------ | --------------------------------------------- |
| Tasks Created           | 所选期间新建及重新打开的任务次数；重新打开也算一次新增工作              | 观察工作量变化；增长可能来自主动跟进带来的新机会，也可能来自需求增加或重复处理，需核对来源 |
| Tasks Closed            | 所选期间的关闭次数；同一任务重新打开后再次关闭，会再次计数              | 团队处理量能否跟上新增工作；不能直接当作成功解决的客户人数                 |
| Net Backlog Change      | 所选期间 Tasks Created 减去 Tasks Closed         | 正数表示积压增加，负数表示积压减少，零表示新增与关闭持平                  |
| Current Backlog         | 当前仍未关闭的任务数，不随所选日期范围变化                      | 眼下还有多少工作待处理，是否需要调整分工                          |
| Estimated Days to Clear | 当前积压 ÷ 所选期间平均每日关闭量，向上取整为天数；有积压但没有关闭记录时显示 — | 按当前处理速度，现有积压需要多久才能消化                          |

**Task Volume Trend：** 可选指标为 Tasks Created、Tasks Closed、Current Backlog；默认同时展示 All Tasks 的这三个指标。Net Backlog Change 和 Estimated Days to Clear 不在趋势指标选项中。

| 组合方式      | 示例                                            | 用途                    |
| --------- | --------------------------------------------- | --------------------- |
| 同一范围，不同指标 | Lead Tasks 的新增、关闭、积压                          | 看处理量能否跟上新增工作，积压是否持续增加 |
| 不同范围，同一指标 | 三个工作大类的 Current Backlog                       | 比较工作压力集中在哪个大类         |
| 具体类型之间比较  | Lead Outreach 与 Lead Follow-up 的 Tasks Closed | 观察首次跟进和后续跟进的处理量变化     |

#### (2) 管理价值

**反映团队消化工作的能力，发现效率和分工上的问题。** 新增持续高于关闭时，检查任务分配和处理节奏；某类任务积压较多时，优先核对卡点并安排负责人。结合积压净变化和预计清空天数，观察调整后是否逐步消化积压。

**Tasks Created 增加也可能是管理有效的表现。** 团队更积极主动地联系客户，可能让 AI 识别到更多需求和跟进信号，形成更多任务。应结合沟通活动、任务来源、关闭量和业务结果，判断增长是主动拓展带来的机会，还是重复处理、处理不及时带来的压力，不能仅凭新增任务增加就认定表现变差。

#### (3) 使用方法

先比较新增与关闭，再看当前积压和预计清空天数；通过分类趋势定位压力来源，进入 Tasks 查看具体任务、安排跟进，持续观察积压是否下降。

### 2.2 Task Performance

#### (1) 数据指标

| 参数                      | 含义                                                    | 能看出什么问题                                          |
| ----------------------- | ----------------------------------------------------- | ------------------------------------------------ |
| Clearance Rate          | 所选期间关闭次数 ÷ 新建及重新打开次数                                  | 低于 100% 表示处理量跟不上新增工作，高于 100% 表示还在消化此前积压；不代表业务成功率 |
| Positive Outcome Rate   | 所选期间取得正向业务结果的关闭次数 ÷ 全部关闭次数                            | 任务虽然关闭，是否取得了业务成果；比例偏低时需检查关闭原因和跟进质量               |
| On-time Completion Rate | 所选期间在有效截止时间前或当时关闭的次数 ÷ 有有效截止时间的关闭次数；无有效截止时间的关闭任务不计入分母 | 已关闭任务是否及时处理；该指标不能单独反映仍未关闭的逾期任务                   |

**对比变化与 Task Performance Trend：** 可选指标为上述三个比例，默认同时展示 All Tasks 的三个指标。顶部显示相对对比期间的变化，趋势图按日期展示表现；比例变化以百分点（pts）表示，— 表示无法计算，不等于零。

| 组合方式      | 示例                                                     | 用途                    |
| --------- | ------------------------------------------------------ | --------------------- |
| 同一范围，不同指标 | Member Care 的清理率、正向结果率、按时完成率                           | 同时看处理速度、业务效果和及时性      |
| 不同范围，同一指标 | 三个工作大类的 On-time Completion Rate                        | 找到及时性需要改善的大类          |
| 具体类型之间比较  | Lead Outreach 与 Lead Follow-up 的 Positive Outcome Rate | 定位需要进一步检查关闭结果和跟进质量的类型 |

任务量与比例分别在两张图中组合，不能混放到同一张图。不同任务类型的业务目标不同，比例差异用于定位问题，不宜直接作为优劣排名。

#### (2) 管理价值

**反映任务处理的效率、及时性和业务效果，找到需要加强管理的环节。** 清理率低，检查处理能力与工作安排；正向结果率低，检查沟通方式和关闭原因；按时完成率低，检查优先级与截止时间管理。三个指标结合看，避免只追求关闭数量而忽视实际效果。

#### (3) 使用方法

先看三个比例及其对比变化，再通过分类趋势定位问题；核对相关任务的处理记录和关闭结果，调整跟进方式或工作安排，观察后续表现是否改善。

## 3 Calls 页签

Calls 展示门店的**电话沟通量与业务构成**，帮助管理者了解团队联系客户的活跃程度，以及沟通集中在哪些需求和问题上。

### 3.1 电话总量与方向

#### (1) 数据指标

| 参数           | 含义                                            | 能看出什么问题                     |
| ------------ | --------------------------------------------- | --------------------------- |
| Total        | 所选期间纳入统计的呼入与呼出电话总数；统计真人通话，并可包含语音留言，不是全部拨号尝试次数 | 电话沟通量是否变化，为判断工作投入和客户需求提供线索  |
| Inbound      | 呼入电话数量及占 Total 的比例                            | 客户主动来电的工作量，是否需要调整接听安排       |
| Outbound     | 呼出电话数量及占 Total 的比例                            | 团队主动联系的活跃程度；数量增加不等于预约或销售增加  |
| 期间变化         | Total 相对所选对比期间的增减百分比                          | 沟通量是增加还是减少；没有可用对比数据时不显示增减比例 |
| Unclassified | 无法归入呼入或呼出的记录，单独展示，不计入 Total                   | 是否存在需要核对的电话方向数据             |

**Include voicemail（包含语音留言）：** 控制电话统计是否包含语音留言。语音留言指留下的录音消息，不代表双方进行了真人对话。

- **开启（默认）：** 统计真人通话和语音留言，了解包含留言在内的电话量与业务话题。
- **关闭：** 只统计真人通话，集中查看实际对话的数量与内容。

切换后，总量、呼入与呼出数量、业务分类及其占比会一起更新，点击进入 Calls 列表时也会沿用该筛选。当前关闭时不显示期间增减比例，因为对比期间的数据仍包含语音留言，两者不能直接比较。

#### (2) 管理价值

**观察沟通投入与客户来电压力，辅助安排人手和跟进工作。** 呼出增加可能来自团队更主动地联系客户，呼入增加可能来自客户需求上升。结合电话内容、Tasks 和预约表现，判断沟通是否带来有效推进，不能只按电话数量评价工作效果。

#### (3) 使用方法

选择门店、日期和对比期间，确认是否包含语音留言，再看总量及呼入、呼出构成；点击 Total 进入对应 Calls 列表，核对具体通话。

### 3.2 电话业务分类

#### (1) 数据指标

| 参数            | 含义                               | 能看出什么问题                    |
| ------------- | -------------------------------- | -------------------------- |
| Revenue       | 涉及收入的业务话题，如体验课预约、会员购买、升级、取消或账单问题 | 销售机会和收入风险集中在哪些话题；不代表已经产生收入 |
| Scheduling    | 课程预约、取消、改期、咨询及候补等排课话题            | 哪类排课需求占用较多沟通精力             |
| Service       | 政策咨询、设施反馈、会员支持及投诉等服务话题           | 客户主要需要哪些帮助，哪些服务问题值得进一步检查   |
| Other         | 其他业务分类                           | 常规分类之外的沟通构成                |
| 细分类别          | 各大类下具体话题的电话数量及占该大类的比例            | 把大类变化定位到具体需求或问题            |
| Uncategorized | 未归入上述业务大类的电话数量及占 Total 的比例       | 有多少电话尚无法从业务分类中解释，需要查看记录核对  |

**比例口径：** 大类卡片的比例以已分类电话为分母；细分类别以所属大类为分母；整体分类分布以 Total 为分母。电话方向的 Unclassified 与业务分类的 Uncategorized 是不同概念。

#### (2) 管理价值

**看清团队在沟通什么，发现值得跟进的机会和需要改善的问题。** 结合数量与占比，定位销售、排课或服务中的重点话题，再查看具体通话核对原因。例如取消相关电话增加时，应进一步检查客户诉求与挽留情况，不能直接当作实际取消人数。

#### (3) 使用方法

先看业务大类，再查看其中的细分类别。点击大类或细分类别进入对应 Calls 列表，保留门店、日期及语音留言筛选；结合录音、逐字稿和分析核对原因，再决定跟进安排或培训重点。

## 4 Team 页签

Team 分为 **Task Work（任务工作）** 和 **Call Activity（电话活动）**：前者看任务分工与推进，后者看电话沟通量与业务构成。两者结合，帮助管理者了解员工的工作投入、负担和需要支持的环节。

### 4.1 Task Work

#### (1) 数据指标

| 参数                             | 含义                                                      | 能看出什么问题                                  |
| ------------------------------ | ------------------------------------------------------- | ---------------------------------------- |
| Tasks assigned                 | 员工当前负责、尚未关闭的任务数                                         | 工作负担是否集中在少数人身上，是否需要调整分工                  |
| Tasks without contact attempts | 当前任务中尚无有效主动联系记录的任务数                                     | 哪些工作还需要开始跟进，是否存在遗漏                       |
| Tasks with contact attempts    | 当前任务中已有有效主动联系记录的任务数，不代表已联系成功或已解决                        | 哪些任务已经开始跟进，但仍需要继续推进                      |
| Unknown                        | 系统无法判断是否联系过的任务数——通常是门店号码未配置（分不清来电去电），或任务记录有数据问题；不是"没联系" | 数量多说明门店号码没绑好，先去 Setup 检查；零星几个多半是数据残留，找工程 |
| Activity                       | 所选期间有员工活动记录的不同任务数 / 活动总次数                               | 工作覆盖了多少任务、记录了多少次行动；次数多也可能是反复跟进           |
| Closed tasks                   | 员工在所选期间关闭的任务数；选了对比期间时，旁边显示与对比期间的增减（↑N / ↓N / No change） | 任务处理量是否变化；需结合关闭结果判断效果                    |
| Unassigned                     | 当前尚未分配负责人的任务                                            | 是否存在无人负责的工作，需要先明确责任人                     |

**统计范围：** 表格分两组，中间以竖线隔开。左侧 Current open tasks（Tasks assigned、Tasks without contact attempts、Tasks with contact attempts、Unknown）是此刻的存量，不随日期范围变化；右侧 Selected period（Activity、Closed tasks）反映所选期间的工作记录。不能把整张表理解为所选期间新增的任务。

**attempt与 Activity 的区别：**

Tasks without / with contact attempts 两列看的是"有没有试图联系过"的证据，来源有两种：上面这种员工记录的联系，或者系统从电话服务商确认到的、从门店号码打出去的电话和发出的短信——没打通也算试过。

什么算 Activity：员工在任务里点 **Log activity** 记下的一次联系动作——选一种方式（Call / SMS / Email / In-person）加一个结果（如无人接听、已发送、收到回复），并归到某位员工名下。记一次算一个 event，涉及几个任务算几个 tasks。系统自动记录、没有归属到员工的通话（如 Lead Line 自动外呼）不计入；改截止时间、改下次行动时间、换负责人、关闭任务、AI 自动更新也都不算。

#### (2) 管理价值

**看清任务分工和推进情况，发现工作负担不均、尚未跟进及无人负责的问题。** 结合员工当前任务量、活动记录和关闭情况，判断需要重新分配工作、督促跟进，还是提供支持。任务数量还受难度和分工影响，不能单凭关闭量评价员工效率。

#### (3) 使用方法

先关注 Unassigned、Tasks without contact attempts 和 Unknown，再比较员工负担与处理情况。点击支持跳转的任务数字进入对应 Tasks 列表，核对记录、明确负责人并安排下一步；之后观察工作是否得到推进。

### 4.2 Call Activity

#### (1) 数据指标

| 参数           | 含义                                | 能看出什么问题                   |
| ------------ | --------------------------------- | ------------------------- |
| Calls        | 所选期间归属于员工的真人通话与语音留言数量，附有可用的期间对比变化 | 员工电话沟通量是否变化，不等于成功联系的客户人数  |
| In / Out     | 呼入 / 呼出数量                         | 员工主要承担接听还是主动联系工作，分工是否需要调整 |
| Live         | 真人通话数量                            | 实际对话的工作量，不能直接代表沟通质量       |
| Voicemail    | 语音留言数量                            | 有多少沟通停留在留言，需要进一步查看后续跟进    |
| 自选业务类型       | 员工处理的具体电话话题数量                     | 谁在处理哪些业务，哪些话题可能需要培训或支援    |
| Unattributed | 尚未归属到具体员工的电话                      | 员工归属是否需要核对；不能把这些电话视为无人处理  |
| Total        | 全部员工及 Unattributed 的汇总            | 核对门店整体电话工作量，避免只看已归属员工的部分  |

**业务类型可自定义：** 点击 Add call type，从 Revenue、Scheduling、Service、Other 下选择具体类型，最多添加 6 列。可同时查看体验课预约、会员购买、投诉等话题，比较员工的业务构成；取消选择或 Clear all 可移除这些自选列。

#### (2) 管理价值

**了解员工的电话投入与业务分工，找到主动跟进、接听安排和培训上的改善空间。** 结合呼入、呼出、真人通话与业务类型，判断员工承担了什么工作，再查看具体沟通内容和后续任务。电话量高不一定效果好，电话量低也可能与排班或职责有关。

#### (3) 使用方法

选择日期和对比期间，先看电话总量与方向，再添加关注的业务类型。点击支持跳转的数字进入对应 Calls 列表，查看录音、逐字稿及分析；结合 Task Work 和业务结果，决定调整分工还是提供培训支持。

## 5 Revenue 页签

Revenue 把任务工作换算成钱，分 **Earned** 和 **Potential** 两个视图：Earned 回答"这段时间的工作带来了多少"，Potential 回答"这段时间新出现的机会全部谈成能值多少"。两个视图共用同一套八个计价项目、同一张表结构和同一份单价（Benchmarks），只是数的东西和计时的依据不同。所有金额都是**估算**，不是实际账单。

**两个时钟，记住这两句就够了：** Potential 看任务哪天开的，算哪天；Earned 看结果哪天发生的（签约、留住、预约那天），算哪天。线索什么时候进来不参与分区间。例：线索 3 月 1 日进来、当天开任务 → Potential 记 3 月；4 月 10 日签约 → Earned 记 4 月。

八个计价项目按"任务类型 · 计入的结果"命名，和员工关闭任务时看到的选项一字不差，分成两组：

| 分组            | 项目                                                                                                                                                | 金额性质             |
| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- |
| Recurring（按月） | New Lead · Signed Up、Cancellation Risk · Member Stayed、Payment Recovery · Payment Fixed、Renewal · Renewed、Upgrade · Upgraded、Win-back · Came Back | 每月持续，显示为 `$X/mo` |
| One-time（一次性） | New Lead · Intro Booked、Referral · Got a Referral                                                                                                 | 一次性金额            |

### 5.1 Earned

#### (1) 数据指标

**顶部两张卡片**

| 卡片                                 | 含义                                    |
| ---------------------------------- | ------------------------------------- |
| Estimated Recurring Revenue Impact | 按月组六个项目在所选期间的成交数 × 各自单价之和，显示为 `$X/mo` |
| Estimated One-time Revenue Impact  | 一次性组两个项目在所选期间的成交数 × 单价之和              |

选了对比期间时，卡片旁显示 `↑N% / ↓N% vs previous period` 或 `No change`；对比期间没有数据或金额为零时显示 `no … data`，不显示 0%。

**明细表**

| 列            | 含义                                                                                                    |
| ------------ | ----------------------------------------------------------------------------------------------------- |
| 项目 · Outcome | 任务类型 + 只有以这个结果关闭才计入。如 New Lead 任务以 Signed Up 关闭才算一笔，以其他结果关闭不算、还开着也不算。例外是 Intro Booked：预约一发生就计入，不等任务关闭 |
| Wins         | 所选期间取得该结果的成交数。**按客户去重**：同一个客户同一种结果只算一次，哪怕跟进它的是好几条任务                                                   |
| Unit value   | Benchmarks 里设的单价；没设的行显示 Set price                                                                     |
| Est. value   | Wins × Unit value                                                                                     |

按月组和一次性组各有小计，Total 行把两个数并排写成 `$X + $Y/mo`——中间的加号是分隔，不是相加，两种单位不能合成一个数。

**计时依据：** 一笔成交记在**结果发生的那天**（客户签约、留住、预约的日期），不看线索什么时候进来、任务什么时候创建。

**Estimated revenue impact trend（趋势图）**

明细表下面是逐日折线图，画的是每天的估算金额：当天成交数 × 单价，只算已经设了单价的项目，未定价的项目不画进来。

- 默认两条线：Recurring revenue impact 和 One-time revenue impact，各自对应上面两张卡片；每条线所有天数加起来等于对应卡片的数字，图和卡片同源。
- 点 **Customize** 可以按项目加线（例如单看 New Lead · Signed Up 每天的走势），**Add line** 添加、**Reset** 恢复默认、**Done** 收起。
- Intro Booked 按预约发生日落到当天。
- 数据取不到时整张图不画线，而不是画一条 0 线——空图表示"不知道"，不表示"没有"。

#### (2) 管理价值

**看这段时间的工作实际换来了什么，以及是在变好还是变差。** 卡片看总量和对比期间的增减，明细表看钱主要来自哪几类结果，趋势图看是持续产出还是集中在某几天。

#### (3) 使用方法

先确认 Benchmarks 里的单价符合本店情况，再选日期范围看两张卡片；进明细表看哪几行贡献最大、哪几行是零；再看趋势图判断产出是否稳定。

### 5.2 Potential

#### (1) 数据指标

**顶部两张卡片**：Potential Recurring Revenue Impact 和 Potential One-time Revenue Impact，算法同 Earned，只是数的是机会数而不是成交数。

**计时依据：** 一个机会记在**任务创建的那天**，之后不再变动。

**两个时钟：** Potential 看任务哪天开的，算哪天；Earned 看结果哪天发生的（签约、留住、预约那天），算哪天。

#### (2) 管理价值

**看这段时间新进来的机会盘子有多大，值不值得投人。** 它是"全部谈成"的上限，不是预测；适合比较不同月份进来的机会规模，或者看某类机会（如续费、追款）是否突然增多。

#### (3) 使用方法

选日期范围看两张卡片和明细表，关注机会数多但单价低、或单价高但机会少的行，决定跟进的优先级。

### 5.3 Benchmarks 与两个视图共同的规则

- **Benchmarks**：页面右上角的 Benchmarks 按钮打开单价设置，每个项目一个单价，存在门店配置里，两个视图和趋势图用的是同一份。只读账号能看不能改。门店一个单价都没设时，金额列整体不显示，只显示数量；设了部分时，没设的行显示 Set price。
- **未归类任务**：表格下方提示 "N tasks have no recognized revenue type"，这些任务没有对应的计价项目，不在上面任何数字里。
- **Earned 和 Potential 不能相除也不能相加**：Earned 按结果发生日计，Potential 按任务创建日计.
- **估算，不是实收，也不证明因果**：金额 = 去重后的业务结果数 × 本店设的单价。代码里明确标记因果归因"未建立"（`causalAttributionStatus: 'not_established'`），并注明这不是账单或 POS 收入。报表能说的是"发现了什么机会、记录了什么结果、按什么价格估算价值"；"实际收到多少钱""因为用了系统多赚多少钱"需要外部业务事实和增量评估，报表给不出。
- **未知不当零**：缺单价的行显示 Set price、数据取不到时整张图不画线，都不会算成 0 加进总数。

## 6 实现依据

本节按本地代码核查，页面实际启用情况以部署版本为准。

[Dashboard 页签与日期控制](https://github.com/retaintive/callytics-infrastructure/blob/a5801436771e0a84378fd9dbf2f1e1cfea37c69c/apps/web/src/pages/store-detail/%5BstoreId%5D.vue#L54) · [Leads 报表](https://github.com/retaintive/callytics-infrastructure/blob/a5801436771e0a84378fd9dbf2f1e1cfea37c69c/apps/web/src/pages/store-detail/components/store-leads-report.vue) · [首次联系速度](https://github.com/retaintive/callytics-infrastructure/blob/a5801436771e0a84378fd9dbf2f1e1cfea37c69c/apps/web/src/pages/store-detail/components/lead-cadence-combo-chart.vue#L170) · [任务趋势](https://github.com/retaintive/callytics-infrastructure/blob/a5801436771e0a84378fd9dbf2f1e1cfea37c69c/apps/web/src/pages/store-detail/components/task-trends.vue) · [电话报表](https://github.com/retaintive/callytics-infrastructure/blob/a5801436771e0a84378fd9dbf2f1e1cfea37c69c/apps/web/src/pages/store-detail/components/performance-review.vue) · [员工任务明细跳转](https://github.com/retaintive/callytics-infrastructure/blob/a5801436771e0a84378fd9dbf2f1e1cfea37c69c/apps/web/src/pages/store-detail/composables/team-task-drilldown.ts) · [业务价值估算说明](https://github.com/retaintive/callytics-infrastructure/blob/a5801436771e0a84378fd9dbf2f1e1cfea37c69c/apps/web/src/pages/store-detail/components/store-revenue-report.vue#L212) · [金额定义与因果标记](https://github.com/retaintive/callytics-infrastructure/blob/main/packages/task-engine/src/metrics/revenue.ts)
