厂家支持需求梳理.md 9.7 KB
厂家支持需求梳理（共 3 项）
适用对象：forge-admin 厂家 | 梳理人：产品通 | 配套文档：forge-admin-可行性分析.md（能力基线） 说明：本文档将我方需厂家支持落地的需求逐项规格化，便于厂家逐条确认"支持 / 需定制 / 不支持"及排期。当前一、差评处理流程已梳理完成；二、三、待补充。
一、差评处理流程
1.1 业务背景与目标
- 背景：公司在电商、外卖、社媒等多渠道经营，各渠道会产生顾客差评。当前差评"发现"与"内部处理"脱节，靠人工在不同系统间搬运，易漏处理、超时限、无留痕。
- 目标：打通「外部检测 → 自动建单 → 层级审批处理 → 客服回访闭环 → 留痕追溯」全链路，保证差评在时限内被跟进、每一步处理可追溯、回访结果可闭环。
1.2 角色定义
| 角色 | 职责 |
|---|---|
| 客服专员 | 流程发起方（人工或系统触发后由其确认），并负责末端回访节点：依据回访结果结束流程，或修改状态后令流程继续流转 |
| 服务导购 | 渠道默认审批链第一级处理人（对应发生差评的订单服务人） |
| 店长 | 渠道默认审批链第二级 |
| 区域经理 | 渠道默认审批链第三级 |
| 直营经理 | 渠道默认审批链第四级（末级，除非被"已完成"分支提前跳出） |
1.3 端到端业务流程
- 外部应用（舆情/客诉监测系统）实时检测各渠道差评；
- 检测到差评后，外部应用调用本应用（forge）的 API 自动发起"差评处理审批流程"；
- 流程主表单由 API 写入：订单信息、差评内容、渠道来源、审批流转状态、处理时限等；
- 审批路由：由客服专员手动指定审批顺序，或按渠道默认链（服务导购 → 店长 → 区域经理 → 直营经理）流转；
- 每个审批节点处理人，在子表单追加一行记录本次处理：系统自动记录填写时间、填写人，处理人人工填写处理进度、处理意见；
- 条件分支：当前节点处理人填写的处理进度 = "已完成" → 流程跳转至客服专员回访节点；≠ "已完成" → 继续流转至下一级审批人；
- 客服专员在回访节点依据回访结果：结束本次处理流程，或修改状态后令流程继续流转（回退/重走相应节点）；
- 流程终结后单据归档，全量处理记录可追溯。
1.4 功能需求清单
| 编号 | 需求 | 说明 |
|---|---|---|
| F1 | 外部系统自动发起流程 | 提供标准 REST API，外部应用调用即创建差评处理流程实例；需鉴权、字段映射、幂等（同一差评不重复建单） |
| F2 | 主表单 API 填值 | 主表单字段（订单信息 / 差评内容 / 渠道来源 / 审批流转状态 / 处理时限等）由 API 在发起时写入，非人工录入；主表单需支持"外部数据写入"模式 |
| F3 | 子表单逐行处理记录 | 子表单（明细）每行 = 一次节点处理过程；自动记录填写时间、填写人，人工填写处理进度、处理意见 |
| F4 | 审批路由规则 | 支持两种路由：(a) 客服专员手动指定审批顺序；(b) 按渠道默认链自动流转（服务导购 → 店长 → 区域经理 → 直营经理）。默认链可随渠道配置 |
| F5 | 条件分支判定 | 依据子表单当前行"处理进度"字段做路由决策：= "已完成" → 跳转客服专员回访节点；≠ "已完成" → 流转下一级。即"节点填写值作为流转条件" |
| F6 | 客服专员回访节点 | 末端固定节点：客服专员依据回访结果结束流程，或修改状态后令流程继续流转（回退/重走节点） |
| F7 | 审批流转状态联动 | 主表单"审批流转状态"随流程推进自动更新（进行中 / 已完结 / 超时 / 已回访等） |
| F8 | 处理时限与超时提醒 | 主表单"处理时限"字段；临近 / 超过时限触发提醒（对接可行性分析第 1 节 企微消息 / 待办） |
1.5 路由与分支规则细节（关键逻辑，需厂家确认可实现方式）
1.5.1 渠道默认审批链配置
- 系统需支持按"渠道来源"（如电商 / 外卖 / 社媒）配置默认审批链；本需求默认链为：服务导购 → 店长 → 区域经理 → 直营经理。
- 客服专员在发起时可覆盖默认链、手动指定各节点处理人及顺序。
1.5.2 分支判定逻辑（逐节点）
当前节点处理人提交子表单 → 读取本行"处理进度"字段
├─ 处理进度 == "已完成" → 跳转【客服专员回访节点】（提前跳出审批链）
└─ 处理进度 != "已完成" → 流转至下一审批级（导购→店长→区域→直营）
若已是末级(直营经理)且仍≠已完成 → 转入回访节点或升级策略(待定)
- 此分支要求"子表单字段值"可被流程网关/条件直接读取并作为流转依据（可行性分析 #4 节点值作条件）。
1.5.3 回访节点与再流转
- 客服专员在回访节点可选：结束（流程完结，状态置"已回访完结"）／ 修改状态后继续（令流程回退至指定节点重走，或携带新状态继续原链）。
- 此项要求"退回到指定节点 + 条件再流转"能力（可行性分析 #9）。
1.6 数据 / 字段说明
- 主表单：订单信息、差评内容、渠道来源、差评等级、审批流转状态、处理时限、创建时间、回访结果 …
- 子表单（每行 = 一次节点处理）：填写时间（自动）、填写人（自动）、处理节点、处理进度（人工，枚举：处理中 / 已完成 / 待回访 …）、处理意见（人工）。
- 路由配置（系统侧）：渠道 → 默认审批链映射；手动指定审批人记录。
1.7 与 forge 能力映射 & 需厂家支持点
- ✅ 外部系统调 forge 发起流程：forge-flow 暴露标准 REST API（可行性分析第 3 节，已支持）；但接口规范、鉴权、字段映射、幂等需厂家明确 / 支持（F1）。
- ⚠️ 主表单由 API 写入：关联可行性分析 #3（跨表 / 关联控件）、#10（节点触发数据操作），需厂家提供外部写入主表字段的配置 / 接口（F2）。
- ⚠️ 子表单逐行记录 + 自动字段：踩中可行性分析 #2（明细控件行内关联）、#3（跨表关联）——需厂家支持明细子表及"自动填充时间 / 人 + 人工填进度 / 意见"能力（F3）。
- ⚠️ 审批路由（手动指定 + 渠道默认链）："手动指定审批人顺序"属可行性分析 #8（自由流程）范畴，当前不原生支持；"渠道默认链"可由流程变量 + 网关实现但需配置层——均需厂家支持（F4）。
- ⚠️ 条件分支（子表单值作流转条件）：底层 Flowable 支持流程变量 + 网关条件（可行性分析 #4），但"读取明细子表行值驱动网关"的可视化配置当前不成熟——需厂家支持把该判定做进配置层（F5）。
- ⚠️ 客服专员回访节点 + 修改后继续流转：依赖可行性分析 #9（退回到指定节点）+ #8（自由流程），需厂家支持（F6）。
- ⚠️ 审批流转状态联动主表单：依赖可行性分析 #10 节点触发数据操作（Flowable 支持，可视化配置需厂家）（F7）。
1.8 验收标准（可检验）
- 外部应用按文档调用 API 后，forge 自动生成一条差评处理流程，主表单订单 / 差评 / 渠道字段与入参一致；
- 同一差评重复调用不生成重复单据（幂等，F1）；
- 每个审批节点处理后子表单新增一行，填写时间 / 填写人自动正确，处理人可填进度 / 意见（F3）；
- 按渠道默认链（导购→店长→区域→直营）逐级流转；客服专员手动指定顺序时按指定顺序流转（F4）；
- 某节点处理进度填"已完成"时，流程跳转至客服专员回访节点而非继续下级；填"处理中"时继续下一级（F5）；
- 客服专员在回访节点可结束流程，或修改状态后令流程继续流转（F6）；
- 主表单"审批流转状态"与流程实际进度一致（F7）；
- 超过处理时限触发提醒（F8）。
1.9 依赖 / 前置
- 依赖可行性分析第 1 节 企微消息 / 待办（F8 提醒落地）；
- 依赖可行性分析 #2 / #3 明细子表能力（F3）；
- 依赖可行性分析 #4 / #8 / #9 / #10（路由、分支、回访、状态联动）；
- 外部应用侧需提供差评检测与 API 调用能力；
- 渠道来源 → 默认审批链的映射数据需由我方梳理后提供给厂家配置。
1.10 合规提示
- 主表单含订单信息、顾客差评内容，可能携带顾客个人信息（姓名 / 电话 / 订单号等），需按《个人信息保护法》做字段最小化、访问权限控制与审计留痕；建议与厂家确认表单数据的权限与脱敏策略。
1.11 非目标（范围外，防蔓延）
- 不涵盖差评的"检测 / 舆情分析"本身（由外部应用负责）；
- 不涵盖差评内容自动分类 / 情感分析（除非后续明确）；
- 不直接对接各渠道 API 抓取（由外部应用完成）；
- 不涵盖回访后的"补偿 / 赔付"等下游业务系统动作（如涉及，作为独立需求另议）。
二、__________（待补充）
请发送第二项需求，我将按上述结构（背景 / 流程 / 功能清单 / 字段 / 能力映射 / 验收 / 依赖 / 非目标）补齐。
三、__________（待补充）
请发送第三项需求，我将按上述结构补齐。