用户反馈的问题如何高效处理好？

小脑壳大思想 2023-07-28 00:48:19

著名的产品人俞军在自己的《俞军产品方法论》一书中提到“产品即媒介，公司只是通过产品这个媒介向用户传递可交易的价值”，所以当一个需求产生之后，实际是向用户获取交易价值，用户在愿意交易的情况下，对于这个收益是超出自己所付出的成本，这里的成本包括“直接的金钱、还有间接的时间等等”，用户才会愿意交易。

那这里谈到的用户反馈问题，其实从某种角度来说，用户已经使用过你的产品，且用户觉得自己付出了一定的交易成本，但是却得不到满足，并且在找平台反馈时（反馈的成本要小于自己的收益，或者预期收益较大时才会坚持找到你反馈）已经有心里预期。

反馈问题的渠道有很多种，有些平台特别重视用户反馈的问题，专门设立了“客服回访小组”，通过人工沟通，处理用户的问题，最常见的就是在产品上有一个客服反馈入口，有的时候用户处于的使用场景不同，找到的反馈渠道也不同，有些可能就是评论、或者公众号留言、或者添加客服微信等等。

那最终要如何处理好用户反馈的问题，以及用户反馈的问题如何高效处理和安抚用户的情绪以及结果反馈，对用户都特别的重要，这里反馈问题的用户以B端为例，产品形态面向用户属于免费模式。

对反馈流程进行梳理，大概分为四部：

收集问题
提交问题
跟进问题
反馈结果

一、收集问题

1. 不做问题纯收集者

面向B端的问题，其实比较致命的，因为影响一个B端，背后其实影响着未知的C端体验，尤其是2B又2C的平台，所以响应速度尤其重要。

所以我们看到很多B端类型产品，在用户使用中特别显眼的位置，放入客服入口，为的就是为了快速响应用户反馈的问题，因为没有百分百的顺利。

用户反馈的问题种类繁多，分为大的三类：

体验类
BUG类
需求类

体验类，无非就是对产品使用理解成本高，或者觉得使用时特别不顺，没有达到自己的预期等等，这些都是为体验类问题

针对体验类问题，并不能一下子就能处理好，而是需要接受人员学会判断，同时记录好相关数据。例如：影响不严重，反馈数据不多，可能就需要另行判断，如果影响不严重，但是反馈数据多，这个时候就需要严谨对待，可以用一个四象限法则来进行梳理。

对于体验问题的严重，做一句解释，比如：产出这个功能，是用户进入产品必使用的，就是属于严重的，如果反馈数量超过几个，就可以进入紧急处理了。

另外对于用户的反馈很多时候，都是主观臆断，因此需要界定标准，但是标准不会是死的，需要灵活制定或者定期调整，而出发的目的是为了给用户提供更好的产品体验，但是开发资源永远都是稀缺的，所以要在稀缺资源中，解决效益高的问题，才能为项目创造更好的收益。

体验问题是一个长期活，当然针对体验问题，我们也可以主动出击，通过用户访谈的方式，来调研产品的某个功能、某个板块对用户的体验是怎样，有什么问题、包括用户在什么场景下使用这块产品、为什么会使用、使用的目的、以及对这个功能的期望等等，这里会涉及一套完整的调研流程和方法，期待下次深入分享调研。

从调研角度分享一句，一款功能上线后数据好不好，生产出来这个功能的产品经理都需要对此负责，用户访谈其实是提升数据、获取功能对用户的体验的一个很好方式。

2. 针对BUG问题

在我们脑海中BUG都是相对比较紧急，因为严重影响用户进程，在BUG面前从产品、运营、技术都是不希望出现，而一旦出现后，就需要处理，而且还需要看处理的效率，但是有些问题可能会进入排期处理，还是那句话，开发资源永远是有限的。

在收集问题环节，就针对如何提高BUG的处理效率，做些简单的梳理。

首先需要学会定位问题，问题来了，有可能不是问题，或者问题能直接处理，无需提交到研发，这样一个来回耽误了的研发时间，还增加了解决问题的时间成本，收集问题的人其实会变成两边得罪人。

定位问题的方式视用户情况、产品不同，定位的方式会有些差异，但是会有些基本相同的东西，需要用户提供证据（包括视频、或者截图），像在微信小程序里面，相同的产品太多了，有的时候用户拿了一个别人家的产品来找你反馈，如果和用户互动了半天，还未看到问题的证据，那证明收集问题的人自身有问题了。

从证据——操作步骤——使用环境——设备/版本（大致一个流程，但是不一定这么走的）

对产品业务比较熟悉时，一般有些简单问题，在证据环节就能马上产出对应的解决方案，而再难一点的问题，就需要用户提供相关操作步骤，从而更好的处理问题。

