客户反馈洞察

要解决的问题

客服工单、应用商店评价、问卷开放题堆在一起时，团队常见的处理方式是挑几段"典型反馈"转给产品。这种做法有两个硬伤：引文不代表分布，被领导注意到的问题不一定最高频；叙述混着推断，"客户希望做夜间模式"到底是真实痛点还是个嗓门大的请求，没人说得清。

客户反馈洞察 的目标不是生成一份漂亮的总结，而是把每条反馈编码成可审计的证据，让"客户说了什么、分析推断了什么、团队下一步该验证什么"三层信息始终分开。

核心能力与工作流

1. 先定义决策，再动手分析。 第一步明确这批反馈要支撑的是缺陷分诊、路线图规划、流失挽回还是活动复盘，并记录时间范围、渠道、产品线与客群边界。没有这一步，分析结果往往无法落地。

2. 数据画像不静默丢数据。 汇报总量、可用记录数、渠道分布、语言构成、重复与疑似垃圾内容；任何排除规则必须留痕并记录条数。原始文本始终保留，只做标准化而不改写。

3. 逐条编码，允许一条多码。 按 references/analysis-schema.md 对每条可用记录标注旅程阶段、反馈类型、主题子主题、严重度、情感倾向、证据摘录与置信度。一条反馈里有三个独立问题就拆成三条，不强行压成一个主标签。

4. 主题构建与透明打分。 主题要具体到可行动（例如"支付结果页未明确显示是否成功"，而不是笼统的"体验不好"），并报告记录数、占比、趋势、严重度分布与正反两方面证据。优先级按频率、用户伤害、业务影响、趋势紧迫性、证据置信度五个维度各打 1–5 分，组件分直接展示，不会折叠成说不清的"AI 优先级"。

5. 把建议写成待验证的假设。 每个高优主题输出问题陈述、受影响用户、疑似原因（明确标注为假设）、行动、负责方、成功指标与验证方式，避免把客户点名的功能当作唯一解。

边界与注意点

• 只使用用户有权分析的反馈，手机号、邮箱、地址、账户 ID 等标识必须脱敏，同时保留稳定的来源 ID 供审计。
• 不做样本外推断：小样本结论会被明确标注，情感分只是信号，不能替代问题分析。
• 交付物包含数据与方法说明、主题排序表、带来源 ID 的证据附录、分群对比、行动清单与排除项说明，各项计数必须能与可用/排除/重复记录对上账。