客服系统的玄学

最后更新于: 2023年3月19日

2016年我来深圳后,开始接触客服系统项目,兜兜转转几年,换了三家公司,最近接手的一个项目,依然是这个领域,有些感慨。

大部分公司对客服系统投入并不大,一开始只是纯粹买一些系统凑合用。随着业务的发展,必然会遇到系统整合的问题。举个最简单的例子,买的是第三方的呼叫系统,客户来电时,如何第一时间知道来电者的业务信息(个人基本资料、交易订单等)?这就必须将第三方系统与我方的内部业务系统打通。

系统整合意味着需要开发定制,也就是研发人力资源的支撑。很多公司对客服业务并不太重视,秉承着“能用就行”的原则,让客服依靠人力去支撑,实在是支撑不起来时,才开始想办法整改一下。我能理解这样做的原因,每个公司资源都是有限的,客服是成本部门,不会被优先照顾,总是排在最后才考虑。

基于以上现状,对于做客服系统的产品经理们来说,有时候的确挺尴尬的。想做的事情很多,但是资源非常有限。巧妇难为无米之炊,对吧?

如果是来到一个比较重视客服系统的公司呢?例如我司。状况会好一些,但是有些固有的难题也依然存在本质上,客服是做支撑业务的,TA是需要其他部门配合才能完成工作的。客服只是问题的入口,除了最基础的咨询类问题,很多业务问题都是要客服之外的其他部门来协助处理。

所以,客服系统需要依赖于其他系统,并不能单一系统运行。在多个系统之间来回切换操作,是一个非常典型的客服工作场景,也是我们一直在争取改进的一个点(尽量减少系统切换,在一个系统内完成操作)。

系统与系统之间一般是通过接口来调用。因客服系统迭代需要,向其他系统提接口需求,这就是我们日常工作的主要内容之一。问题是,其他业务部门是很忙的,他们也堆积一大堆需求待办,客服的需求,在他们眼里,优先级并不高。套用某领导的原话,就是客服系统这些所谓常规需求,“不做又不会死”。

的确,我也同意,大部分时候,大部分系统的大部分功能,都是“不做又不会死”的。只是,在其位谋其职,总得有活干,不是么?我不是在说“做一天和尚撞一天钟”的意思(将来报道出了偏差你们可得负责哟。。。),而是说,如果一个系统,TA有一两个改进点,好像不改问题也不大对吧,不过如果TA有几十个乃至上百个改进点,那就不是可以简单说“不做又不会死”的。

要知道,做内部系统,其实比做面向外部的系统,压力大很多(几百号人的客服部,系统出了点啥问题,在群里一喊,领导就都知道了。。。)。客服部以妹纸居多,也得小心哄着。。。

其实我很能理解领导们是怎么想的:你们这帮人整天捣鼓这个客服系统,两三周一个迭代,投入这么多人力,总得给我一些量化指标吧?例如操作效率提升了百分之多少之类的。。。一个内部系统,从无到有,可能确实效果显著,只是从有到更好,效果就不见得那么好衡量了。我又想起在以前公司的一个尴尬例子了,当时我们以为新系统能大幅减少客服处理每一单的操作时间,结果最后拉了数据一看,差别并不大,最后只能得出这么一个结论:单纯从每单操作耗时维度来看,客服工作已经没有多少可以改进的空间了,只能从其他角度来挖掘改进。

话说回来,做了这么久客服系统,也有那么点久病熬成医的意思了,还是多说点干货吧。

大部分客服系统,都以工单系统为核心。原因无他,方便用统一的载体来记录跟进每个客户的咨询信息。来电变成一个工单,邮件变成一个工单,在线咨询也变成一个工单,万物皆工单。

所以,如果公司有研发能力的话,建议自己做核心的工单系统,这个系统可以和其他内部系统,乃至外部系统,做深度整合。

工单系统的主流程就是工单这个载体是如何记录(创建)和流转的。每个公司的业务要求不一样,所以定制的流程节点也不太一样。最简单的可以是“新建>处理中>已关闭”,实际会更复杂一些。

