⚠️ 系统只记录评价，回访、判责和催办散落在线下台账与群聊，无法看到处理进度。
CASE STUDY · 03
低分评价管理系统
让每一条低分评价，都有明确的跟进路径。
原系统只能记录订单与评价，无法管理低分产生后的处理进度。回访、判责和跨部门交接全部发生在线下，系统内看不到由谁处理、处理到哪一步、最终责任归属。
🧩 不重做评价系统，而是在原后台补齐“识别 → 回访 → 判责 → 通知 → 留痕”的闭环。
✅ 不是功能上线数量，而是低分评价能否被及时接手、完成判责并可追溯地闭环。
01
BACKGROUND
处理什么问题
原系统记录了评价，
却没有管理评价之后发生的事。
用户提交评价后，后台只能保存订单与评价信息。低分评价的筛选、回访安排、责任判断和处理结果都转移到线下台账与群聊中完成，系统内看不到完整进度。
现状数据 · 统计口径：2026.01–03，全国
998,771订单数
44,545评价数
1,998低分评价数
0.2%低分评价率
改造前 · 一条低分评价如何被处理
后台记录评价→人工筛选低分→导出线下台账→群聊催办回访→线下完成判责→人工同步结果
为什么必须处理
- 规模已经不能依赖人工记忆。统计期内有 1,998 条低分评价，需要稳定而非临时的处理方式。
- 低分原因跨越多个责任主体。问题可能来自服务运营、产品体验、产品故障、权益政策或资源配置，单一部门无法独立处理。
- 判责结果影响后续业务与指标。评价是否有效、责任如何归属，会影响满意度统计，也决定后续由谁改进。
02
SOLUTION
怎么解决
把散落在后台、表格和群聊中的动作，收进同一条线上流程。
方案不是推翻原评价后台，而是在原有评价数据上补齐任务触发、回访、判责、通知、权限与日志能力。
规则识别
用下单时间与评分判断是否进入低分处理流程。
角色接力
客服/区域运营回访，体验团队判责，责任部门承接。
关键通知
仅在任务产生和判责完成时推送，明确下一位处理人。
证据留痕
回访附件、字段修改、操作人和时间统一进入系统。
对比维度改造前方案设计后
数据管理 后台 + 线下台账评价数据与跟进信息分散 一条评价，一份完整记录集中展示基础信息、回访、判责和状态
任务触发 人工筛选 + 群内通知需要逐条识别并主动寻找处理人 规则自动识别并推送按下单时间与评分触发待回访任务
跨部门协作 群聊反复确认客服、区域运营与体验团队来回同步进度 同一详情页，分角色维护每个角色只编辑自己负责的信息模块
判责依据 证据分散回访文字、图片和录音难以关联与复核 证据与评价绑定单条评价最多上传 9 个附件，统一沉淀
过程追踪 人工同步，无历史记录无法确认当前进度和字段变化 状态与日志线上可见记录操作人、时间、字段与文件变化
03
CORE FLOW
核心业务逻辑
只有“有效低分评价”进入回访和判责。
系统先做规则过滤，再把任务交给对应角色；每一次交接都对应状态变化和信息推送。
只有低分评价进入后续的回访和判责判断。
超出有效期的评价标记为无效，不参与后续流程。
手动改为无效时，需记录恶意评价、用户责任或其他原因。
待统一口径 原需求资料中同时出现“下单时间 < 7 天”和“≤ 7 天”两种写法，进入开发前需要由业务方统一边界。
04
PERMISSION & HANDOFF
跨部门如何协作
权限跟着职责走，通知跟着任务走。
所有人都能查看同一条评价，但只有负责该环节的角色能编辑对应内容，减少字段误改和责任不清。
有效低分产生
通过钉钉群机器人，将待处理订单信息推送给客服或区域运营，触发回访任务。
接收人：部门标签成员 / 对应处理角色判责完成
将判责结果推送给对应责任部门与责任人，完成下一环节交接。
接收人：责任部门 / 订单责任人05
PRODUCT DETAILS
方案如何落到页面
列表负责定位任务，详情页负责完成一次处理。
01 / 评价管理列表
集中查询与识别待办
除基础评价数据外，新增有效性、无效原因、处理状态和判责结果，支持按业务条件快速筛选。
查看筛选字段
- 下单时间（默认近 30 天）
- 换电订单号
- 换电记录单号
- 省份 / 城市
- 车型
- 车辆运营类型
- 车牌号
- 是否新用户
- 处理状态
- 是否有效
- 无效原因
- 判责结果
评价列表共 1,998 条
下单时间换电记录单号省份城市车型评分处理状态是否有效判责结果操作
05-14 15:43HD***0918浙江宁波巧克力★★☆☆☆待处理——查看
05-14 13:06HD***0862浙江杭州巧克力★★★☆☆已处理有效服务运营查看
05-13 18:22HD***0741上海上海巧克力★☆☆☆☆待处理——查看
05-13 16:48HD***0695江苏苏州巧克力★★☆☆☆已处理无效用户责任查看
02 / 评价详情
在一个页面完成回访与判责
基础信息只读，回访和判责按权限编辑；查看模式与编辑模式使用不同按钮，避免误操作。
- 低分原因、用户跟进情况：必填，单项最多 1,000 字
- 回访凭证：选填，最多 9 个文件
- 支持图片、PDF、视频、音频和 DOCX
- 有效性与判责结果：必填；选择“其他”时补充原因
基础信息（只读）
订单来源换电服务评价星级★★☆☆☆
用户反馈现场等待时间较长…
已完成电话回访，补充处理说明与凭证。
有效⌄
服务运营⌄
03 / 通知与操作日志
让交接可达，让修改可查
通知卡片提供评价详情入口；日志记录操作人、操作时间和修改内容，文件上传与删除也单独留痕。
- 文本字段记录原值与新值
- 首次填写时，原值统一记为“—”
- 文件记录名称、格式、上传或删除动作
10:24体验团队 更新判责结果
09:51区域运营 上传回访凭证 2 份
以上界面依据项目真实后台结构脱敏复刻；订单号、手机号与车牌号均使用掩码数据，不展示真实用户信息。
06
EFFICIENCY
效率改善来自哪里
减少的不是一个步骤，而是四类重复沟通。
减少无效评价进入回访造成的重复处理。
让下一责任人及时知道“轮到我处理”。
判责时无需再次向回访人员索取材料。
降低跨部门确认成本，为复盘提供依据。
指标类型指标内容当前证据
现状基线1,998 条低分评价 / 0.2% 低分率真实数据
效率目标问题处理 48 小时内完成，闭环时效提升 30%方案目标
结果目标闭环解决率 100%，整体满意度提升 0.03待上线验证
由于项目未跟进到正式上线，我不能把目标值写成实际结果。这个案例能证明的是：我完成了问题定义、业务规则、流程、权限和页面方案，并将项目推进至评审 / 开发排期阶段。
07
BOUNDARIES
如果继续推进
还需要补齐四个上线条件。
01统一 7 天有效期是“< 7 天”还是“≤ 7 天”的边界口径。
02明确“闭环完成”的定义，并补充责任部门处理、验收与二次回访。
03定义超时升级、通知失败重试与重复通知的幂等规则。
04补充附件大小、隐私、保存周期及历史数据迁移规则。