# S14 · 待办提醒与试点指标

状态：**业务评审草案 v0.5 / draft**。更新日期：2026-10-15。
来源：PRD 4.4、8.3、第 10 章；C-01、C-03、C-07；B2、B3、B5、R10。
依赖：S07。

## 问题与目标

物业能发现待处理事项并观察真实服务基线，不把提交完成、住户解决与超时混为一谈。

## 使用者与需求

- 物业：从待办查看未受理、处理超时和待确认事项并跟进。
- 运营：按明确口径查看绑定覆盖、响应与处理结果。
- 发起方：连续 2–4 周每周复盘员工使用和群追问。

## 一期范围

- 简单待办列表、站内提示、统计数字、指标口径与人工抽样台账。

## 业务规则与确认状态

- 【PRD 已定】先一个小区试点；观察基线，不设硬达标线，不建设复杂看板。
- 【PRD 已定】绑定人数与房屋覆盖率分开；首次实际受理不含自动回复；员工使用/群追问靠台账或抽样。
- 【PRD 已定，按本轮 C-03 细化】物业提交完成和后台人工关闭不等于住户亲自确认解决或满意；普通报修久未确认不再超时自动关闭。
- 【PRD 议 R10】明确提交区间与观察截止点；同问题现场只保留一条任务继续，其他任务按重复关闭单列；保留/关闭均不得重写原提交与首次实际受理记录。旧全员确认率不再作为一期默认指标。
- 【PRD 议 R10】取消/撤回单列且建议不进完成率分母；重开保留任务 ID 和累计时间线；等待费用/上门/住户确认的计时暂停需分别决定。
- 【本轮用户确认 C-03】普通报修已提交结果但住户久未确认，系统只提醒，之后由 PC 后台手动关闭。该情况通常是已修好但住户未点击；记录物业关闭来源，不伪造成住户确认。提交维修结果后 7 天作处理参考，后台可提前/延后手动关闭，不设时间硬门槛；具体指标分母仍待明确，提醒时点不由此自动确定。

## 操作前提与业务对象

- 试点小区房屋基数可核对；事项真实提交/首次受理/结果时间线可用。
- 后台关单 7 天参考时间已确认；统计时点、分母、计时暂停和普通结束统计公式尚待 R10/B3 明确；重复现场留单与重复关闭不计解决本轮已明确。

下列“入口”描述业务上的操作位置，不预设最终菜单名或页面布局。`基线`沿用源文档；`待同步`仍需 PRD 同步；`条件/待裁决/候选`不能视为已批准；`补充建议`为本次新增的待确认细节。主流程中遇到相应条件未定，即表示该分支尚未具备实现依据。

## 用户主流程

| 步骤 | 给谁操作 | 在哪里 | 用户操作 | 可观察结果 / 状态 | 依据与确认等级 |
|---|---|---|---|---|---|
| S14-M01 | 管理员/运营 | 试点设置与统计入口 | 确定试点小区、提交区间、观察截止点 | 指标明确覆盖哪批事项与截止时状态 | 基线试点；窗口 R10/B5 |
| S14-M02 | 物业员工 | 首页待办/员工列表 | 查看未受理、待处理、待确认及待重新分配事项 | 可进入本人有权任务继续办理 | 基线待办；分类 S14-D01 |
| S14-M03 | 物业/系统 | 提醒规则 | 到达按类型批准的时限 | 显示/发出提醒；已提交维修结果但住户久未确认不自动关闭，后续关闭仅在 PC 后台人工操作 | 基线提醒；时限 B3 |
| S14-M04 | 运营 | 绑定统计 | 查看有效绑定人数和房屋覆盖数 | 人数与房屋覆盖率分列，覆盖率分母为试点总房屋 | 基线：PRD 10.2 |
| S14-M05 | 运营 | 响应与结果统计 | 查看首次实际受理、物业完成、住户确认、超时及人工结束 | 分类不可互相冒充；重复关闭与保留任务真实完成分别统计，不把重复关闭算解决 | 基线分类；细则 R10/C-01/C-03 |
| S14-M06 | 运营 | 核对样本与台账 | 抽查系统使用/群追问，核对指标原始样本 | 系统数字与人工抽样区分，能说明计算所据记录 | 基线：PRD 10.2；样本展示 S14-D02 |
| S14-M07 | 发起方/物业 | 每周复盘 | 连续观察 2–4 周并记录磨合期 | 形成基线观察，不擅设硬达标线 | 基线：PRD 10.3 |

