客服每天写的工单，是离用户最近、却最难进产品会的数据。不是大家不重视，而是原因码一塌糊涂：不是「其他」就是「质量问题」，点完就算完结，复盘时什么结论都下不了。要打通「从原因码到改品」，关键是把标签设计成可聚合、可下钻、可问责到责任部门的三层结构，而不是在表单上堆 200 个平铺复选。下面用一套不绑定具体系统字段的建法，你可以迁移到自研、海外 SaaS 或平台自带工单上。
一、三层：域 → 现象 → 责任假设
第一层（域）建议控制在个位数：如物流、品控、描述/期望、支付与售后、账户与安全。第二层（现象）是用户能感知的一句话，如「少发一件」「到件破损」「与主图色差不符」。第三层才落在内部主责猜测：仓拣错、工厂批次、美工做图过饱和、等——第三层可以每月根据数据洗一次，没数据的选项直接砍掉。禁止一线在第三层上自由发挥长文本当标签用。
二、和「改品会」的接口：从聚合表到单 SKU 决策
给产品/供应链固定一张月度聚合表：每 SKU（或 SPU+批次）一行的 Top 原因、金额、重复进线率。设两条红线触发深度复盘：① 同一 SPU 连续两周同一现象占比上升；② 某新品上线后 14 天内客诉率显著高于同店同类。会上的结论要落成三类之一：改设计/改供方、改描述与主图、改仓内 SOP/包材，并写 Owner 与验证指标，而不是只记「再观察」。
三、杀死「其他」与「质量不好」
把「其他」的占比压到 5% 以下，是主管级 KPI。做法是：每周抽查 20 条其他工单，在晨会上当场补码；若某类被反复归到其他，就升格为正式二层码。对「质量不好」类同——必须下钻到可行动子原因，或退回一线补图举证。和 系统对接 时，原因码用稳定英文 key，多语言只展示在 UI 层，避免拉报表时同义多码。
四、和仓库、承运的衔接
当域落在物流时，工单要能一键盘出物流号与面单，方便和 009/011 的排查联动。仓侧 WMS 事故码与客服码不必 1:1 相同，但要有映射表，否则定责会永远在「你扫错了」和「他贴反了」之间。
下篇 013 讲店小秘/ERP 与 WMS 的 SKU 主数据，那是标签与库存共同的「字典」问题。
