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

# 三、产品论证

本文回答：\*\*主稿提出的产品价值，在真实使用中是否成立，应怎样验证？

本文整理于 2026-09-15。下面的验证方法是待执行的安排，不代表已经完成验证；已有生产材料来自 2026-09-13 的局部观察，本次没有重新检查生产环境。

## 1. 要论证哪些产品价值

**按“要验证什么 → 怎样验证 → 已有证据 → 当前结论 → 待补证据”记录每项论证。** 有功能、有页面、有任务数量，只能说明部分实现或使用情况；产品效果还需要检查识别质量、真实执行和实际结果。

| 论证方向          | 要回答的问题                                        | 验证方法                                                      | 已有证据与当前结论                                                  | 待补证据                                    |
| ------------- | --------------------------------------------- | --------------------------------------------------------- | ---------------------------------------------------------- | --------------------------------------- |
| **需求与跟进事项识别** | 客户需求、购买信号、问题和员工承诺是否识别准确？应跟进的有没有漏掉，不需跟进的有没有误报？ | 从原始沟通中抽样，由人工先判断哪些需要跟进及原因，再与系统结果逐条核对；同时检查系统判定不需跟进的记录       | 现有材料可以定位部分真实沟通，但没有形成识别准确性与漏识别的系统评估                         | 包含应跟进与无需跟进情况的样本、人工判断、系统判断、分歧与复核结果       |
| **员工执行**      | 识别结果能否变成合理的任务和下一步？是否让员工更容易开始、更及时完成工作？         | 核对原始沟通与任务的对应关系，检查遗漏、重复、依据和下一步；观察员工实际使用，比较查找准备耗时、首次联系和后续处理 | 有线索、任务、电话与短信关联记录；案例 A 仍有任务状态与会员状态不一致的问题，尚不能认定已经形成正确闭环或提高效率 | 任务质量评估、员工采用与纠正记录、实际执行记录，以及同口径的耗时和响应速度比较 |
| **门店管理**      | 经理能否借助产品发现问题、安排工作、培训员工并检查效果？                  | 让经理完成具体管理任务，记录使用了什么信息、作出什么决定；把报表与回答回查到原始记录，后续检查处理结果       | 现有材料没有形成“发现问题—作出决定—执行—复查”的完整管理案例；已有一次月度报表请求失败记录            | 可核对的管理案例、经理反馈、指标准确性检查、管理工作耗时比较          |
| **总部与多店支持**   | 是否帮助总部比较门店、安排支持，并把有效做法推广到其他门店？                | 统一门店与统计口径，记录一次跨店问题发现、资源或培训安排、实际执行及复查过程                    | 单店局部观察不足以证明跨店管理效果；CRM 对接和后续功能扩展仍应按规划验证                     | 多店可比数据、总部实际使用记录、跨店推广及复查结果；需要对接的场景另行验证   |
| **经验积累与复用**   | 客户历史、处理方法和销售经验是否被其他员工用于交接、培训与后续工作？            | 选取客户交接或新人培训场景，检查他人能否利用记录理解情况、完成工作；记录被复用的案例、纠正和改进          | 案例 A 可查看跨次沟通，说明存在可追溯材料；尚未证明这些材料已被复用并改善工作                   | 交接与培训案例、他人复用记录、准备耗时和处理质量比较              |

**业务结果另做核实。** 在上述工作变化有依据后，再核对预约、成交、续费、款项追回或问题解决等结果。核实日期、客户身份、付款与退款，并使用可比对象或分阶段试用等方式检查产品贡献；客户后来成交，不自动意味着成交由产品促成。收益验证方法见下一节。

## 2. 收益验证

**门店的收益验证逻辑分三层：先证明工作发生了变化，再核实结果，最后判断是否真的多赚了钱。**

![收益验证顺序：执行改变，核实业务结果，再与对照比较增量贡献](/images/product-sale/presentation/money-flow.png)

