第151期 | 如何回应用户的“吐槽”？
郭蕾
讲述：郭蕾大小：8.52M时长：09:18
你好，我是极客时间的总编辑郭蕾，这是我代班的第四周。之前我和你分享了极客时间团队的内容故障处理方法，这里面核心点是根据影响范围对故障做分类，不同的故障等级又有不同的处理流程。这样流程有了，体系有了，出故障的时候，团队都不用碰眼神，就能快速解决问题、复盘问题。
但很多时候，我们更难的地方都是那个模糊的地带。比如，之前就有个用户吐槽我们的某个专栏，他说，“这个专栏真差，极客时间现在越来越飘了”。
说到这里，先插个题外话，我其实特别害怕用户吐槽我们说，“极客时间内容越来越水了”。这种描述趋势的吐槽能让人做噩梦。为什么呢？你可以想下这个逻辑，我们极客时间刚发布的时候，很多用户吐槽我们的 App 体验不好，说我们有很多 Bug，但是两年过去了，回过来再看，这种吐槽或者反馈是越来越少。因为我们每发布一个 App 版本，每解决一个 Bug，那都是代码实打实的写进去了，它解决了就是解决了，代码就固化到那里了。这是物理层面的叠加。
但是，内容不是这样，我们从一开始到现在，做了两年时间，我们沉淀下来什么了？我们沉淀下来了很多经验，很多方法论，这些东西的载体是什么呢？是人、文档、文化、培训。它并不是物理的叠加。
所以，到底极客时间的内容能不能越来越好，这就特别考验我们的内容生产能力。这也是我今年最最最重要的工作。
再回来接着说吐槽的事情。说实话，做极客时间内容的这几年时间里，我就收到过很多的吐槽，那怎么回应吐槽呢？下面是我曾经的一些回应写照：
“大部分用户都觉得很好，就一个用户吐槽。没必要理会，不要让他扰乱了我的工作主线。”
“哎呀，不好，有用户吐槽，这内容质量有问题。”
“我做得很好，昨天晚上还加班呢，委屈啊我，这人太挑剔了。”
你可以先停下来想一想，如果你是我，你会怎么应对呢？再或者，作为一名用户，你希望我怎么做呢？
先定个基调，我觉得一个内容工作者在做内容的时候，保持“悲观”没什么错，特别是我们现在已经经营了这么久的内容产品，在正式交付之前还是得多想多提几个问题，比如这里如果有用户觉得太基础怎么办，这种学习方式是不是用户不会接受，用户是不是会觉得这部分内容没必要学……
当然，也不是说你只要悲观就可以了，悲观地、谨慎地提出来这些问题之后，我们就需要想对应的解决办法。比如我们担心高阶用户进来会吐槽， 那我们就可以在简介里、开篇词里写清楚。我们担心这块知识点密度不够，那就可以把它当成预习放出来……反正用我党的一句话总结就是“把问题消灭在萌芽状态”。
基于这样的基调，我再详细说下我们现在处理内容类用户吐槽问题的策略。
1. 心态开放
现在，看到有用户吐槽我们的内容问题，我和我的团队都会第一时间处理，或是和用户直接沟通，或是花时间判断问题。这事情看起来很费力气，但我为什么要做？两点考虑，第一，让吐槽的那个用户知道我们在乎他的反馈，同时，如果真没问题，我们也有机会向他解释，但不管怎么样，这都是一次很好的构建信任的机会。第二，倾听用户的反馈，从里面找到一些问题点，要知道，这个问题点可能也是共性的问题，不管怎么样，我们收集到了更多更全面的信息。
这里为什么我要强调心态开放呢？因为人总是有 EGO 的，如果听取反馈的时候不能心态开放，那效果肯定会大打折扣。
2. 逻辑闭环
收集完信息，紧接着就要开始处理吐槽了。如果用户反馈的那个信息纯属吐槽，没有增量，也不具体，那可以选择性忽略。但更多的时候，用户都会反馈出来具体的点，比如说你这个地方没有具体的方案，你这部分内容和我的预期不一样，怎么没有某个系统实现方面的原理介绍，你这个课程的 Demo 不适合初学者，这都是很具体的。
具体的问题就要具体分析了，但这里我用了一个词叫逻辑闭环，也就是说我们起码得过了自己逻辑这一关。为什么呢？因为用户反馈的问题可能是真问题，也可能是假问题。我们不能不重视用户的吐槽，但也不能被用户牵着鼻子走，要不然就真没有主线了，就像“父子骑驴”的故事一样。
3. 小题大做
分析完问题之后，有的小问题我们还是比较难界定，这时候我一贯的做法是把它当成警醒就好了。而有的吐槽暴露出来的问题，它真的是一个大问题，这个时候，就要把这事升级为故障了。
8 月的时候我们收到过一个用户的投诉 / 吐槽，用户说我们某个视频课程最后的实际篇幅和一开始写的不一样。如果只是解决这个问题，那方法也很简单。就两步，第一，和用户道歉，回复用户为什么少了 4 节。第二，告诉用户接下来我们的解决方案。
但我们肯定不会这么解决，我们要小题大做。所以，很快内部组织了一次复盘。复盘的时候，我们其实发现了整体视频课程在生产流程上的一个大问题，也让我们更关注视频课程的出厂流程。
你看，这就是通过小问题暴露出来的大问题，我的主要精力就是得解决这些大问题了。因为从大的层面来说，那些小问题肯定要解决，也好解决，但是系统层面的问题如果不解决，后面肯定会再出现类似的问题。
关于如何回应用户吐槽的方法到这里也就阐述完了，我总结下。主要有几点，首先，大的层面，做内容我们多一些悲观心态也不是坏事，提前把一些不好的问题考虑到，防患于未然。其次，接收吐槽时，我们要保持开放的心态，收集更多的问题信息，通过交互给用户信任感。第三，如果用户吐槽的问题不具体，那就忽略。如果问题具体，那分析问题的时候一定要注意让逻辑闭环。如果分析之后确实还是无法界定问题，那就把它当做用户给我们的一次警醒，为未来交付好的内容蓄能。第四，如果吐槽升级为了故障，那处理完故障一定要小题大做，从系统层面复盘故障，并把复盘的结果回溯到内容生产体系中。
不知道看完今天的内容你有何感想，你是不是也收到过别人的吐槽呢？你是怎么回应的呢？你可以在评论区给我留言，我们一起交流。
卖桃者说，明天见。
（编辑：夏天）
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《卖桃者说》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(5)
- 最新
- 精选
熊斌换位思考了一下，假如一个用户很情绪化地说：“你们的产品真烂！ ”。那我先会想想他在说什么？最好的办法就是和他进行沟通，进行询问。 其实，他说内容不好、说产品烂时，生产者接收到的是一个立场，你认为对方不喜欢这个产品，质疑这个产品。但你应该挖掘的，是对方的真实需要。 这时候有很多问题可以问。比如说，你可以询问用户，您是在使用产品哪个功能的时候，遇到困难了吗？能不能跟我们说说，发生了什么？ 在任何沟通里，不要揣测、不要忽略、要保持好奇，了解对方立场背后真实的需求到底是什么。编辑回复: 优秀，这个总结棒
2
业哥最近准备开技术博客，写点东西，想问个问题，就是写文章的时候，每个段落的头两个字不是应该往后移动空出来的吗？极刻时间还有网上的很多博客文章都是不空出来，而且每个段落之间都会空一行，这样的风格是现在默认的风格吗？编辑回复: 现在很多书也都已经不空了，你上网搜下历史背景吧。现在段落之间你加个空行我感觉会更有美感，而不是缩进。
1
Jerryz郭老师文中主要还是侧重内容层面的反馈，部落里面还有不少功能性或者改善型的反馈。我的理解，用户吐槽或者反馈都是用户想更多的参与到产品中，是改进产品的正循环。关于反馈的具体性，也可以提供一些模版之类的，让用户的反馈可以更结构化，也便于处理。1
捷后愚生小题大作，有时候也是正确的做法，发现问题是发现提升与进步的机会
小斧1. 心态开放 2. 逻辑闭环 3. 小题大做 大的层面，做内容我们多一些悲观心态也不是坏事，提前把一些不好的问题考虑到，防患于未然。 接收吐槽时，我们要保持开放的心态，收集更多的问题信息，通过交互给用户信任感。 如果用户吐槽的问题不具体，那就忽略。如果问题具体，那分析问题的时候一定要注意让逻辑闭环。如果分析之后确实还是无法界定问题，那就把它当做用户给我们的一次警醒，为未来交付好的内容蓄能。 如果吐槽升级为了故障，那处理完故障一定要小题大做，从系统层面复盘故障，并把复盘的结果回溯到内容生产体系中。
收起评论