互联网公司问题上报流程

　　作为一个合格的产品运营，从发现问题—上报问题—解决问题—问题闭环每一环都是必不可缺的一环。其中发现问题是最关键的，如果连问题都不能发现，那么就没有上报解决闭环的环节了，今天就来讲讲问题的上报流程。

　　一些互联网公司都会有自己的重点问题上报流程和上报标准，会根据问题反馈数量和问题原因纬度来判断问题的等级，从而进行汇报。不同问题的等级汇报的层面也是不一样的，例如达到重点问题标准，需要上报到公司层面的领导知晓，一般问题同步至业务线领导，零星问题同步给单独的负责人即可，有了这样的标准，才可以降低风险问题的出现，更好的进行项目的管理以及长久的发展更有效推动用户反馈问题的解决，检验产品功能的实现程度，提升产品的质量、体验及用户满意度。

　　1、发现问题 发现问题是前提，那么如何发现问题呢？这需要你对业务足够的熟悉，对于简单的问题可以通过用户的反馈直观的看出来，对于隐藏的问题通过经验判断可能是什么原因导致，会不会出现关联的问题，这需要一个运营长时间积累才能拥有的能力。当我们从一个渠道发现问题时，先收集一下其他渠道是否出现该累问题的反馈，我们一般都是通过后台反馈入口、QQ、微信、论坛等各个渠道来监控问题，统计问题数量，整理问题现象，以及问题时间点以最快的速度同步至相关的技术负责人，由技术人员去进行复现和分析原因，进行解决。通过用户问题反馈的表象，总结出问题根本所在，并提交产品优化改进。

　　2、上报问题 前面讲了对于不同的问题等级上报的层面也是不一样的，下面是问题等级划分的标准，给予大家借鉴。

级别	类型	数量	上报层面
P0	重大损失类产品故障类负面舆情类	24小时内≥10个	集团CEO、运营管理VP、业务分管 VP
P1	反馈较多、比较影响用户体验、用户投诉的问题	3 天内累计>5 个 24 小时内累计反馈[3,9]个 7 天内累计反馈≥10 个	业务部门负责人开发、产品、测试负责人邮件通知开发，产品，测试负责人
P2	反馈较少且对用户体验影响不大的问题	1) 一般类问题，影响不大，且是零星反馈  2) 3 天内累计≤5 个  3) 24 小时内累计反馈[1,2]个  4) 7 天内累计反馈≥3 个	开发，产品，测试负责人
P3	个例问题	1) 10 天内累计反馈[1,2]个2) 问题在运营、业务团队都无法复现 3) 问题影响较小 4) 联系不到用户，或联系上了用户不稳定复现，或用户无法配合开发分析定位原因	开发，产品，测试负责人

3、推动解决：运营侧将问题反馈给技术后催促技术尽快解决问题，尽快给出问题原因和解决进度以及后续避免方案，对于一个初级运营考虑的是要如何把一个问题跟好，完全解决用户问题就可以了。但是对于一个老运营来说，要求技术给出一个后续规避方案，避免以后出现该类问题。

4、问题闭环：当技术侧和你说问题解决之后该问题还不算完，需要和用户验证一下问题是否解决，如果没有解决需要技术再次解决。

以上就是简单的问题上报流程，可能大家的所从事的行业和领域和我所在的领域不太一样，但是换汤不换药，其中的逻辑都是一样的。下面给大家推荐一下问题上报模版，供大家借鉴。

 

问题上报模版：

问题原因：用户反馈XXX出现XXXXX问题

是否必现：是/否

反馈例数：XXX例

影响范围：影响XXXX功能

问题原因：XXXX导致XXXX

解决进度：1、技术侧：XXXXXX 2、运营侧XXXXX

后续避免：XXXXXX

跟进人： XXX