## 异常与分支处理

| 分支 | 触发情况 | 系统或业务处理 | 用户/办理者下一步 | 状态与历史影响 | 依据与确认等级 |
|---|---|---|---|---|---|
| S14-E01 | 只有自动回复，没有真实受理 | 不记作首次实际受理 | 员工继续受理/跟进 | 真实等待时间不被自动回复结束 | 基线：PRD 10.2 |
| S14-E02 | 同故障现场留一条任务、后台关闭其他 | 原始提交数、重复关闭数、保留任务真实完成分别看 | 查询对应原记录 | 后台留单/关闭时刻不重置原提交或首次实际受理 | 本轮确认：S09；统计细则 R10 |
| S14-E03 | 已取消、撤回或重开 | 分别按批准分母/时间线规则计算 | 查看各类明细，不把取消当解决 | 重开保留任务历史；重开解决率判定待定 | 条件：R10；S14-D02 |
| S14-E04 | 等待报价、上门或住户确认 | 是否暂停时限分别决定 | 配置批准规则并展示计时口径 | 不统一默认暂停 | 条件：R10/B3 |
| S14-E05 | 无样本或试点房屋总数为零 | 候选：显示无样本/无法计算而非 0% 完成或 100% 成功 | 补齐基数或调整统计窗口 | 原样本不改 | 补充建议：S14-D02 |
| S14-E06 | 微信提醒失败或一期不接 | 站内待办仍可使用 | 员工打开列表跟进 | 提醒失败不替代处理结束 | 基线非强依赖；C-07 |
| S14-E07 | 人数多但房屋覆盖没增加 | 人数更新，已覆盖房屋不重复累计 | 核对有效关系分布 | 同房多账号只增加人数不重复房屋分子 | 基线：PRD 10.2 |

异常表对能够从基线确定的处理给出明确结果；无法确定的分支给出候选或明确缺口。没有写成定稿的恢复动作，不由开发者自行补成业务选择。

## 待确认与实现阻塞

- B3：按类型提醒时限及默认值；处理计时是否暂停、何时恢复。
- 本轮 S09 已确认只对接保留任务的报修人；重复关闭单列，不计为各住户确认解决。C-03 提醒与 PC 后台人工关闭方向已确认；7 天参考已明确；后台关单由管理员另行授予指定员工已确认；具体统计公式仍待明确，其他强制结束不据此放开。
- C-07/B2：微信触达是否一期实现；B5：试点房屋基数、住户与员工特点。
- “解决率”分子和观察分母、重开后是否仍算已解决等需形成可复算公式，不能只沿用名称。


### 本次补充的细节待确认

| 本 spec 补充编号 | 需要确认的具体细节 | 受影响位置 |
|---|---|---|
| S14-D01 | 待办集合、红点意义、提醒对象/重复频率与恢复后的消除；时限阈值仍归 B3。 | M02/M03 |
| S14-D02 | 每个指标的精确定义、分子分母、零样本、账号去重、重开当前结果及核对产物。数值例为条件样本，不替代口径批准。 | M06；E03/E05；AC01/AC06–AC07 |

## 验收标准与完成条件

### 可逐条核对的验收条件

以下编号稳定用于评审与后续测试追踪；“给定—当—则”只验证用户能观察的结果。条件验收须先批准对应规则；“未决验收占位”表示目前还没有完整预期，不能宣称通过。

