编辑导读:对于产品满意度调查,你是怎么理解的呢?如何评判这个调研是否客观呢?满意度调研是为了得知用户对于产品的满意度情况,收集用户的建议,是衡量我们工作的一个维度和迭代优化的参考。本文作者以B端系统为例,对其满意度进行分析,希望对你有帮助。
之所以要写这篇文章,主要是近期的两个事件,事件一是近期部门的OKR中,其中的一条就是系统用户满意度达到一个较高的指标。事件二是近期使用我们系统的业务部门,自行发起了一个给系统打分的调研,给到系统平均仅为及格分。
这两个事件,不得不让我去思考一个问题:什么才是真正客观的系统满意度调研。
在开始正题之前,想说一下刚提到的打分的事。有一句我很喜欢的话,来自罗胖罗振宇:“数字化对你来说是蜜糖还是毒药,只取决于你是对人负责,还是对事负责。”在这个例子中,调研的角色全部一线的操作人员,他们通常只是为了事情负责,可以想象当你的职责只是把事情做完,早点下班,应对上级的考核时,你会觉得系统是帮助你的吗?我更希望不要使用系统,不去做这些操作,不去考虑各种限制,那我可以把事情完成得更快。
所以给系统打多少分,只取决于人的目的,不能用简单粗暴的调研方式。
认真思考以后,我对系统满意度调研的目的思考是这样的:
- 满意度调研是为了得知用户对系统的满意程度,它是衡量我们工作成果的一个维度。
- 满意度调研可以让我们收集到来自用户的建议,这是我们系统迭代优化的一个很重要的输入。
基于这样的目的,将分为三个维度展开,怎么去设计一个好的调查问卷,怎么更有效的获取用户满意度和建议。
一、基于用户的分类去设计问题
我认为好的满意度调研,首先要明确用户群,就像上文提到的,不同的人使用系统的目的不一样。如果采用同样的调研方式,会导致数据无效。本文所讲的B端系统,我认为通常会有两大角色:
- 管理者,指的是公司级目标的承接者,也是系统需求的提出者,一般是管理层的人员。
- 操作者,指的是系统的直接操作者,他们会以执行者的角度,行使管理层给到的具体工作目标,通常指的是一线工作人员。
如何去针对这两类人群设计问题,我的思考是全基于角色和系统相关的期望设计问题,因为系统就是为他们去设计的,针对他们最关心的事提问,能得到更真实的答案。
对于管理者:
监管一线人员的操作流程及时效。
可以设计出这类问题,系统流程是否贴合业务流程的设计;是否有核心的业务流程都在系统中运转。
有较好的报表的丰富度及数据准确性。
系统的报表是否足够灵活;数据是否与实际情况相差甚小;报表的丰富度是否能满足分析现状及展望未来的需要。
有较高的需求的满足效率。
提的需求是否能及时上线;需求的透明度是否足够。
对于操作者:
能快速简单地上手一个系统。
系统的操作流程是否足够简化;培训教材是否足够生动。
顺畅的系统使用体验。
对于系统的交互体验是否满意;大多数情况下是否能轻松走完流程而不被系统问题所阻碍;系统是否有逐步提升工作效率。
较高的的疑问解答效率。
提出的系统问题是否能被及时响应;是否能被及时解决。
以上只是我目前想到的涉众期望及提问,只是一个引导,可以再根据实际情况发挥。
二、问卷的设计
就像上文提到,我们做满意度调查,一是真的去看系统用户的满意度,二是收集建议。那问卷的设计就要紧跟这两大主题。
对于满意度,最高效的就是针对问题内容打分,打分的方式有很多种,有满意或否定制;五星制;十分制;一百分制。我推崇的是五星制,相对于是或否,它有更多的选项也就能更准确;对于十分制,它更简单好操作,且当样本足够多时也足够精确。这里可以参考豆瓣的电影或书籍的评分,我觉得非常经典。
对于收集建议,每个问题下的文本收集是最有效的,但人常忽略的一点是,大多数人给的建议是无效的,从而导致分析人员面对大量的不可靠的信息。我的想法是,要不然就不写,要写就要求认真写。所以建议可不填写,但如果有文字,那就要求字数有达到一定的限额。
此外,每套问卷的问题一定不能过多,十个以内足矣想想平时做的一些长达二十条甚至更多问题的问卷,你是否还有心情去认真一个个回答?
三、评分的计算
这里就涉及到了权重的问题,假设你已经得到了两自管理者和操作者,两套问卷各自均分,但最终需要得到一个分数,你会如何去权衡?一边人数极少,但具有话语权;一边人数多,操作最频繁,但是却没什么影响力。
我觉得,就像前文说的,系统对于不同的目的的人,态度可以截然相反。所以没必要去求得一个最终分数。但如果是公司或上级的要求,我的想法是偏行为监管的系统,比如仓管系统或供应链系统,权重偏向管理者,偏与一线终端用户打交道的系统,比如客服系统,权重偏向操作者。
四、结尾
以上就是现阶段能想到的B端系统满意度调查的方法论,也希望能得到大家的指正,后续如果有新的感悟,会更新下去。
本文由 @旭无双 原创发布
题图来自 Unsplash,基于 CC0 协议