处理用户反馈时,我总结的几点经验

处理用户反馈时,我总结的几点经验

ID:10338169

大小:56.50 KB

页数:4页

时间:2018-07-06

处理用户反馈时,我总结的几点经验_第1页
处理用户反馈时,我总结的几点经验_第2页
处理用户反馈时,我总结的几点经验_第3页
处理用户反馈时,我总结的几点经验_第4页
资源描述:

《处理用户反馈时,我总结的几点经验》由会员上传分享,免费在线阅读,更多相关内容在工程资料-天天文库

1、处理用户反馈时,我总结的几点经验本文是笔者在处理反馈时总结的经验,可能和你在做的有一些不一样。不过,用心去对待用户,认真对待每一条反馈,我相信肯定都是一样的。互联网的用户支持和传统客服的重要区别在于:相比于客服被动地响应用户的问题,用户支持更多的会主动出击,发现并解决问题。以前做这部分工作的时候,是借助于一款协作软件去开展的,这里不提名字了。我最初是觉着这样的事情做起来没什么意思,直到慢慢的摸索出这样一套流程来,算是这部分工作最直接的收获了。我想你可能已经留意到了,它是一个闭环的流程。一、需求收集1、用户反馈要给用户留下可以联系你的渠道,一般说来有以下这些:用户

2、反馈邮箱产品反馈后台用户群(群/微信群等)新媒体(公众号、微博等)第三方社区(知乎、豆瓣、贴吧等)其他(应用市场、公关稿、办公室的一声吼…)用户会通过这些渠道把使用过程中遇到的情况反馈过来,反馈通常分为以下几类:产品bug吐槽功能建议其他(比如,以前听到多位用户来打听CEO有木有女盆友的…)(1)产品Bug如果用户描述的很清楚,我通常会自己动手看看能不能捕捉到这个bug(嗯,「人肉」测试下),然后报给团队;如果描述的不是很清楚,就按照技术猿们问我们的套路来向用户收集信息:平台、版本、页面、操作……话说后来有一天,我知道有一种工具,是可以在出现bug时,直接精准到

3、导致出错的那一行代码,根本不需要问用户杂七杂八…我承认那一刻,我其实内心深处真的是很想问候下,当年那些不尊重我们时间的猿们…愿你们有一天也要直面用户的怒火,然后持续个百十天。(2)吐槽很多原因导致用户吐槽,交互设计、页面设计、操作流畅度、业务流程等,但通常都是用户感到非常沮丧时,才会引起吐槽。所以,在和吐槽用户的交涉过程中,多含一些同理心吧。当然,吐槽真的很容易让人产生负面情绪,有段时间看吐槽多了,负能量爆棚,就天天想要逃避用户…但是,不得不承认,很多的吐槽都是有价值的,争取引导用户说出来,找到问题。如果实在累了,就去特么的,休息几天调整调整心态吧。(3)功能建

4、议功能建议分为两大类:新增功能、功能优化。这部分是反馈的重点,下文慢慢说。2、反馈收集在进行需求收集的时候,可以从以下几个方面考虑:(1)用户画像了解下反馈用户的基本信息,性别、职业、年龄层、收入等,这通常与我们所运营的产品相关,了解下是否是目标用户提出的需求。(2)用户场景用户提出这个需求的原因是什么,在什么样的情况下,想完成什么事情,做了哪些操作,结果如何?这些信息非常有助于团队成员理解需求。(3)产品信息了解用户使用的是哪个客户端(web、iOS、android、WP等),使用的版本号。很可能反馈的需求在新版本中已经解决了,但用户没有升级,所以并不知晓。(

5、4)用户联系方式记录下用户的联系方式,这条很有用,一方面用于统计分析,一方面为了完成反馈的闭环。通常,用户通过哪个渠道反馈的,就记录下该用户在这个渠道下的联系方式,如号、邮箱、评论链接、等。3、反馈处理(1)已知需求很多时候,用户的反馈是团队已知悉的,对于已知悉的需求,通常我会告诉用户团队对这个需求的考虑,以及大概的开发计划(一定记得给团队留点时间,不要向用户透露具体时间,除非这件事是板上钉钉,绝不会改变的,而这种情况是极少的)。时间允许的情况下,还可以和用户一起聊一聊对于解决方案的看法。(2)新需求对于新的需求,作好记录的同时,也不忘告诉用户,你的反馈已经收到

6、啦。(3)使用问题如果是功能使用的问题,就可以第一时间帮用户解决掉,告诉下正确的使用方法即可。二、需求管理1、需求记录用户反馈在经过筛选整理后,有很多建议会被放到需求池。通常建议是和产品迭代联系在一起的,旧的去了,新的又会来。所以,就需要对需求池进行管理。(1)归类如果用户的反馈在之前已经有类似的反馈,只需要将相同的建议统一在一处即可,不需要单独开新的需求;而对于同一功能模块下的需求,也可以归集在一处,按照不同模块来简单分类;而具备上下游关系的多个需求,可以进行关系的梳理,待上游的问题解决后,下游的需求可能自然就对应的解决了。(2)次数对于相同的需求,记录有多少

7、用户反馈过,从反馈总次数的维度了解用户比较关心的几个问题。这里要注意,并不是反馈的次数多,这个需求就一定是重要到非做不可的。一个需求能不能做,还需要考虑公司对产品的战略规划、占用的开发资源以及开发难度等问题。对于需求的考虑需要单独讨论,这通常也是产品经理考虑的问题,这里先不展开了。(3)频次顾名思义,频次就是在一定时间内,同一个需求反馈的次数。这个是从紧急度的维度去看一个需求。通常,会在新版本上线后,重点留意这个维度。如果新版本上线后一段时间,有多个用户反馈了同一个问题,那可能新版本出现问题了,就要及时通知团队,但是立即修复发新版,还是回滚到之前的版本,就要看团

8、队的考虑了。2、进度跟踪

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。