至于工单系统之外,给客服同学用的一些周边配套系统,购买第三方还是自研,就见仁见智了。市面上成熟的客服系统供应商非常多,有卖一整套解决方案的,也有单独售卖某一类客服能力的(如呼叫系统、在线客服等)。你可以自己研发工单系统,然后配合外采一些系统来整合,这是比较常见的做法。

外采系统会涉及到选型的问题。如果你对系统整合要求不高,那么SAAS产品就够用了。如果是对系统整合要求很高,就不可避免要采取本地化部署和定制的方案了。市面上的客服系统供应商大部分都主打SAAS,能做本地化部署的很少,或者说,即便能做,可参考案例也不多(不缺钱的甲方,如银行类机构,必然是要求做本地化部署的)。我也是来到这边才知道,原来还能要求供应商介绍去他们的客户那里实际参观考察的。。。

我本人是不太赞成重复造轮子的,能用市面上成熟产品的话,尽量用。迫不得已才考虑自研。举个例子,在线客服(IM)这块,其实已经非常成熟,供应商也特别多,这种就没有必要自己重新发明一套了。

客服同事往往会提出很多需求,有时候不能简单靠“频次高不高”来决策做还是不做。例如有些出现概率很低的场景,按照一般理解,产品经理应该把这类需求优先级降低,但是某些场景一旦出现,会有破坏性的影响(如容易引发舆情或者造成重大损失),这种需求就还是得及时排期实现的。

时间管理四象限法,也可以用一用,但不能光靠这玩意儿来评估需求。确实有些需求拖了很久没做,不是因为不重要不紧急,而是因为没人力罢了。客服同学一直在喊,然而研发人力就这么多,只能摊手。

控制好客服同事的预期,是很重要的。虽然是内部系统,但也不是有求必应的。尤其是,客服流动性比较大,如果换了个对接人,可能TA就会推翻前任的一些系统打造的思路和方向。研发是最讨厌把系统改来改去的,表层的功能性改动还好,要是你让他们把底层逻辑也给推翻了,他们不气炸了才怪。所以,一开始的系统整体框架打造是十分关键的,要留好足够的扩展性,同时也得让客服的关键决策人理解,这些底层的最基本逻辑是不能随便改的。打个比方,你都盖了10层楼了,才和我说要重新挖地基,这不是开玩笑么。。。

另外,客服领导的想法,和一线坐席的想法,经常差别是挺大的。一味听领导的,迎合领导去做需求,容易被一线抵触,做出来的东西不受欢迎。可是,PM也不能光听一线人员的反馈,因为,他们受限于自己的岗位层级,看到的,和想到的,没有领导层那么深远。所以说,上层路线要走,多和领导通气,了解领导想要啥;群众路线也要走,多去一线看看,聊聊,听听一线的吐槽也挺好的,接地气,才能做出更好的产品。

在去客服部之前,好些同事都提醒我说,客服那边对产品部颇为不满,要小心处理好与客服的关系。去了之后,我发现还好,毕竟我是去给她们做系统的,我要是跑了,不就没人了嘛。。。同事们会这么说,也是有原因的。当我代表客服与其他业务线产品沟通某些需求时,经常被以“影响用户体验”或者“使用频次不高”为理由挡回来。可能,我还能站在产品的角度,与双边理性沟通一下,充当缓冲的作用?如果是以前,可能这种被拒绝的情形多了,客服自然会对产品部没有啥好印象了。

最后的最后,再说一句,其实客服系统本身真的不复杂,就是比较琐碎。基本框架搭建起来后,剩下的工作,都是纯粹处理业务性的需求。如果你想入坑,那么建议搞一些高端大气上档次的方向,如AI智能客服之类的,否则可能你会觉得,好像都挺平淡的(相比起做其他系统来说)。

然而生活大部分时候不也是挺平淡的么,习惯就好吧?

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注