用 AI 整理客户反馈:先定分类规则,再统计问题

先明确你要统计什么

任务速览:入门,会复制文字即可。输入六条虚构反馈;输出逐条标签、原文证据与去重后的计数。重点练习分类规则和人工核对。

客服群里有十条抱怨,不等于十位客户遇到十个故障。AI 适合先做归类候选,人再核对。本练习交付逐条标签和问题提及数,不判断客户价值,也不自动回复客户。先规定统计单位:一条反馈可以有多个标签,每个标签在该条中最多计一次。

准备可上传的材料

使用公司允许的文字 AI 工具即可,不需要联网、插件或付费 API;免费方案可能限制长度与次数,具体以账户为准。练习直接用下方虚构数据。处理真实材料时,先在本地去掉姓名、电话、订单号、精确地址和可识别身份的细节,使用 F01 这类编号。编号与真实身份的对应表留在本地。

去掉姓名不等于匿名:独特事件仍可能识别人。未经允许的投诉记录不要上传。OpenAI 说明个人服务内容可能用于模型改进,可通过数据控制选择退出;这类设置也不能替代公司数据政策。

第一步 用六条记录练习

F01:验证码等了五分钟才收到,后来登录成功。
F02:点导出后转圈,最后没有下载文件。
F03:导出报错,重新登录后还是报错。
F04:同一订单看起来扣了两次,请帮忙查一下。
F05:登录和导出现在都正常,想加个深色模式。
F06:同事转述 F02 的情况,没有补充新信息。

先读一遍:F04 只是用户怀疑重复扣费;F05 明确说登录和导出正常;F06 是重复转述。这三种情况最容易被错误计数。

第二步 固定规则再交给 AI

按以下规则处理上述六条虚构反馈:
标签只用 登录、导出、账单、功能建议、待确认。
登录:登录环节出现延迟或失败;导出:无法正常取得文件;
账单:对扣款有疑问,不能标成已确认扣款故障;
功能建议:要求新增或改变功能;无法归类才用待确认。
保留编号和原文证据,可多标签;否定句不能当故障。
明确重复转述标 duplicate_of,不计入提及数。
输出逐条:编号/标签/原文证据/需人工核查/duplicate_of;
最后列每类提及数和计数分母,不推断客户人数或原因。

第三步 对照答案查错

按本练习定义,F01 是登录,F02、F03 是导出,F04 是账单,F05 是功能建议,F06 重复指向 F02。排除重复后分母为五条,登录一条、导出两条、账单一条、功能建议一条、待确认零条。F03 提到重新登录只是尝试过的操作,不能据此增加登录问题。

这里的“两条导出反馈”不是“两名客户”。多标签时,各类计数相加可以大于反馈总数;因此别强行让比例合计百分之百。真实材料没有明确重复关系时,先列疑似重复供人检查,不凭措辞相似直接删除。

六条虚构反馈分类:F01登录,F02和F03导出,F04账单,F05功能建议,F06为F02的重复转述。排除重复后分母五条,分类数为1、2、1、1、0。重登是尝试,账单疑问未经证实,正常描述不能当故障。
虚构反馈练习:先排除明确重复,再核对否定句、尝试操作与未经证实的投诉。

怎样扩展到真实工作

先用少量人工标注记录校准规则,再分批处理,每批沿用同一版标签定义。逐条检查高风险记录、待确认项和疑似重复,再随机抽查普通记录。若经常出现无法归类的同一问题,修订标签后重跑旧批次,避免新旧口径混算。

最终汇报只说样本中的问题提及和需要排查的线索。不要把模型自报的高置信度当准确率,也不要根据这份分类自动退款、封号或评价员工。

参考资料

资料核查:2026年10月10日。示例为原创虚构练习,未声称已在产品中实测。

© 版权声明

相关文章