Q3.08.3Support-ticket error mining设计研究
客服记录是低成本的错误来源
别名: 客服工单 · 支持日志 · ticket mining
概念解释
客服工单、在线聊天和退款备注是已经付过采集成本的错误档案：用户在真实后果下主动描述“哪里走不通”。它比实验室更便宜、覆盖面更大，也更接近真实损害。它不是随机抽样的错误率，而是一张被投诉意愿、渠道可达性和坐席分类规则过滤过的清单。当作普查会高估爱投诉的问题、低估默默离开的问题。
机制
工单要经过三道选择。用户得认为问题值得花时间、找得到入口、愿意留下痕迹；坐席再把叙述压进业务标签，标签服务于响应时限和部门分工，不一定对应界面失败类型；重复联系、一单多问题、机器人分流还会改变计数单位。于是“标签频率”测量的是组织如何收件，夹杂着真实失败。低成本来自数据已存在，不来自它自动等于错误测量。越是造成资金、账号或法律后果的失败越容易进档案，越是一次性的困惑越容易消失。
怎么研究
先弄清工单的生成路径、标签词典和计数单位（人、单、还是会话）。主题分析从原始叙述而不是从坐席标签起步，再把高频主题映射到界面状态。与产品日志对齐同一时间窗，检查有日志失败却无工单、以及有工单却无对应事件的缺口。估计谁从不进客服：新用户、低权限用户、非工作时间用户。工单适合发现和排序问题，要用任务测试或日志率去估计发生率，而不是直接把标签占比当成错误率。
边界
没有客服渠道、或渠道被外包且拿不到原文的产品，这条来源不可用。高度敏感的失败可能被用户改走监管或社交媒体，工单反而变少。坐席绩效考核若奖励快速关单，标签会系统性变宽、变轻。机器人先过滤一层之后，人类坐席看到的已是被筛过的尾巴。内部员工自己提的单与外部用户的单不应合并。
怎么落地
- 每月抽一批未二次编码的原文，按界面步骤重标，而不是只看部门标签排行。
- 把“有失败日志但无工单”的功能标成沉默失败，列入观察或访谈，不因为客服安静就结案。
- 禁止用工单量单独做可用性 KPI：入口改版、机器人拦截、营业时间都会让量变化而错误不变。
- 修复后在同一标签与同一叙事主题上观察下降，并配一条日志率；只降标签不降叙事，可能是坐席改了分类。