---
name: feedback-themes
description: 把 NPS 评论、问卷回答、应用商店评价等开放式客户反馈归纳成主题，给出每个主题的条数、代表性原话、情绪倾向和建议的行动；有评分时一并算出 NPS。用于有人发来问卷结果、NPS 回复、评价或反馈导出数据，问“客户都在说什么”、要主题归纳、客户之声总结，或者问先修什么的时候。
---

# 反馈主题归纳

主题分析告诉团队：客户说得最多的是什么、有多强烈、该怎么应对。每条评论都读、都编码、都计数、都引用：只有数字没有原话显得空洞，只有原话没有数字，就会让嗓门最大的那条评论胜出。

## 适用场景

- NPS 或 CSAT 问卷已经结束，手上有评论。
- 导出了应用商店、G2 或应用市场的评价。
- 做路线图规划之前，把客户的原话带进讨论。
- 不适用于一对一访谈记录：用 user-interview-synthesis。也不适用于把工单整理成 FAQ：用 faq-from-tickets。

## 需要准备

- 评论，每行一条。有评分（NPS 是 0 到 10 分）和分群信息（套餐、地区、使用时长）会更好。
- 时间段和问卷的发放方式，用于标题部分。
- 评论少于 30 条也照样做，但要说明数量少，并且不写百分比。

## 步骤

1. **有评分就先算分数。** NPS = 推荐者（9 到 10 分）占比减去贬损者（0 到 6 分）占比；被动者（7 到 8 分）只计入总数。结果写成 -100 到 100 之间的数字，并注明回复数。本技能的默认做法：回复少于 30 条时，说明样本量小。
2. **先通读一遍，再编码。** 给每条评论打 1 到 3 个编码：说明它讲什么的简短标签（“加载慢”“价格”“客服有帮助”）。一条评论可以同时带正面和负面编码。
3. **把编码归为 5 到 10 个主题。** 主题是团队可以采取行动的具体话题（“报表加载慢”），而不是一个大类（“性能”）。提及少于 3 次的主题合并到“其他”，除非涉及数据丢失、安全或计费错误。
4. **计数并标注情绪。** 每个主题写：评论条数、占全部评论的比例、情绪倾向（正面、负面、混合）。有评分的话，写出提及中有多少来自贬损者、多少来自推荐者。
5. **每个主题选 2 条原话。** 选典型的，而不是最极端的。一字不改地引用；可以用“……”删节，但绝不改动措辞。删掉姓名和邮箱。
6. **每个负面主题建议一项行动。** 一个具体的下一步，以及由谁负责（这里写团队即可，不必写到个人）。如果某个主题需要更多数据才能行动，就写明需要什么数据。
7. **写要点总结。** 3 条：最大的负面主题、最大的正面主题，以及（如果给了上一期数据）与上一期相比新出现或上升的内容。

## 输出格式

```markdown
# 反馈主题 — [来源]，[时间段]

**回复数：** [N] · **NPS：** [分数]（推荐者 [推荐者]%，被动者 [被动者]%，贬损者 [贬损者]%）[或“未提供评分”]

## 要点
- [最大的负面主题，附条数]
- [最大的正面主题，附条数]
- [新出现或上升的内容，或“未提供上一期数据”]

## 主题
| 主题 | 提及数 | 占比 | 情绪 | 来自贬损者 / 推荐者 |
|---|---|---|---|---|
| [主题] | [n] | [%] | [+/–/混合] | [n / n] |

### [主题]
- “[原话]”
- “[原话]”
**建议行动：** [下一步] — [负责团队]

## 其他（[n] 条评论）
- [用一行概括零散话题]

## 数据说明
- [样本量、缺少的分群、评论的编码方式]
```

## 示例

**输入（112 条回复中的 8 条，节选）：**

> 3 — “导出慢得要命，周报我已经放弃了”
> 9 — “客服团队很棒，小雅几分钟就帮我解决了问题”
> 5 — “涨价了，可什么都没变”
> 10 — “模板很好用”
> 2 — “导出又超时了”
> 8 — “还不错，就是手机 App 不太顺手”
> 6 — “对我们这种规模的团队来说太贵了”
> 9 — “客服响应很快”

**输出（节选）：**

```markdown
# 反馈主题 — NPS 问卷，第三季度

**回复数：** 112 · **NPS：** 14（推荐者 41%，被动者 32%，贬损者 27%）

## 要点
- 导出慢或失败：提及 23 次，几乎全部来自贬损者。
- 客服又快又友好：提及 31 次，是推荐者给出的头号理由。
- 未提供上一期数据，因此没有趋势。

## 主题
| 主题 | 提及数 | 占比 | 情绪 | 来自贬损者 / 推荐者 |
|---|---|---|---|---|
| 客服响应快、有帮助 | 31 | 28% | + | 2 / 24 |
| 导出慢或超时 | 23 | 21% | – | 19 / 1 |
| 价格高于价值 | 17 | 15% | – | 12 / 0 |

### 导出慢或超时
- “导出慢得要命，周报我已经放弃了”
- “导出又超时了”
**建议行动：** 测量大客户的导出耗时，优先解决超时 — 研发团队

## 数据说明
- 客服相关的原话里提到了客服人员的名字；对外分享的版本已删除姓名。
```

## 发送前检查

- [ ] 如果写了 NPS，用的是 9–10 分占比减 0–6 分占比，并注明了回复数。
- [ ] 每个主题都有条数，条数来自实际编码过的评论。
- [ ] 原话一字未改、具有代表性，已删除姓名和邮箱。
- [ ] 主题足够具体，团队知道要修什么。
- [ ] 每个负面主题都有一项建议行动。
- [ ] 小样本已注明；少于 30 条评论时不写百分比。

## 常见错误

- 主题写成“用户体验”或“产品”。要说清是它的哪一方面。
- 把最愤怒的评论当作典型来引用。
- 一条长评论里有 4 个抱怨，却只算一个主题。每个点都要编码。