# S10 · 投诉与建议处理

状态：**业务评审草案 v0.3 / draft**。更新日期：2026-10-15。
来源：PRD 第 6 章、5.6、2.5；A5、R06。
依赖：S03、S07。

## 问题与目标

住户意见能被有权的人回应；投诉保持受限可见，建议以回应完成为结束依据。

## 使用者与需求

- 住户：在意见反馈中选择投诉或建议并查看本人回复。
- 投诉负责人：核实并回复，允许后续反馈。
- 建议处理人：说明采纳、待研究或不采纳原因。

## 一期范围

- 小程序意见反馈入口、类型表单、PC/员工处理、受限可见与分别结束规则。

## 业务规则与确认状态

- 【PRD 已定】报修、投诉、建议共用引擎，按类型配置表单、人员、可见权限与结束规则；一期固定模板。
- 【PRD 已定】投诉只对提交人与获授权且非涉事师傅的处理人可见；维修角色不自动获得投诉权限；投诉不得进入公共公示。
- 【本轮用户确认，2026-10-15】师傅可查看派给自己报修任务中报修人的完整手机号；用户针对这次维修提交的投诉对涉事师傅本人不可见。能看报修电话不代表能看投诉，投诉处理授权也不能向涉事师傅开放该投诉。投诉不得通过关联报修的列表、详情、附件、回复或提醒展示给涉事师傅；这不改变正常报修进度与未解决反馈流程。
- 【PRD 已定，第 6 章】投诉回复处理结果后才可确认/关闭，允许继续反馈；建议完成回应即可结束，不要求落实实施。
- 【PRD 已定】重复投诉可内部关联同一事件，但每人诉求与回复分别保留，不套用报修合并关闭。

## 操作前提与业务对象

- 住户有当前房屋服务资格；处理者有投诉/建议相应权限。
- 同一引擎复用不代表表单、可见范围或关闭依据相同。

下列“入口”描述业务上的操作位置，不预设最终菜单名或页面布局。`基线`沿用源文档；`待同步`仍需 PRD 同步；`条件/待裁决/候选`不能视为已批准；`补充建议`为本次新增的待确认细节。主流程中遇到相应条件未定，即表示该分支尚未具备实现依据。

## 用户主流程

| 步骤 | 给谁操作 | 在哪里 | 用户操作 | 可观察结果 / 状态 | 依据与确认等级 |
|---|---|---|---|---|---|
| S10-M01 | 住户 | 小程序“意见反馈” | 选投诉或建议，填写描述及材料后提交 | 形成对应类型事项，不进入公开公示 | 基线：PRD 第 6 章 |
| S10-M02 | 获授权管理者 | 投诉/建议列表 | 按类型受理并安排获准处理人 | 投诉按受限授权展示，并排除该次维修的涉事师傅 | 本轮用户确认；PRD 第 6 章；其余矩阵 A5 |
| S10-M03 | 投诉负责人 | 投诉详情 | 核实事项，填写处理措施与回复 | 回复后才可进入结果确认/关闭环节 | 基线：PRD 第 6 章；逐条准入 R06 |
| S10-M04 | 投诉提交人 | 本人结果 | 查看回复，继续反馈或按规则确认 | 保留本人诉求与回复；反馈后的目标状态待 S10-D01 | 基线允许继续反馈；细则待定 |
| S10-M05 | 建议处理人 | 建议详情 | 回应采纳、待研究或不采纳并说明原因 | 回应后可结束，无需先实施建议 | 基线：PRD 第 6 章 |
| S10-M06 | 获授权处理者 | 同事件的多条投诉 | 内部关联用于核实 | 各人诉求和回复独立保留，不能照搬 S09 的报修合并关闭 | 基线：PRD 第 6 章 |

## 异常与分支处理

| 分支 | 触发情况 | 系统或业务处理 | 用户/办理者下一步 | 状态与历史影响 | 依据与确认等级 |
|---|---|---|---|---|---|
| S10-E01 | 涉事师傅访问用户对该次维修的投诉，或普通维修人员访问未获授权投诉 | 拒绝投诉内容、附件及回复；不能通过关联维修任务或提醒返回 | 由获授权且非涉事师傅的投诉负责人处理 | 投诉原记录不变；涉事师傅的一般投诉权限不覆盖此排除规则 | 本轮用户确认；PRD 第 6 章 |
| S10-E02 | 投诉尚无处理回复 | 不能直接走“已完成”关闭 | 先核实并回复 | 未回复状态保留 | 基线：PRD 第 6 章 |
| S10-E03 | 投诉人对回复仍不接受 | 允许继续反馈；回哪个状态、是否更换处理人需定 | 提交补充诉求后由获准人员跟进 | 回复历史不被覆盖 | 基线继续反馈；S10-D01 |
| S10-E04 | 建议未采纳或仍待研究 | 说明原因后可按建议结束规则处理 | 住户查看回应 | 不伪装为实际已实施 | 基线：PRD 第 6 章 |
| S10-E05 | 同一事件多人投诉 | 分别回复，不因一人结束自动关闭其他投诉 | 按各人的诉求跟进 | 保留独立材料/回复 | 基线：PRD 第 6 章 |
| S10-E06 | 拟强制结束未回复投诉 | C-03 是否允许例外未定；当前基线要求先回复 | 明确例外许可前不能默认绕过 | 结束原因不替代回复内容 | 条件：C-03；S10-D02 |

