社区超市客服：客诉台账根因归因分析器——一个月的投诉按品质/价格/效期/服务/政策五类拆开，每类落点必须指出台账里哪个字段支撑，给店长的整改单最多三条

你是社区超市的客服主管。客诉登记台账记了一个
月，我把它给你，请按根因归因，输出给店长的
月度客诉结构表和整改单。

我会给：
1. 一个月的客诉登记台账：日期 / 渠道（现场·
   电话·微信群）/ 顾客描述原文 / 涉及商品或
   岗位 / 当班处理人 / 处理结果 / 顾客是否
   接受结果
2.（可选）上月台账——用来比趋势；没有就直说
  没有，趋势一节跳过

五类根因口径（严格按这个分，不要自己发明类别；
描述里两类都沾的，归顾客实际受损更深的那类，
并在备注里注明兼类）：
A 品质：生鲜变质、破损、有异物——货的问题
B 价格：价签与结算价不符、称重争议、折扣没
  生效——标价和收银系统的问题
C 效期：买到临期无提示、过期在售——效期巡检
  的问题
D 服务：排队久、语气冲、退换被拒、承诺没
  兑现——人的问题
E 政策与设施：储值卡、发票、购物车、停车——
  制度或硬件的问题

输出格式：
- 第一张表：类别 / 件数 / 占比 / 涉及部门 /
  顾客不接受结果的件数——最后一列最能说明
  处理质量，处理结果栏全写「已解决」没有意义
- 第二张表只列件数前三的类别，每类一行
  「根因落点」：不是「生鲜品质差」，而是
  「叶菜类变质投诉集中在闭店前两小时售出的
  单品，指向晚市折价启动太晚」这种落到环节
  和时段的写法——落点必须指出台账里哪个字段
  （日期、时段、商品名）支撑它，指不出来源
  的落点不许写
- 最后给店长的整改单最多 3 条，每条写明：
  改哪个环节、谁牵头、怎么验证改掉了——下个
  月台账里该类件数就是验证口径

限制：
- 件数不足 15 件的类别，占比保留但标注
  「样本小，不宜下结论」
- 顾客描述里有原话的才允许写「员工用语问题」，
  没有原话的不许推「态度差」
- 不写「加强服务意识」「优化顾客体验」这类
  无法验证的话
- 渠道分布单独一行报数（现场 X / 电话 X /
  群 X），不进五类归因——渠道是入口不是根因
- 不要开场白，直接从第一张表开始

为什么这样写

客诉台账的价值不在登记，在翻译：顾客不会说「你们的效期巡检流程有漏洞」，只会说「买到的酸奶过期了」。五类口径就是这次翻译的字典——A 类多要去找供应链和存储，B 类多要查换档改价流程，C 类多说明效期巡检没跑，D 类是排班和培训的事，E 类是店长定制度的事。不翻译，台账就只是客服的加班记录。

「顾客不接受结果的件数」这列是特意加的。台账里最容易失真的是处理结果栏——柜台上图快全勾「已解决」，月底一看零客诉升级，店长还以为天下太平。顾客接不接受是比「处理完成」硬得多的信号，而它是顾客自己勾的，客服编不了。

「落点必须指出来源字段」这条限制是防模型的老毛病：AI 最爱写「晚市人手不足导致服务缩水」这种听起来专业、台账里却一个字都查不到的推断。要求指出具体字段（哪天、哪个时段、哪个商品），模型就只能贴着数据说话，编不出漂亮话。

小样本标注那条是给中小门店留的活路：很多社区超市一个月客诉就二三十件，某个类别两三件就开始谈占比、谈趋势，会得出吓人又没用的结论。样本小就明说样本小，把注意力让给件数多的前两类。

变量