由客诉单处理而引起的关于需求排序的想法

2018-07-12  本文已影响0人  站在教堂路口的胖子

关于需求的收集啊、采集什么的应该会在其他的文章中专门写一下,这里就谈一点在工作中遇到的问题。
记得以前读书看文章的时候对于我这种产品没有入门的人来说,需求的排序可以用 ||紧急|| 和 ||重要|| 这两个维度来衡量,按顺序依次是:紧急且重要,不重要但紧急,不紧急但重要,不重要也不紧急(现在我购物的时候也会采用这个法则。。。发现省了很多钱)这里面呢,紧急和重要很多时候是重合的,具体的说就是像发生了比较范围广的bug这种肯定是紧急重要的了,但是一些很难碰见的bug,特别是很多情况下是客户操作不当引起的没有严重后果的bug可以算不重要也不紧急了。。。我是这么觉着的;像要添加一个很能提升用户体验的一个功能,我觉得可以算不紧急但重要的了,除此之外还有些小bug,改了他们很重要,但是发生的情况不多,所以不是很紧急;不重要但紧急的话,我觉得有点少见,因为一般紧急的好像都蛮重要,但不排除这种情况:需要和外部系统对接的时候,对于自己的产品不是重要的问题,但是对接的部门很重视很紧急,所以算是不重要但紧急的;紧急和重要的判断我个人觉得如果没有一些不可抗力(比如领导要求啊,业务提的需求啊)之类的,都应该以 |||提高客户体验||| 为标准。
接下来呢,我单纯以上个月的客诉单处理情况来排个序。


image.png

这个应该不会泄露什么公司秘密吧,如果有谁看到了觉得涉及安全问题麻烦说一下,我好删掉。。。谢谢
问题比重占10%以上的有三个,延期和退款不是什么硬性问题,应该算是业务处理上的问题,在前台系统里没加,只能后台人工操作,如果作出修改的话可以提高很多用户体验,所以可以划归到重要但不紧急的范畴里(其实加的话估计有涉及很多权限、财务问题,感觉挺麻烦的,而且说实话,不是业务需求,能提高用户体验程度但是不能增加业务量。。。估计这辈子是做不出来了,这种辩证的思考方式可能是我考研政治最大的收获吧。。。)系统处理问题的话就很严重了,这就是bug啊。因为系统处理出问题直接影响到用户的购物,并且细分问题里有不少的比例在一些拉新活动中,这就很扎心了。。。新用户还没来就不想用了。毫无疑问第一个待解决。接下来看一下5%以上的,开发票,特殊问题和规则理解,基本上也属于能提高用户体验但不能增加业务量的内容,不过这里面的规则理解我个人觉得还是有点重要的,对于规则理解出问题的主要是新用户、或者购买了新产品的老用户,这个规则如果不做进一步的说明是会损失一部分用户的,相较而言,延期和退款利用人工处理的话并不会减少用户量。而且开发票这个问题最好也能解决一下,开发票的一般是小规模的批量购卡。。。大客户都是有单独通道的,所以对于发票问题的解决能够增加一定的用户粘度,重要,但不紧急。
so,这么看的话需要处理的是5%以上的问题,数量太少的话就可以划归到不重要且不紧急的了。
1.系统处理问题 重要且紧急
2.规则理解 重要但不紧急
3.开发票 重要但不紧急
4.延期 重要但不紧急
5.退款 重要但不紧急
这么排序的原因在上面也说了,主要是考虑到拉新和增加用户粘度的问题,虽说满足用户体验的产品才是好产品,但是既能提高用户体验又能提升业务的产品才是正确的产品吧。。。

上一篇下一篇

猜你喜欢

热点阅读