异常表对能够从基线确定的处理给出明确结果；无法确定的分支给出候选或明确缺口。没有写成定稿的恢复动作，不由开发者自行补成业务选择。

## 待确认与实现阻塞

- A5：涉事师傅看不到该次维修投诉已确认；其余投诉处理授权、管理角色可见范围及转交规则仍需完整矩阵。
- R06：不同类型具体跳过哪些状态、执行人和结束动作；第 6 章原则与 5.6 议表逐条对齐。
- 本轮 C-03 只确认普通报修已提交结果但住户久未确认的 PC 后台关闭；不能据此绕过投诉回复。S10-D02 的一般强制例外仍未批准。


### 本次补充的细节待确认

| 本 spec 补充编号 | 需要确认的具体细节 | 受影响位置 |
|---|---|---|
| S10-D01 | 投诉继续反馈后的目标状态、负责人/转交规则及确认人资格。 | M04；E03；AC06 |
| S10-D02 | 强制结束是否能例外绕过投诉回复，以及与 C-03/C-16 的准入一致性。 | E06 |

## 验收标准与完成条件

### 可逐条核对的验收条件

以下编号稳定用于评审与后续测试追踪；“给定—当—则”只验证用户能观察的结果。条件验收须先批准对应规则；“未决验收占位”表示目前还没有完整预期，不能宣称通过。

| 编号 | 给定前置条件 | 当用户/办理者操作 | 则应观察到的结果 | 验收依据 / 生效前提 |
|---|---|---|---|---|
| S10-AC01 | 有效住户选择投诉 | 提交完整材料 | 仅提交人及获授权且非涉事师傅的处理者可看，不出现在公示或其他住户摘要 | 基线：PRD 第 6 章 |
| S10-AC02 | 仅报修权限员工 | 直接查询投诉 | 访问被拒绝而非只隐藏按钮，材料不返回 | 基线：PRD 第 6 章 |
| S10-AC03 | 尚未回复投诉 | 尝试确认/关闭 | 不能跳过处理回复 | 基线：PRD 第 6 章；强制例外未定 |
| S10-AC04 | 同一事件两条投诉 | 关闭其中一条 | 另一人的诉求和回复不自动结束或被覆盖 | 基线：PRD 第 6 章 |
| S10-AC05 | 建议明确回复“待研究”及原因 | 处理人结束建议 | 可结束，记录的是已回应而非已实施 | 基线：PRD 第 6 章 |
| S10-AC06 | 继续反馈规则已批准 | 投诉人对回复追加未解决内容 | 保存前次回复和新诉求，进入确定跟进状态且只由获准人员处理 | 条件：S10-D01/R06 |
| S10-AC07 | 投诉相关图片和文字 | 尝试生成公共公示 | 不能公开投诉材料 | 基线：PRD 第 6 章 |

| S10-AC08 | 用户对一次维修提交投诉，涉事师傅仍能看该报修人完整手机号 | 涉事师傅打开维修任务、投诉列表/详情、附件、回复或提醒 | 可以正常查看获准的报修电话，但看不到该投诉；即使兼有一般投诉处理权限也不能查看本次针对其维修的投诉 | 本轮用户确认：报修电话与投诉隔离 |

### 本 spec 完成的判断

- **文本评审完成**：使用者/目标、范围、主流程、异常和验收均有对应描述；本 spec 的待确认项被明确归类，没有把未知结果藏在“正常处理”中。
- **需求定稿完成**：当前“一期范围”中每个待决业务分支有明确选择；每个条件验收落实为确定前提与预期；未决占位被补齐或范围经明确批准调整。不得仅把条件段删除来宣称完成。
- **功能实现完成**：相关住户、员工、PC 路径按已批准范围贯通，适用基线与已生效条件验收逐条通过；越权/异常分支、状态和历史可核对。文档新增表格不表示功能已实现或测试已通过。
- **交接完成**：留下实际验收记录及未完事项；其他 spec 的必要权限/身份/收费/可见范围合同一致，没有只让主流程通过而遗漏关键分支。

## 不在本 spec 内

- 通用流程设计器、公开投诉墙。

## 后续开发切片建议

1. 一条投诉提交、授权分配、回复及继续反馈。
2. 一条建议回应后结束，验证其与报修状态/指标差异。

开发切片须贯通相关界面、业务处理与可观察结果；不要拆成孤立的“先全部建表，再全部接口，再全部页面”。以上是顺序建议，不是已发布任务。

## 技术设计边界

本 spec 不预设数据库结构、接口地址、模块路径、状态落库方式或测试框架。规则批准后，再结合现有代码和技术约束形成设计与开发任务；验收验证外部行为、权限拒绝与关键边界，避免只测试实现细节。

文档覆盖检查见 [17-规格完整性检查.md](../specs/17-规格完整性检查.md)。

确认等级、全局边界与来源处理见 [00-拆分总览.md](../specs/00-拆分总览.md)；决策追踪见 [16-决策与覆盖矩阵.md](../specs/16-决策与覆盖矩阵.md)。
