如何在软件产品中向客户征集反馈：时机、渠道与话术
阅读约 1 分钟
要在软件产品中向客户征集反馈，就针对用户刚刚做过的某件事，在他们做这件事的地方，问一个具体的问题。刚导出完报表就问”刚才那次导出满足你的需求了吗？“，会得到回答；在页脚里写一句”告诉我们你对产品的看法”，只会得到沉默。本页接下来讲的，就是时机、渠道和确切的措辞。
关于这个话题的大多数建议，都是写给商店和客服台的。软件团队清楚地知道用户一秒钟之前做了什么，所以问题完全可以围绕那件事来问。
| 时机 | 在哪里问 | 现成的问法 |
|---|---|---|
| 一项任务刚完成之后 | 应用内，紧挨着结果 | “刚才那次导出满足你的需求了吗？” |
| 首次使用新功能之后 | 应用内，只问一次 | “你想用批量编辑完成什么事情？” |
| 支持工单解决之后 | 在支持对话里 | “问题解决了吗，还是仍然有哪里不对？” |
| 用户中途停下或离开某个流程之后 | 一天后发邮件 | “你停在了设置的第 3 步，是什么挡住了你？” |
| 经常使用 30 天之后 | 由一个具名的人发邮件 | “你最想改变的那一件事是什么？” |
| 用户取消订阅时 | 在取消流程里 | “是什么让你今天决定离开？” |
| 你交付了他们提过的需求之后 | 在他们提出请求的地方 | “你提过 CSV 导入，现在上线了。它能覆盖你的情况吗？” |
什么时候向用户征集反馈最合适？
最合适的时机，是用户刚完成某件事、细节还留在脑子里的时候。紧跟在一个操作之后的问题，会得到关于这个操作的回答。而凭空冒出来的问题，得到的要么是对方当下心情的回答，要么根本没有回答。
不要在注册时问，因为那时还没有人用过任何东西。不要在任务进行到一半时问，因为你打断的正是你想了解的那件事。一旦对方回答过了，在你有进展可以回复之前，就不要再去打扰他。
应该在哪里向客户征集反馈？
在体验发生的地方问。应用内的提示适合问关于某个界面的问题。支持对话适合问关于某次修复的问题。邮件适合问关于一周使用情况的问题，或者关于对方中途放弃的某个流程。通话适合问那些你无法预测的问题。
每个渠道得到的回答类型都不一样：
- **应用内：**简短、即时、具体，但只来自当下在场的人。已经离开的用户，你什么也听不到。
- **支持对话：**来自那些已经沮丧到愿意写信进来的人。适合找出坏掉的东西，不适合评判产品的其余部分。
- **邮件：**来自更少的人、篇幅更长的回答，也是联系那些已经沉默的用户的唯一办法。把它写成一位具名的人发出的简短留言，里面只放一个问题。
- **访谈：**了解人们为什么这样做事的办法。请他们演示自己的工作方式，并在他们操作时保持安静。
反馈信号质量介绍了如何衡量每个渠道告诉你的内容。
怎样才算专业地征集反馈？
针对具体的事，说明你为什么问，并且让回答的成本不到一分钟。专业的问法会点明那个时刻，让对方明白会有真人阅读答案，并且不会为打扰而道歉。
点明确切的操作（“你刚刚运行的那次导出”），只问一件事，使用没有必填项的自由文本框，并以名字签名。
征集反馈时用什么样的句子比较好？
好的句子，是针对一个具体时刻、几个字就能回答的问题。对比下面两列。左边的可以耸耸肩就回答，右边的则需要对方回想起一些真实的事情。
| 较弱的问法 | 更有力的问法 |
|---|---|
| “有什么反馈吗？” | “设置这个功能时最难的是哪一步？” |
| “你觉得我们的产品怎么样？” | “上周你用它做了什么？” |
| “请为你的体验打 1 到 10 分。” | “你今天想做的事做完了吗？” |
| “告诉我们该如何改进。” | “这周有什么事拖慢了你？” |
| “你会推荐我们吗？” | “你最近一次把它展示给了谁，你是怎么说的？” |
另一个几乎在任何地方都管用的问题：“当这个功能对你不管用时，你会改用什么？“它会让真正的竞争对手浮出水面，而那往往是一张电子表格。
最糟糕的征集反馈方式有哪些？
最糟糕的问法，是宽泛的、过早的、冗长的或者带有引导的。它们有一个共同的问题：对方要回答，就得先替你做完你本该做的思考。
- **“请填写我们的 20 道题调查问卷。“**能填完的人，是空闲时间最多或者意见最强烈的人。
- **登录后第一个页面上的弹窗。**用户是来做事的，而你挡住了他。关掉它是唯一合理的回答。
- **“我们很期待你的反馈！“却没有任何问题。**这是在要求用户自己去发明话题。
- **带引导的问题：“你有多喜欢新的仪表盘？“**你得到的是附和，什么也学不到。
- **只有评分，没有追问。**10 分里的 6 分只能告诉你情绪，不能告诉你该改什么。
- **问完之后就没了下文。**这会让你失去下一轮，下面会讲到。
关于产品的客户反馈叫什么？
关于产品的反馈通常称为产品反馈，可以分成两类。缺陷报告说的是某个东西没有按预期工作。功能请求说的是缺少了某个东西。这个区分决定了谁先来看它，而功能请求还是缺陷划清了这条界线。第三类是赞扬，值得保存下来，并在征得许可后引用。
一个把”缺陷”和”功能请求”作为第一个选项的反馈表单，已经替你完成了这第一次分类。
拿到答案之后怎么办？
把每一条答案放到团队本来就在工作的地方，并保留对方的原话。一行引用的原文，胜过你对它的概括。按类型和大致的紧急程度打上标签，合并重复项，然后做出决定：构建、搁置，还是拒绝。
拒绝同样算一种回答。“我们不会构建这个，原因如下”，能结束对方的等待，而拒绝功能请求里有相应的措辞。至于背后的管道，功能请求追踪介绍了如何把来自五个渠道的请求汇入同一份清单。如果你以书面形式接收请求，功能请求模板能让它们保持可比较。
Changeloop 的小组件会把每次提交作为一个 GitHub issue 归档，所以反馈会落在将要修复它的代码旁边。无论使用哪种工具，规则都是一样的：一份清单，一个负责人，没有任何一条答案被遗落在某个人的收件箱里。
为什么要告诉大家发布了什么？
它让对方看到，回答是值得花时间的。一个告诉过你某件事、后来听到”这个已经发布了，谢谢你”的用户，就有理由再次回答。一个什么也没有听到的用户，会断定这个框从来没人读。
所以征集的最后一步是回复。当每位提出请求的人所要的东西上线时，用他们自己的话、在他们使用过的渠道上告诉他们。闭合客户反馈循环介绍了这套机制：已发布的体验日志条目是触发消息的条件，所以请求者只有在变更真正上线之后才会被告知。在 Changeloop 中，如果小组件里的反馈变成了一个 GitHub issue，而合并的 pull request 又关闭了它，那么批准条目就会在那个 issue 上发出一条”Shipped”评论，并在小组件中向提交者展示这条条目；手动创建的 issue，以及 GitLab 或 Bitbucket 仓库，不会收到评论。我们的文档列出了小组件和信息流的设置。
回复可以很简短：“你在三月提过 CSV 导入。今天上线了，用法如下。“它也给了你最好的下一个问题：它是否覆盖了他们需要的情况。
一个起步方案
从顶部的表格里挑一个时刻，选用户最常成功或者最常放弃的那一个。为它写一个问题，放在一个渠道里，在加入第二个提示之前，先把两周内的每一条回答都读一遍。对每个给了你具体内容的人，都要回复。
FAQ
应该多久向客户征集一次反馈? 把询问和事件绑定，而不是和日历绑定。一个用户每周最多看到一次提示，而且刚回答完一次之后不要立刻再问。收到反馈之后的下一条消息，应该是关于它的后续处理的回复。
怎样征集反馈才不会惹恼用户? 在任务完成后问，绝不在任务进行中问，只问一个问题，并且让它很容易被关闭。用户关闭之后，要尊重这个选择，几周内不要再问。
应该为反馈提供奖励吗? 通常不需要。一个具体的问题加上看得见的回复，比一张礼品卡更有分量，而且奖励会吸引冲着奖品来的人。把奖励留给访谈，因为那时你要的是对方 20 分钟的时间。
如果没有人回答怎么办? 把问题收窄，并且挪到离那个时刻更近的地方，比如只针对一个界面，在它刚被使用之后立刻问。如果依然没有动静，就直接给少数几位用户发邮件，并用这些对话来写出更好的提示。
本文的技术内容未经独立审核。如有错误，请告诉我们，我们会更正。