百木园
产品经理在日常工作中经常会遇到被用户问题打扰的情况，解答用户疑问作为日常工作项之一常常让产品经理很头疼，用户提问时间不固定，有的时候很简单的问题会打断别的工作事项进度，但是用户疑问有时候响应不及时又可能造成更大损失。所以处理用户问题的方法和节奏就成了产品经理的必修课，用户问题处理好了诸事顺遂，处理不好麻烦一堆。今天我们就来聊聊处理用户问题的一些关键事项。
一、设置用户提问渠道
首先应该明确，处理用户问题是产品经理在产品运营部分需要承担的相关责任，而产品运营不应当是产品经理核心工作，所以日常工作主线中是不应该出现处理问题这种事情的，应该把解答用户提问设定为一个被动事项。
正常情况下，产品运营是有专门的运营人员去做的，一般情况的处理和承接都应该有产品运营人员去做，只有在产品运营也解决不了的时候才会反馈到产品经理这里。但是也有很多公司是没有设置产品运营岗位的，产品经理本身就是唯一的产品运营人员，公司考虑产品使用人数，使用频次，投入产出比等因素，这种做法本身也是可以理解的，但是产品经理自身不能任由自己的时间大量消耗在这个地方。
所以就应当为用户设置好一系列解决问题的合理路径：
1. 帮助入口
在产品页面中应当能找到使用说明之类的基本介绍内容入口，要能支撑用户自己按图索骥解决自己遇到的问题。
2. 创建用户群
在产品帮助页留下群号或者群二维码，在群里公告或置顶处放置产品使用说明和常见问题说明，并告诉用户如果看说明后问题依然无法解决再联系产品经理，在群内把相关产品经理设为管理员方便用户找到。
3. 用户留言
明确告知用户先通过办公沟通软件留言，产品经理会在某个时间集中统一处理留言，这样产品经理的其他工作事项也不会被打断。
4. 急事电联
考虑到用户可能会有十分紧急的事项，还可以在办公沟通软件上设置一条自动回复，告诉用户如果事项紧急可以打电话联系。
有了这样一套完整的用户问题解决路径，至少可以给到用户一个自行解决问题的方式，不至于遇到问题就束手无策，同时也避免了绝大多数不重要不紧急的问题突然打断产品经理手头的工作，影响工作进程。
二、撰写产品帮助文档
前面提到，用户在遇到问题的第一时间应该先通过自己查找资料的方式解决，这对用户和产品经理来说都是最节省时间的方法，这就要求产品经理要提前准备好相关资料以供用户查看。
1. 产品手册
产品手册是产品经理对外提供的最全面的产品解释说明内容，应当涵盖产品整体框架介绍，产品功能阐释说明，产品中涉及的名词解释等等，要尽可能具体地把产品介绍清楚。
2. 操作手册
区别于产品手册的全面性和系统性，操作手册更多地是从用户使用角度出发来写的一份指导性文档，是针对用户想要做的事情，给出的具体操作步骤。操作手册应当能够覆盖到用户日常在产品中要处理的各种事项，在用户看来这应当是一份清晰的指引说明，而不是像产品手册那样是详细的介绍说明。
3. 常见问题答疑手册
有些时候产品本身是没有问题的，但是因为大家认知不同，或者操作习惯不同，对一些名词的理解不一致会导致用户在有指引的情况下还是无法正常操作。产品经理应当总结类似的问题做进一步的解释说明，帮助用户处理一些非产品问题导致的使用障碍。
4. 使用延伸手册
产品中的很多功能是有隐藏属性的，就是它表面可能是用来解决A问题的，但其实通过变通或者跟其他功能组合的形式也可以用来解决B问题，这种情况一般用户是很难发现的，也需要产品经理单独说明。产品使用延伸可以邀请产品运营和产品用户来一起创作，一份好的延伸手册可以让产品覆盖到更多的使用场景，扩宽产品的市场。
产品帮助文档像是产品经理与用户沟通的触手，可以让用户更好地了解产品，更好地使用产品，所以产品经理一定要重视产品文档的设置，这个工作可以帮助产品经理在后期节省很多跟用户重复沟通的时间成本。
三、创建用户问题清单
即便前面准备了充分的帮助文档，也还是会有很多问题会流转到产品经理手上，这是很正常的现象，处理用户问题本来也是产品经理工作的一部分，我们前面准备那么多帮助文档，也不是为了阻断用户提问，而是希望用户能在不需要沟通协助的情况下就自己解决掉问题，解不掉那肯定还是要找产品经理解决的。面对众多的问题产品经理也应该创建一张用来跟踪用户问题的表格。
创建用户问题跟踪表的好处有很多，一方面可以根据表头内容提示更全面地了解问题的相关信息。另一方面对于现场未解决的问题也方便做进一步跟踪，此外还可以定期回顾根据表格内容持续改进产品。下面我们来结合用户问题跟踪表具体字段来分享一下它的具体用法。
1. 创建时间
记录首次发现问题的时间，方便后期结合时间确定解决问题的紧急程度。
2. 提问人
记录问题是谁提出的，方便后期需要了解更多细节时找到具体的人员，或者问题解决后能够及时通知到用户。
3. 归属系统
一般一个产品经理不会只负责一个产品，而且这种问题跟踪表很可能还是部门共用的，所以记录系统就很有必要了。
4. 操作环境
是测试环境还是正式的线上环境，根据本公司产品部署的环境做具体的设置。
5. 浏览器
用户用什么浏览器使用系统时出现的问题，记录时需要详细到版本，方便开发排查问题时及时排除掉相关因素影响。同时复现问题时也可能会用到这个信息。
6. 问题概述
一句话简短描述问题的主要内容，方便后期翻阅时可以快速定位到具体问题。
7. 问题详情
补充问题的更多细节内容，记录问题发生的具体情景，方便后续复现问题或解决问题时参考。
8. 问题归类
可以预先为常见问题设定几种类型，比如操作问题、性能问题、功能问题、界面问题、产品BUG等，后期可以根据问题类型做不同处理。
9. 记录人
一般就是产品经理自己，如果是团队共用一张表的话，可以用来定位是谁对接到这个问题的。
10. 解决人
谁对解决这个问题负责，一般也是产品经理自己，但也有时候需要开发同事介入，记录解决人可以方便跟踪后续解决进度。
11. 问题原因
由解决人定位出问题产生原因，可以方便排查类似原因有没有可能导致更多问题，也可以结合原因划分问题归类。
12. 解决方案
说明问题最终怎么解决的，方便后期遇到类似问题时参考，也可以根据解决方案确定进一步推进策略。
13. 解决进度
可以直接提供三个选项，已解决、处理中、待分配，后期可根据解决进度确定是否继续跟踪。
14. 用户验收
问题解决后需要联系用户验收解决结果，看用户是否对解决结果满意。根据验收反馈及时调整，直到用户满意。
此外还可以结合公司实际情况以及产品实际情况设定诸如紧急程度、是否必现、影响范围、用户ID、处理排期、完成时间等等，只要你认为这个在问题的处理过程中或者事后跟踪过程中是需要用到的，那就都可以考虑放到你的跟踪表中。
一份好的用户问题跟踪表是可以直接跟用户需求统计表完成对接的，有些用户的问题属于产品功能属性的问题，那就可以直接从问题池升级到需求池。还有些问题可能是用户不会操作导致的，那就可以排查一下帮助文档中这个部分是不是有缺失，并将内容补充到对应的地方。
从问题跟踪表的字段设置也可以看出，我们遵循的原则就是问题从用户那里来，最后一定要再回到用户那里去，最终形成一个解决问题的闭环，只有用户说这个问题解决了那才算是真正解决了，产品工作最忌讳的就是自嗨，一定要听用户的声音，了解用户的真实反馈。而解决用户问题就是一个很好地听用户声音的机会，各位产品经理一定要用好这个机会。
四、梳理问题跟踪流程
作为一个常规事项，而且又是具有突发性质的事项，如果没有成体系的应对策略的话，往往会造成处理问题时考虑不到位留下隐患，或者问题解决不彻底造成用户持续反馈消耗更多时间，又或者因为没有清晰的流程在处理问题时手忙脚乱也会浪费很多时间。所以我们就在今天的最后一个部分来分享一下，如果最后问题还是给到产品经理这边的话，我们应该如何正确地应对和处理，该有哪些比较规范的处理流程。
1. 确认场景
跟用户确认问题发生的具体场景，包括所属环境、发生问题的系统、操作账号、在进行的操作、涉及的任务或表、报错提示以及所产生的影响等。场景越具体越有利于后续问题复现及定位解决。
2. 复现问题
根据用户提供的问题发生场景尝试在本地复现，以此来确认是系统中的共性问题还是用户那边的偶发性问题。如果产品经理自己无法完成复现，可以邀请测试人员来共同完成，有时候测试人员对一些特殊场景的把控会比产品经理更细致一些。
3. 排除操作原因
在了解问题发生场景和复现问题的过程中，首先要确认问题是不是由于用户错误操作导致。如果是操作错误就进一步看这个操作我们是否有在前面的帮助文档中写到相关的内容，写了就让用户再去看，没写就要把相关内容补充到文档中。如果不是操作错误就再往下排查其他问题。
4. 问题建档
将问题的相关信息维护到用户问题跟踪清单中，并在后续跟踪中逐步完善跟踪表中的相关内容，也可以根据用户问题跟踪表中的相关字段来梳理待办事项。
5. 排除功能性问题
排除用户操作错误导致的问题后，产品经理首先应该排查一下问题是不是由于产品本身的功能缺失或者功能设置不合理等原因导致的，如果是功能性问题，可以进一步判断是否有必要新增或调整功能，并将相关结论和计划告知用户。
6. 找前端定位
产品排除用户操作问题和功能性问题后还没能解决的话，就要找前端看一下是不是前端页面的问题导致的，前端问题排查起来相对比较简单，解决也会相对更快一些，所以技术排查的时候往往会先从前端开始排查。
7. 找后端定位
前端排查完以后还没解决就得找后端来看了，根据问题发生时的具体场景，或者问题发生时的日志记录等来确定问题发生的具体原因。如果是不需要发布就能解决的问题就直接解掉，如果会涉及到发布才可以解决的就走Bug修复流程。
8. 找测试提交Bug单
确认需要走Bug流程以后找测试人员提交Bug单，后续的发布流程中会关联到。
9. 排查相关影响
开发明确问题原因后，产品需要进一步排查这个原因是不是还会导致其他相关问题出现，以及有没有类似问题存在的隐患，如果有的话也要一并解决掉。
10. 明确解决方案
经过各方排查以后，根据大家的反馈确定相关的问题的明确解决方案，并请前后端开发及上下游等各相关方评估方案可行性及合理性，排除可能造成的其他影响。
11. 做好变更文档
方案评审通过后将涉及到产品调整的内容维护到产品功能需求文档中，确保需求文档与线上产品保持一致，方便后期查看。
12. 修改上线
Bug修复后要按照正常的流程安排测试，测试确认无误后发布上线，上线成功产品经理需要在线上版本进行验收，确保问题已经解决。
13. 同步用户
问题解决后，将问题解决结果同步给提出问题的用户，邀请用户重新试用相关功能，来确认相关问题是否已经得到解决。
14. 接收反馈
主动找用户获取试用反馈，反馈已解决，整个问题处理流程结束。反馈还有问题再进入问题处理流程进一步跟踪处理。
上面这个流程不同的产品或者不同的团队，可以根据自己的产品特性和团队习惯做相应的调整，把问题解决，得到用户认可这个最核心的事情解决就可以。
五、总结
最后来回顾一下，用户问题的解决应该是在用户发现问题之前就开始准备的，所以我们最开始要给用户设置合理的自己解决问题的路径；而用户自己解决问题的时候又必然要用到一系列产品帮助文档，产品经理要提前准备；问题最终还是回到产品手上，产品要有对问题整体把控和跟踪，所以就需要用到用户问题清单；具体的问题解决过程又需要有一个相对标准的流程去指导问题的解决，可以帮助产品经理有一个清晰的解决问题思路。
只要按照这一整套逻辑去处理用户问题，基本可以覆盖80%以上的场景，希望能够对大家的工作有所帮助，大家如果还有其他需要补充或者辩证的点，也可以一起探讨。
给作者点赞，鼓励TA抓紧创作！
来源：http://www.woshipm.com/user-research/5367999.html
本站部分图文来源于网络，如有侵权请联系删除。