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

2. 针对BUG问题在我们脑海中BUG都是相对比较紧急，因为严重影响用户进程，在BUG面前从产品、运营、技术都是不希望出现，而一旦出现后，就需要处理，而且还需要看处理的效率，但是有些问题可能会进入排期处理，还是那句话，开发资源永远是有限的。
在收集问题环节，就针对如何提高BUG的处理效率，做些简单的梳理。
首先需要学会定位问题，问题来了，有可能不是问题，或者问题能直接处理，无需提交到研发，这样一个来回耽误了的研发时间，还增加了解决问题的时间成本，收集问题的人其实会变成两边得罪人。
定位问题的方式视用户情况、产品不同，定位的方式会有些差异，但是会有些基本相同的东西，需要用户提供证据（包括视频、或者截图），像在微信小程序里面，相同的产品太多了，有的时候用户拿了一个别人家的产品来找你反馈，如果和用户互动了半天，还未看到问题的证据，那证明收集问题的人自身有问题了。
从证据——操作步骤——使用环境——设备/版本（大致一个流程，但是不一定这么走的）
对产品业务比较熟悉时，一般有些简单问题，在证据环节就能马上产出对应的解决方案，而再难一点的问题，就需要用户提供相关操作步骤，从而更好的处理问题。
定位问题，还有一点，就是需要判断“问题的影响程度”，在这里也可以用四象限法则进行梳理，在这个前提我们需要界定“是否为核心流程、还是分支流程”，核心流程就不需要分析，直接定位清楚问题直接处理。
在面向用户提价的BUG必须要自己走一遍流程，需要确认为是否必现，还是个别用户会出现，个别用户会出现，有可能是机型兼容问题、就需要进一步找到对应机型来操作一遍，如果未复现，就有可能是环境或者其它原因，这类型就会变成偶现BUG类型。
3. 针对需求类型需求相信是产品经理比较喜欢的，一个产品的功能，源自于用户的需求，不是源自于功能本身，这个时候如果用户在使用你的产品发现原有功能未能满足自己想达到的目的时，就有可能找客服倾诉反馈。
但不是所有的功能诉求，都是能被满足的，原因是“开发资源永远是稀缺的”，调用资源时，需要考虑付出的成本，是否低于收益，如果是，则是可以考虑，当远不止这些，还得考收益大成本的指数是多少，当然越高越好。
需求分类是可以用到四象限法则，市场空间，可以定位给我们能带来多少效益，也可以理解为这个功能针对哪类人群推出，预计会有多少人使用。

文章插图
在问题收集时，特别考验收集人员的沟通技巧，因为你需要挖掘用户背后的核心诉求、包括用户为什么要这个功能、在什么场景下使用、想达到什么目的？是否有替代方案等等，相当于一次用户访谈调研了。
二、提交问题问题的提交设计到内部协作，对接的是技术，想要问题得到快速处理，就需要让技术放下手中其它重要的事情，来处理你认为的这件重要的事情，也就是技术心中的取舍。
前面在收集问题如果做好的话，如果进入到提交问题，基本已经为处理问题的效率解决了一般以上的问题了。
解决问题的效率，是否把用户反馈过来的问题丢到群内就可以了，这样肯定是不行的，除非那种整体崩盘、大面积影响的，直接在群内艾特相关负责人来紧急处理，这类的问题比如：“服务器异常、某个主流程功能无法打开等等” 。
提交问题必须有标准规范流程，因为标准所以才会高效，从用户反馈——收集人员收集——技术，已经被过滤了，如果没有标准，处理问题起来，技术就会增加理解成本，从而导致处理问题的效率变得低效。