| 编号 | 给定前置条件 | 当用户/办理者操作 | 则应观察到的结果 | 验收依据 / 生效前提 |
|---|---|---|---|---|
| S14-AC01 | 试点 100 套房，20 套各至少一有效账号，其中一房三账号 | 查询覆盖指标 | 覆盖房屋数 20、覆盖率 20%；人数不以 20 自动代替 | 基线：PRD 10.2；账号去重细则 S14-D02 |
| S14-AC02 | 10:00 提交、10:01 自动回复、10:20 真实受理 | 查询首次受理时长 | 为 20 分钟，不是 1 分钟 | 基线：PRD 10.2 |
| S14-AC03 | A 10:00、B 10:10 提交；B 10:20 实际受理，现场后来留 B 并重复关闭 A | 查询 B 原时间线及重复关闭记录 | B 仍从 10:10 到 10:20 算 10 分钟；A 原提交/受理记录不丢，不从留单时刻重算 | 本轮确认：S09；分母细则 R10 |
| S14-AC04 | 仅物业完成、无人确认的任务 | 查询结果分类 | 只计物业完成，不计住户确认解决或满意 | 基线：PRD 10.2 |
| S14-AC05 | 普通报修已提交结果，住户未确认；部分后由 PC 后台人工关闭 | 同窗口查提醒超时、物业关闭与住户确认 | 分类分别保留，后台关闭不生成住户确认记录，也不由时间自动产生关闭；具体统计分母待 R10 | 本轮确认 C-03 行为与来源；计算公式 R10 待明确 |
| S14-AC06 | 候选取消分母规则获批，样本 10 任务含 2 取消、其余 8 中 4 达定义完成 | 计算任务完成率 | 若采用排除取消方案则 4/8=50%，取消另列；其他方案须另给确定样本 | 条件：R10 |
| S14-AC07 | 零样本/零房屋基数的展示方案获批 | 查询对应窗口 | 按确定“无样本/无法计算”含义显示，不误导成高解决率 | 条件：S14-D02 |
| S14-AC08 | 等待费用/上门/住户三段规则已批准 | 核对含这三段的时间线 | 暂停/计时分别按批准表计算，可手工复算 | 条件：R10/B3 |

### 本 spec 完成的判断

- **文本评审完成**：使用者/目标、范围、主流程、异常和验收均有对应描述；本 spec 的待确认项被明确归类，没有把未知结果藏在“正常处理”中。
- **需求定稿完成**：当前“一期范围”中每个待决业务分支有明确选择；每个条件验收落实为确定前提与预期；未决占位被补齐或范围经明确批准调整。不得仅把条件段删除来宣称完成。
- **功能实现完成**：相关住户、员工、PC 路径按已批准范围贯通，适用基线与已生效条件验收逐条通过；越权/异常分支、状态和历史可核对。文档新增表格不表示功能已实现或测试已通过。
- **交接完成**：留下实际验收记录及未完事项；其他 spec 的必要权限/身份/收费/可见范围合同一致，没有只让主流程通过而遗漏关键分支。

## 不在本 spec 内

- 复杂经营看板、硬达标线、商业收益分配（B6 不属于功能 spec）。

## 后续开发切片建议

1. 一份未受理/待确认列表可跟进，不依赖微信推送。
2. 用一组可手工复算的样本验证绑定率、响应及结果分类，再加入多报修和重开口径。

开发切片须贯通相关界面、业务处理与可观察结果；不要拆成孤立的“先全部建表，再全部接口，再全部页面”。以上是顺序建议，不是已发布任务。

## 技术设计边界

本 spec 不预设数据库结构、接口地址、模块路径、状态落库方式或测试框架。规则批准后，再结合现有代码和技术约束形成设计与开发任务；验收验证外部行为、权限拒绝与关键边界，避免只测试实现细节。

文档覆盖检查见 [17-规格完整性检查.md](../specs/17-规格完整性检查.md)。

确认等级、全局边界与来源处理见 [00-拆分总览.md](../specs/00-拆分总览.md)；决策追踪见 [16-决策与覆盖矩阵.md](../specs/16-决策与覆盖矩阵.md)。


## 本轮确认 · 重复关闭与解决分开

三人提交同一故障，现场留 B、重复关闭 A/C 时：提交记录 3，重复关闭 2，正常跟进 1；B 没点完成前不能记成解决 3 个问题。B 正常完成后只有保留任务产生真实完成/住户确认结果，A/C 仍为重复关闭。具体统计区间/分母继续独立定义，不恢复多人确认汇总。