Customer Feedback

---
name: customer-feedback
description: 用户反馈分析——一堆吐槽和评论聚成类、排出优先级、落成产品能直接排期的行动项
---

# 用户反馈分析

## 适用场景
应用商店评论、问卷开放题、客服工单、群聊记录、issue 列表——
一堆零碎的话，要变成"先修哪个"。

## 步骤

### 1. 先归一，再分析
反馈来源多半不止一处。先统一成一张表，每行一条：
`时间 / 来源 / 原话 / 用户身份（付费？用多久了？） / 涉及的功能`。
原话一字不改地留着——后面产品会想看原话。

### 2. 聚类：按「用户想干什么被挡住了」分，不是按关键词分
"闪退"和"打不开"和"点了没反应"可能是同一件事，"太贵了"和"没有免费版"也是。
**按用户的目标聚**，不要按词聚。

每一类给一个用人话写的名字："想导出但找不到入口"，不是"导出模块问题"。

### 3. 每一类算三个数，缺一个都排不了序

| 指标 | 怎么算 | 为什么要 |
|---|---|---|
| 提及量 | 这一类有多少条 | 多不等于重要，但少基本不紧急 |
| 严重度 | 用不了 / 难用 / 不爽，三档 | "用不了"哪怕只有 3 条也得先修 |
| 说话的人是谁 | 付费用户占比、老用户占比 | 付费用户说难用，比一百条白嫖用户的许愿重 |

**别只按条数排序**——按条数排，排在最前面的永远是最吵的那群人。

### 4. 分清三种东西，它们的去向完全不同
- **Bug**：有人用不了。→ 直接给修复项，带复现路径
- **缺失**：功能没有。→ 进需求池，写清用户原本想干什么
- **许愿**：用户直接提了个方案（"加个按钮"）。→ **别照着做**，回到他想解决的问题

第三种最容易出事：用户说"想要一匹更快的马"。把他的原话记下来，但排期排的是"他要去哪儿"。

### 5. 找矛盾
有人嫌步骤多，有人嫌选项少——这不是数据噪声，是两拨不同的用户。
把矛盾单列一节，让产品决定服务谁。

## 交付

`反馈分析.md`：

1. **结论**：这一批反馈最该动的三件事，每件一句话 + 依据
2. **分类明细表**：类别 / 条数 / 严重度 / 付费用户占比 / 代表性原话 2-3 条（一字不改）
3. **Bug 清单**：可直接进缺陷库，带复现步骤
4. **需求池**：每条写"用户想达成什么"，不是"用户要什么按钮"
5. **矛盾与分歧**
6. **这批数据不能回答什么**：只有会说话的用户在说话，沉默的那部分不在样本里

用 `gen_diagram` 出一张分类占比图，横轴按严重度分层，比单纯的饼图有用。

## 红线
- **原话不许润色**。用户骂人的话也原样留着，那是强度信号。
- 不要把一条极端反馈写成"用户普遍反映"。
- 样本有偏就明说：应用商店评论天然是骂的多，不能当满意度。

## 质量标准
- 每一类都挂着能回溯的原话
- 优先级有依据，不是感觉
- 产品拿到就能排期，不需要再问一轮"这个具体是什么意思"