上篇跟大家讲了用户评分,本文接上篇来谈谈什么是服务分?服务分是怎么应用的?又是如何构成的呢?它的计算方式是怎样的?有哪些注意事项?
C端的用户是作为终端消费者的个体,B端的用户是企业或者组织。随着行业的变化,C端产品需求量正在减少,而B端产品的需求正在增加。其中面向组织内部,以提高组织效率为目标的B端产品的需求正在增加。在这样的B端产品中,服务分尤为重要。
服务分的设计需要以应用为前提。
最基础的应用是对服务者进行能力评价。所以服务分要尽可能保留会体验服务者服务能力的数据和信息。通过这种评价体系,可以引导服务者去努力达到业务的要求。
在进行能力评价的基础上,服务分要影响服务者的工作分配。这点至关重要,因为对于服务者而言,收入主要是由工作量和工作结果构成。服务分如果不影响工作分配,就无法影响服务者的主要收入构成,服务者将没有动力去提升自己的服务分。
最后服务分也应该影响服务者的升降去留。定期的服务考核是服务能力的综合体现,在给了充足机会的前提下,淘汰掉不合格的服务者是对用户负责的表现。而围绕服务分打造晋升体系也对服务者有很强的激励作用。压力和上升通道相结合的过程中,统一的服务分必不可少。
服务分主要由三部分构成:员工属性、SOP执行情况、业绩结果。
员工属性很简单可以理解,不同基础属性的员工需要给不同的评定标准。比如教育背景、工作年限、取得的评级、职业资格证书等,这个属性反映的是一些客观可衡量的用户属性。
SOP执行情况则用于评估员工的执行力。SOP(Standard Operating Procedure,标准作业流程)是服务行业中服务者都需要遵循的守则,由服务设计团队设计,通过标准化的流程,保证每个用户的体验。
比如你进入一个化妆品店,服务员会有一整套话术跟你沟通,并且根据你的回答调整自己的话术从而获得好感,并且达到给你推荐合适化妆品的目的。在线上产品中,很多动作都有系统级别的记录,比如送外卖到店点击到店、到家点击送达,快递员在不同的配送节点也需要对包裹扫码。
这些SOP如果有线上动作,则可以量化是否执行到位,比如通话时长是否达标、配送时间是否超时。如果没有线上化,则需要进行质检,简而言之就是抽查。服务质检方法在传统服务行业中很成熟,不做展开。总之可以通过对SOP的评估,得到服务者的SOP执行到位的程度,也就是衡量服务者是否听话。
业绩结果很好理解,就是服务最终得到的收益,也是服务分的重中之重。实际上SOP只能保证服务的下限,把SOP执行到位不能保证成为优秀的服务者,要取得业绩,需要更多的技巧和灵活性。比如对于教师而言,同样的ppt不同的授课风格会导致不通的结果,比如在SOP之外有些专车司机会更加贴心获取好感。
在业绩衡量的时候除了绝对的业绩数量,还需要看业绩的质量。收入的质量最简单的衡量方式就是用户评价。加入用户评价可以防止服务者为了提升业绩,而降低服务标准引起用户不满,比如外卖提前点击送达、司机绕路、快递员不联系用户直接扔门口。虽然从个体上来看服务者业绩增加了,但是这样的服务会让用户对平台产生负面影响,所以需要遏制。
在业绩结果评价中还需要特别注意的是,很多复杂流程需要对结果数据进行归因,比如销售的业绩和销售线索的质量高度相关,为了整体效益销售线索往往不是均匀分配的,好的销售线索本身就有更高的转化概率。
对于销售而言,更合理的方式是拆分出销售贡献提升的转化率。当然,目前销售行业并没有这样衡量,因为归因确实太复杂了并不直观。
服务分的计算其实就是把这些数据综合起来变成一个0~100的分数。并且给出每一个细节的拆解,让服务者知道后续哪些地方需要提高。
一般而言,是需要对不同的子项加权求和。并且分层确定权重。针对不同的数据分布情况,给出具体的划分规则。这个分数和大学课程成绩类似,平时分共40分,其中出勤10分,作业20,小论文10分。考试分60分,考试分选择题40%,简答题60%。在这个规则中平时分和考试分就是第一层,下面的子项是第二层。
服务分的计算方式就是分析清楚业务不同分类下的子项是什么,然后根据服务者的数据分布,给出归一化的规则。然后加权求和,转化为100分。
因为服务分对公司重要,所以需要在管理层达成共识;因为服务分对服务者重要,所以需要让服务者理解;因为服务分要提高服务者绩效,所以需要提供细节的拆分,让服务者知道哪里弱,可以继续提高。
所以在服务分设计时,解释性非常重要。不能用过于复杂的数学工具,并且要给出详细的计算过程,让服务者能够自己复盘。
因为服务分要配合绩效使用,所以也需要经过财务核算,保证整体预算方案合理。
因为服务分影响服务者的升降去留,所以也需要和人力资源配合,提前公示,并且提前做好规则设计,防止后续调整影响管理权威。
在具体设计过程中,涉及到一些归一化、加权求和、归因等数学方法,这些我们下次再聊。
潘一鸣,公众号:产品逻辑之美,人人都是产品经理专栏作家。毕业于清华大学,畅销书《产品逻辑之美》作者;先后在多家互联网公司从事产品经理工作,有很多复杂系统的构建实践经验。
本文原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自 Unsplash,基于 CC0 协议