定位问题，还有一点，就是需要判断“问题的影响程度”，在这里也可以用四象限法则进行梳理，在这个前提我们需要界定“是否为核心流程、还是分支流程”，核心流程就不需要分析，直接定位清楚问题直接处理。

在面向用户提价的BUG必须要自己走一遍流程，需要确认为是否必现，还是个别用户会出现，个别用户会出现，有可能是机型兼容问题、就需要进一步找到对应机型来操作一遍，如果未复现，就有可能是环境或者其它原因，这类型就会变成偶现BUG类型。

3. 针对需求类型

需求相信是产品经理比较喜欢的，一个产品的功能，源自于用户的需求，不是源自于功能本身，这个时候如果用户在使用你的产品发现原有功能未能满足自己想达到的目的时，就有可能找客服倾诉反馈。

但不是所有的功能诉求，都是能被满足的，原因是“开发资源永远是稀缺的”，调用资源时，需要考虑付出的成本，是否低于收益，如果是，则是可以考虑，当远不止这些，还得考收益大成本的指数是多少，当然越高越好。

需求分类是可以用到四象限法则，市场空间，可以定位给我们能带来多少效益，也可以理解为这个功能针对哪类人群推出，预计会有多少人使用。

在问题收集时，特别考验收集人员的沟通技巧，因为你需要挖掘用户背后的核心诉求、包括用户为什么要这个功能、在什么场景下使用、想达到什么目的？是否有替代方案等等，相当于一次用户访谈调研了。

二、提交问题

问题的提交设计到内部协作，对接的是技术，想要问题得到快速处理，就需要让技术放下手中其它重要的事情，来处理你认为的这件重要的事情，也就是技术心中的取舍。

前面在收集问题如果做好的话，如果进入到提交问题，基本已经为处理问题的效率解决了一般以上的问题了。

解决问题的效率，是否把用户反馈过来的问题丢到群内就可以了，这样肯定是不行的，除非那种整体崩盘、大面积影响的，直接在群内艾特相关负责人来紧急处理，这类的问题比如：“服务器异常、某个主流程功能无法打开等等”。

提交问题必须有标准规范流程，因为标准所以才会高效，从用户反馈——收集人员收集——技术，已经被过滤了，如果没有标准，处理问题起来，技术就会增加理解成本，从而导致处理问题的效率变得低效。

举些简单例子：操作步骤、用户机型/版本、是否必现、影响程度、包括用户设置好的信息（如用户发布的文章无法打开，就需要文章链接）用户的ID（内部）。包括在哪里反馈问题都有规定，不能随便在群内丢个问题，这样信息可能会被聊天记录覆盖，而是需要有专门的协作文档。当信息特别齐全的时候，有专门的协作文档，协作效率自然会变得高效。

三、跟进问题

认为跟进问题，也是需要有协作规范的，毕竟每个人都有忙不完的事情，既然是线上协作，那提交问题的人在哪里进行反馈，处理问题的人反馈的结果自然也要在反馈处进行回复。

当提交问题的人，提交上去后，最想知道的就是，问题什么时候能解决好，因为用户会追着问你处理进度，会拷问你什么时候给我处理好，面对用户的压力，另外一边又面对技术工作繁忙的压力，除了规范的协作之外，还需要当面沟通，避免忘记。

另外个人认为，除了跟进问题的处理进度，以及处理好后的反馈，还需要知道问题导致的原因，毕竟每一次导致的原因，是收集问题最好学习的时候。

这个时候就需要内部制定标准规范，所有的问题，都需要技术对问题的造成原因进行描述，以及处理好了进行描述，甚至还可以说处理的方法，以及处理好后对未来是否有隐患，都是需要写清楚，这样问题跟进起来，特别明了，也能追责，当再次遇到问题时，也能快速处理。

四、反馈结果

反馈问题，一般都是实时的，因为收集问题的人，有可能是微信沟通中，还有的时候用户会时不时的问你进度，这都需要处理好。

在反馈过程中，有些用户会有情绪，这个时候还要考验收集问题人的安抚能力，需要站在用户角度来安抚，而且还不能把话说死。

有些收集到问题的人，因为一直催一直闹，这个时候当问到技术xx时间处理好后，收集问题的人会立马反馈给到用户，来安抚用户，但是往往有的时候技术任务特别繁忙的时候，会让问题处理的时间延后，这样就会在用户面前失信，从而更加激起用户心中的不满。

反馈结果还有需要特别注意，就是谁反馈的什么问题，处理好后需要向这个人反馈处理结果，这个情况是有的时候接待聊天的人数较多，同时反馈问题的人也多时，要么造成反馈结果不及时或者漏掉，当用户主动再来找你时，已经加重用户内心不满的情绪，认为问题收集者需要有针对自己的专门记录文档，以便问题从处理到跟进到反馈，能有比较清晰的处理进度流程，这样尽力保证处理起来特别顺。