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