**OTF SPOG 指标参考：** 验证时重点关注线索数量、体验课预约率和首次联系时间；OTF 的 Contact Opportunities 在业务用途上可与 Retaintive 的 Tasks 对照。比较前需对齐门店、时间范围和统计口径，不能把 OTF 原系统的数据直接当作 Retaintive 的效果。具体指标见[OTF SPOG 指标与业务参考](#61-otf-spog-指标与业务参考)。

### 2.1 三层证据

**给买方看的数字分三层：** 执行有没有改变、哪些业务结果已经核实、与对照相比多了多少。AI 判断“想买”、员工记录“办好了”和业务系统显示“到账了”，是三种强度的证据。

**每种价值都要单独测量。**

- 更早响应和持续跟进可以帮助新客转化。
- 处理会员问题可以支持续费和挽留。
- 升级有自己的结果。
- 转介绍有自己的结果。
- 召回有自己的结果。
- 恢复支付有自己的结果。
- Coaching 要证明员工处理有所改善。
- Ask AI 要证明经理更快找到了需要处理的问题。
- 多店报告要证明经理更快找到了需要处理的问题。

### 2.2 Revenue 怎么算

（1）当前 Revenue 报表如何估算金额

**现在的 Revenue 报表是估算，不是实收账本。** 系统根据配置价格和去重后的业务结果估算金额，不代表实际到账金额；缺少必要数据时，显示金额未知。[实现定义](https://github.com/retaintive/callytics-infrastructure/blob/5fb52c15982c6fd67ef91319c895ae3b16a5e28d/packages/task-engine/src/metrics/revenue.ts#L420)

**对外表述边界：** 关于钱的说法要卡在报表能证明的范围内：Revenue 是按本店单价对去重后的业务结果做的估算，代码明确标记因果归因未建立、不是账单或 POS 收入。可以说"发现了什么机会、记录了什么结果、按什么价格估算价值"；不能说"客户实际多收了多少钱""因为用了我们多赚了多少"，那需要买方的外部业务数据和增量评估，产品本身给不出。

（2）如何进一步评估产品带来的增量收益（可选验证方法）

如果后续需要评估使用 Retaintive 后额外增加了多少收益，可以在具备可比数据时采用以下方法。这是额外的效果评估，不是当前 Revenue 报表的计算方式。

**一个假设算例——下面只解释计算方法，不是 Retaintive 的实测成绩。** 两组各有 100 个可比机会，观察时间与服务期间相同。

| 计算到哪一步      | 假设与计算                      |     得到什么 |
| ----------- | -------------------------- | -------: |
| 多出多少购买      | 使用产品 30 次，对照组 20 次；30 − 20 |     10 次 |
| 对应多少增量净收入   | 每单扣除退款与税后 $200；10 × $200   |   $2,000 |
| 对应多少贡献毛利    | 假设贡献毛利率 70%；$2,000 × 70%   |   $1,400 |
| 扣除额外产品与实施成本 | 另有尚未计入的 $500；$1,400 − $500 | **$900** |

**真实评估比算例复杂。** 要考虑客户来源、人员、促销和样本差异；能随机分配时随机分配，否则匹配基线并说明差异，失败和不知道结果的案例也保留。短期能验证响应和部分购买；长期留存需要更长观察。

**收入按用途分开记，不重复算。** 新会员首付款、课包购买、升级差额、续费到账和恢复支付后实际到账的款项分别统计。同一交易不能被多个 Task 重复计算，恢复支付后实际到账的款项不能全部算作新增 MRR，一次挽留不能直接乘上假设的终身价值。

## 3. 先把“识别”和“任务”分清

- **识别出的跟进需求：** 对某次沟通的判断——是否需要后续处理、为什么需要。论证重点是判断是否准确、有无遗漏。
- **正式 Task：** 系统中持续要处理的工作事项。论证重点是任务是否合理、是否有依据、下一步是否可执行，以及后续是否被处理。
- **待审核提议：** 还需要确认是否执行的建议，应与正式任务分别记录。

评估时，应把原始沟通、识别结果、任务或提议及实际处理记录关联起来。**不能把通话数、跟进原因数、客户数和 Task 数混为同一个数量，也不能仅用任务多来证明识别好。** 具体统计字段、去重方式和取样范围需要在执行评估时确认。

## 4. 已有产品材料：可以从哪里开始核查

以下是历史观察，供选择验证样本，不是已完成的效果评估。

| 已有材料                                                                           | 现在支持的判断                     | 仍不能据此认定                             |
| ------------------------------------------------------------------------------ | --------------------------- | ----------------------------------- |
| **Retaintive，8 月 23–29 日**：Leads 页面 67 条记录，Task、电话和 SMS 可打开                    | 可以用真实客户记录组织演示，展示沟通与后续工作怎样关联 | 页面有数据不证明所有自动化已执行，或全部统计口径已正确         |
| **匿名案例跨系统匹配**：内部 Converted/Member；OTF 显示 Orange Basic Membership、Class Total 2 | 可以核对当前会员资料及官方课程总数           | 入会日期、付款、退款和增量尚未核实；可能是回流会员，不能当新客增收案例 |

来源：[West Harlem 生产证据](/funding-strategy/04-West-Harlem生产证据.md)。验证后应记录样本、方法和结论，不能只把演示成功更新成“价值已验证”。

## 5. 验证前需要复核的产品问题

以下保留原主稿记录的局部异常，发现于 2026-09-13。当前是否已修复尚未重新核实；复测时记录结果、环境和日期。

- **案例 A 的 Task 状态和会员状态打架。** 客户已显示为会员，Task 却仍开放，下一步为空、期限已过，还在建议回拨。
- **一通电话在历史里显示 Connected，详情却是 Voicemail。** 线路接通和与真人沟通需要分清。
- **一次月度 My Stores 请求失败，** 周度 Leads 仍能打开。

这三件是局部抽查发现，不能扩大成整个产品都失败，也不能在 demo 中假装已经解决。

## 6. 外部经营背景与比较基准

**本节记录的是 OTF 原系统的经营数据，不是 Retaintive 的识别数量、任务数量或产品效果。** 这些数据可帮助理解客户问题；只有门店、时间、对象与定义可比时，才可以作为效果比较的参考。

| 外部材料                                                                                      | 可提供的背景                                         | 使用限制                                                                                                                 |
| ----------------------------------------------------------------------------------------- | ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| **2026 年 6 月原系统列出的会员待跟进事项**：406 条（页面标为 opportunities），已联系记录为 15（contacts made），显示联系比例为 4% | 原系统已列出值得员工联系、跟进的会员事项；还需要核查员工是否处理，以及联系和处理结果如何记录 | 406 按“会员 × 跟进原因”统计：同一会员有多个原因时可能计为多条，不等于 406 名会员，也不等于 406 笔销售机会。已联系记录少，可能涉及漏记、通过其他渠道联系或更新延迟，不能据此说“96% 没人跟”，也不能换算可追回收入 |
| **West Harlem，2026 年 8 月**：首次联系平均 0.98 天，约 23.5 小时                                        | 电话提醒和跟进有一个可以检验的响应速度起点                          | Contact 包括电话、Email、短信；均值不等于每人等一天，也不证明延迟造成流失                                                                          |

**出处：** June 证据见[原图](/images/orangetheory-revenue-management-app-june-2026.png)及[口径说明](</industry-knowledge/OTF/OTF Revenue Management 分析.md>)；West Harlem 的日期、页面、匿名案例和异常见[生产证据](/funding-strategy/04-West-Harlem生产证据.md)。

**OTF 同月的漏斗数字不是我们的漏斗。** 8 月还有 458 Lead captures、114 Booked Intros、89 Intros Taken、46 Closes。它们是按月独立统计的事件，不保证属于同一批客户，不能直接画成 Retaintive 带来的完整漏斗。June 截图、West Harlem 8 月数据和 Max 最初提供的 Totowa 截图也不能混用。

**有些店主缺的是 Lead 数量，这会影响找谁谈。** 已有[店主访谈](/industry-knowledge/OTF/otf-owner-pain-points.md)提示了这一点。Retaintive 能帮助处理已有需求和机会，不能因此声称创造了新的市场需求。谈买方时先确认他最需要改善的是获客、留存、付款恢复还是员工管理，再选相应案例。

### 6.1 OTF SPOG 指标与业务参考

本节整理 OTF SPOG 网站的一些相关指标，说明它们与 Retaintive 的对应关系，供指标设计与业务对照参考。

#### 6.1.1 线索指标

![OTF SPOG Totowa 门店的线索来源、营销成本及客户转化与跟进指标](/images/product-sale/evidence/otf-spog-totowa-studio-metrics-2026-09-15.png)

##### ① 图上的重要指标

**线索来源（Network New Lead Sources）**

- 合作伙伴来源的线索数量（Partner）
- 其他来源的线索数量（Other）
- 手机 App 来源的线索数量（Mobile App）
- 外拓渠道来源的线索数量（Outreach Methods）
- 网站来源的线索数量（Web）
- <span style="color: #d32f2f;">线索总数（Total）</span>

**营销成本（Marketing Spend）**

- 品牌基金投入（Total Brand Fund）
- 门店本地营销投入（Total Local Spend）
- 营销总投入（Total Marketing Spend）
- <span style="color: #d32f2f;">每条线索的获取成本（Cost per Lead）</span>
- 每次入会的获取成本（Cost per Join）

**转化与跟进（Network New Lead Funnel）**

- <span style="color: #d32f2f;"><strong>获取的线索数量（Lead Captures）</strong></span>
- <span style="color: #d32f2f;"><strong>线索预约体验课的比例（Intros booked % of leads）</strong></span>
- 预约后实际参加体验课的比例（Intros taken % of intros booked）
- 参加体验课后的成交比例（Closes % of Intros Taken）
- 直接入会占线索的比例（Direct joins % of lead captures）
- 总体转化率（Conversion %）
- <span style="color: #d32f2f;">平均每条线索的主动联系次数（OB Contacts/Lead）</span>
- 平均每次入会对应的主动联系次数（OB Contacts/Join）
- <span style="color: #d32f2f;"><strong>首次联系的平均耗时（Avg Time to First Contact）</strong></span>

##### ② 与 Retaintive 的对应

其中，**线索数量、体验课预约率（Intro Booking Rate）和首次联系时间，也是 Retaintive 关注的重要指标**：

- **线索数量：** 对应需要接入和跟进的潜在客户规模。
- **体验课预约率：** 对应线索跟进后推进到预约体验课的情况。
- **首次联系时间：** 对应线索进入后，员工开始联系的响应速度。

这三项可作为产品论证和效果比较的重点；与 SPOG 数据比较时，需要对齐门店、时间范围及统计口径。

#### 6.1.2 Contact Opportunities

![OTF SPOG Totowa 门店的收入跟进原因、会员收入指标及经营对比](/images/product-sale/evidence/otf-spog-totowa-revenue-metrics-2026-09-15.png)

![OTF Revenue Management App 对 Contact Opportunities 的定义与各类联系原因说明](/images/product-sale/evidence/otf-spog-contact-opportunities-help-2026-09-15.png)

##### ① 图上的重要指标

**收入相关的跟进原因（Revenue Management App — Contact reason）**

- 欠款／逾期付款（Past due）
- 即将流失（Upcoming churn）
- 课包续购（Package refresh）
- 迟取消相关待处理事项（Missed late cancel）
- 建议升级（Recommended upgrade）
- 信用卡即将到期（Expiring credit card）

##### ② 与 Retaintive 的对应

OTF 将这些需要联系会员处理的事项称为 **Contact Opportunities**，在业务用途上对应我们 Retaintive 的 **Tasks**；Contact reason 说明为什么需要联系，例如付款问题、续购、升级或信用卡更新。

**SPOG 与 Retaintive 的统计口径可能不一致，数据不一定能直接对应，但 SPOG 的指标和业务分类可以作为 Retaintive 对比与借鉴的参考。**

## 7. 每次验证怎样留下结论

每项验证使用同一记录格式，未执行或证据不足时明确写出，不提前填入通过结论。

| 记录项   | 要填写的内容                          |
| ----- | ------------------------------- |
| 待验证价值 | 对应第 1 节哪一项，以及本次具体要回答的问题         |
| 范围与样本 | 门店、日期、参与者、样本选择方法、样本量和排除条件       |
| 验证方法  | 人工判断依据、操作步骤、比较对象，以及通过标准；执行前确定   |
| 证据    | 原始沟通、系统结果、任务与行动记录、访谈或业务结果的可追溯链接 |
| 结果与异常 | 实际观察、错误与遗漏、失败样本、员工纠正及尚未解释的差异    |
| 当前结论  | 已支持的价值、适用范围、不能支持的结论及待补证据        |
| 复核信息  | 执行人、复核人、日期和运行环境                 |
