服务产品思维
服务产品思维
说在前面:服务产品这个词自己已经不陌生了,之前的大部分工作都是在服务产品的设计上,但是概念上的理解,还是过于陌生,因此记下来加深印象的同时,让自己的认识更加深刻。
服务产品定义
服务产品是指不具有实体,而以各种劳务形式表现出来的无形产品。如旅游业、信息咨询、法律服务、金融服务等。菲利普·科特勒认为:服务是一方能够向另一方提供的基本上是无形的任何功效和利益,并且不导致任何所有权的发生。它的生产可能与某种有形产品密切联系在一起,也可能毫无联系。
很表象的理解就是服务产品不同于实体的可见性,流程、规则等服务元素虽然可以文档可视化,但是实际最终整体的服务结果并不是一个规则或者一个流程就足够的,而是多流程、多规则的组合结果。并且该组合过程的随机性根据用户需求是完全不一样的,所以服务对于不同的个体来说都是个性化的。
据此,服务产品又可区分为以设备为基础的服务产品和以人为基础的服务产品两部分。服务产品就有无形性、不可分离性、易逝性、可变性、相互替代性等。因此,提供此类产品的企业应加强服务质量管理,提高服务人员综合素质,以提高企业的知名度和美誉度;定价更为灵活;多倾向于顾客导向定价;直销和经由中介机构销售较多采用;正确利用人员推销和广告。
与其说服务产品的区分,不如说是服务产品的简单组成元素,包含上图所示的内容。(ps:后文会通过服务产品的设计过程描述,更准确的去定义服务产品的组成。)
理论参考:服务产品(servicing products)。
服务产品案例【搭建质量服务产品的心路历程】
这里引入一个工作中的例子来更深刻的理解以上的理论内容。
老规矩,一切想法的源头都是故事。
【第一个故事】
质量管理部门牵头完成了“极端红一高危范围”的拟定、评审和确认。评审确认会议在上周就已经完成,但是业务应用团队还是会一直不确认实际应用时间和范围。该处的不确认的体现:
1、 是否已经生效?
2、 我在哪里可以查到?会议之后还有变更吗?
3、 隐藏的问题:如有不清楚的地方,是否可以清楚明白的获得解答(最好是白纸黑字,易懂无歧义,能触达到每个人)
由此,!!#cc0000 业务的担忧实际是对信息的不确认,那是不是所有此类信息都会存在这种同步困难?应该怎么同步呢?!!
【第二个故事】
质量管理组的同学天天都会收到各种各样的问题,当然质量组同学是期望所有的问题都支持、协助去解决,但同样的问题被反复问到多次,还是没有完全普及到所有业务同学这就样质量组的同学为难了。
小A:我上传的数据表有12条数据,为什么已上传数据只展示了8条?【质量数据】–涉及指标和考核的信息对齐
小B:我在平台上操作质检提交完成后为什么短时间内还能查出来呢?【质量平台】–工具平台与工作效率
小C:【抽样理论】–方法论和质量知识
小D:质检对标准有疑问或与人工理解存在偏差时,是否提出问题并与标准团队拉齐执行尺度,单点案例反馈是否可以以点盖面作为质检出错结果?【质量标准】–与日常执行相关的依据
…….
以上问题可以看出,!!#cc0000 业务侧对质量信息的需求有很多,包含咨询、学习、协助等。那针对这些信息每次都要解答一遍是不是太费力了?应该如何让一个问题同步到所有需要知晓的同学呢?!!质量管理组针对该类问题都有自己的解答,只是每次回答的仅仅是一个人的问题,不是一群人的问题。
“咀嚼”故事
故事讲完了,可相同的问题却一直存在,我们可以理解以上故事里我们迫切需要一个大家公认的地方,实时更新此类信息,并且提供咨询、支撑和协助等横向支撑业务的能力。一方面为了解决业务侧对质量信息的咨询需求;另一方面也是为了让质量管理组有一个与业务互动交流的渠道。
我知道这一整套服务目前是每个人或者每个小团队独立支撑的,如何才能整合这一些独立的支撑能力,形成完整的一个质量支撑面呢?
这个时候我想到了服务号,作为1-3个服务人员与整个部门同学互动的枢纽,它起到了至关重要的作用。它之所以被大家共识的原因:
- 官方承认的渠道
- 24小时服务的支持
- 降低了社交成本(特别针对社恐人士的心理层面)
构思一个服务产品
故事“咀嚼”到这里,我们开始思考,是不是也可以建立这样一条通道来横向支撑所有部门同学对质量的需求?
1、底层服务需要的内容支撑从哪里来?【信息源】
在常用的办公场景中,wiki作为业务知识库而存在,因此所有的服务内容,我们可以依赖该平台来实现信息的承载和知识的沉淀。
2、如何打通横向沟通的渠道?【信息的传递】
沟通即存在交互与信息的传递,目前企业微信是最便捷的渠道,学习成本最低且能与每一位同学都能随时建立联系。因此企业微信服务号是一条不错的途径来打通该渠道,实现期望的信息传递和交互。
3、长线运营的便利性如何实现?【交互的高效和便捷】
服务上为了提高效率,也减少内部的重复工作,沉淀的内容可以转化为知识点由机器人【智能开放平台的能力】直接解答,让该部分重复工作的精力得到解放。另一方面,知识的沉淀持续下去在未来的应用中可以去发现和挖掘更多的场景。
综上,那我们可以利用wiki+企业微信服务号+智能开放平台的能力来组建一套完整的平台和互动机制。
理论存在,开始实践。
1、信息整理
确认利用!!#cc0000 当前客观存在的,且有一定公信力的平台-iwiki!!来作为服务内容的信息承载和知识沉淀之后,就需要整理出整体信息的架构,并协同各知识层面的同学对内容进行补充完善。
2、渠道打通
- 企业微信服务号申请
- 企业微信与智能开放平台对接
- 企业微信服务号服务窗搭建
3、智能服务的建设
(1)智能服务与企业微信服务号的打通
实现在企业微信上应用已经完成配置的机器人,且采用机器人优先服务的方式,当机器人无法解答的时候再由人工直接受理相关咨询或需求。
(2)智能服务的知识体系建设
- 根据wiki内容沉淀对应的知识体系【持续沉淀、运营】
注意:所有业务时效性信息需要根据业务实时更新。
说在最后:质量服务产品初步建设已经基本完成,运营才刚刚开始,产品的建设是离不开运营的,因此在整个产品设计与实现过程中没有完全融入运营的概念是本次质量服务产品设计完成的不足之处,但好在整体设计都没有完全限定业务的适用范围,也没有过于定制化的实现某个功能,都可以根据业务运营来进行对应的调整,期待后续的应用与实践。