企业官网建设流程全解析

今天主要在补电商平台管理端的治理业务。之前不少页面已经能看、能点，但部分功能还停留在“展示数据”的阶段，缺少后台定时检查、状态联动和数据持久化。

所以今天没有继续堆新页面，而是把售后、投诉和商家入驻这三块业务往完整流程上推进了一步。

一、补全平台售后监管流程

首先处理的是管理端售后监管。

原来的售后业务主要集中在买家申请和商家处理，平台端能够看到的数据比较有限。今天补上了平台售后列表、详情、处理记录和审计时间线，并增加了几个实际操作：

• 平台介入售后
• 催促商家处理
• 关注重点售后
• 查看售后状态变化
• 查看管理员操作记录
• 业务完成后自动关闭平台待办

这些操作不再只是修改页面状态，而是会把结果写入 Redis。管理员刷新页面或者重新登录后，之前的操作记录仍然存在。

售后审计记录按售后单独保存，后续查看详情时，可以按时间顺序还原整笔售后的处理过程。

二、增加售后 SLA 超时预警

平台能够查看售后还不够，还需要主动发现长时间没人处理的售后。

今天增加了一个后台 Worker，每隔 5 分钟扫描一次售后数据，并按照处理时间生成平台待办。

目前使用的规则是：

• 待商家处理超过 24 小时：生成超时待办
• 待商家处理超过 48 小时：升级为严重超时
• 售后退款、拒绝或者处理完成：自动关闭待办

管理员可以在待办中心认领任务，也可以释放自己认领的任务。认领之后，页面会显示当前负责人和认领时间，避免多名管理员重复处理同一笔售后。

系统在生成或者升级预警时，还会自动向管理员发送通知。

三、投诉业务改成分阶段计时

投诉和售后不太一样，不能只从投诉创建时间开始一直计算。

一笔投诉可能经历：

1. 买家提交投诉
2. 平台受理
3. 商家提交说明和凭证
4. 平台作出裁决
5. 买家再次申诉

如果所有阶段都按照同一个时间计算，很容易出现误判。因此今天把投诉 SLA 改成了分阶段计时。

目前的时间规则如下：

投诉进入新阶段后，会重新计算该阶段的处理时间。

例如投诉已经被平台受理，接下来应该等待商家举证，那么系统就不会继续使用投诉提交时间，而是从进入“等待商家举证”阶段的时间重新开始计算。

等待商家举证超时后，除了通知管理员，也会通知对应商家及时处理。

四、解决商家入驻审核时间不增长的问题

商家入驻审核接入统一待办时，遇到了一个比较隐蔽的问题。

项目目前有一部分演示申请数据，提交时间是这样生成的：

SubmittedUnix: time.Now().Add(-7 * time.Hour).Unix()

这种写法在页面展示时看不出问题，但后台每次重新扫描，提交时间都会重新变成“当前时间减去 7 小时”。

结果就是这条申请永远只提交了 7 小时，无论系统运行多久，都不会自然超过 8 小时的预警线。

最后的处理方式是：第一次扫描到未完成申请时，把它的计时基准保存下来。

ReferenceAt int64

后续扫描即使演示数据重新生成，也继续使用第一次保存的ReferenceAt，不再覆盖。

这样申请时间才能正常累计，SLA 预警也能真正触发。

商家入驻目前的规则是：

• 待初审超过 8 小时：生成审核预警
• 资质复核超过 12 小时：生成审核预警
• 任一阶段超过 24 小时：升级为严重超时
• 审核通过或者驳回：立即关闭对应待办

如果申请从待初审进入资质复核，会重新开始计算新阶段的时间，同时清除上一个阶段的认领人，避免审核责任混乱。

五、统一平台待办中心

完成三类 SLA 后，把它们统一接入了平台待办中心。

目前待办中心包含：

• 售后时效
• 投诉纠纷
• 商家入驻

管理员可以按照以下条件筛选：

• 处理中
• 已认领
• 待认领
• 已自动关闭
• 普通超时
• 严重超时

也可以搜索业务编号、订单号、商家名称、经营类目和投诉原因。

每种待办都可以直接跳转到对应业务页面。例如商家入驻待办点击“前往审核”后，会自动打开相应申请，而不是让管理员再去申请列表里重新查找。

这次也顺便调整了空状态判断。选择“商家入驻”标签时，只判断当前入驻待办是否为空，不会因为售后还有数据，就导致当前页面的空状态不显示。

六、数据持久化和运行验证

这次新增的待办不是只保存在内存里，而是统一写入 Redis。

主要保存了：

• 业务编号
• 当前处理阶段
• SLA 计时基准
• 预警等级
• 是否已经生成过预警
• 首次发现时间
• 关闭时间
• 认领管理员
• 认领时间

这样服务重启后，待办状态、认领关系和计时基准都不会丢失。

为了避免重复生成待办，后台每次扫描都会对比已有记录。状态和预警等级没有变化时，不会重复写入通知。

今天还补了相关测试，主要检查了：

• 未超时申请只追踪、不生成预警
• 动态演示时间不会覆盖固定计时基准
• 达到预警时间后正常生成待办
• 重复扫描不会重复生成
• 升级严重超时时保留认领人
• 审核完成后自动关闭
• 进入新审核阶段后重新计时

最后重新启动了前端服务，并读取 Redis 检查 Worker 的真实运行情况。系统已经成功写入巡检时间，也实际生成了一条商家入驻审核超时待办。

七、今天的收获

今天做的内容看起来主要是“待办”和“超时提醒”，但真正麻烦的地方不是页面，而是不同业务状态之间的联动。

如果只做一个待办列表并不难，难的是保证：

• 待办不会重复生成
• 服务重启后计时不会丢失
• 业务进入新阶段后重新计时
• 处理完成后自动关闭
• 严重等级升级时保留负责人
• 前端展示和后端状态保持一致

特别是商家入驻的动态时间问题，如果只看页面很难发现。只有让 Worker 实际运行一段时间，再检查 Redis 中的计时数据，才能确认它真的在增长。

下一步准备继续补充待办优先级、SLA 规则配置和管理员处理量统计，让统一待办不仅能够提醒问题，还能更合理地分配平台审核任务。