最后更新于： 2023年3月19日
2016年我来深圳后，开始接触客服系统项目，兜兜转转几年，换了三家公司，最近接手的一个项目，依然是这个领域，有些感慨。
大部分公司对客服系统投入并不大，一开始只是纯粹买一些系统凑合用。随着业务的发展，必然会遇到系统整合的问题。举个最简单的例子，买的是第三方的呼叫系统，客户来电时，如何第一时间知道来电者的业务信息（个人基本资料、交易订单等）？这就必须将第三方系统与我方的内部业务系统打通。
系统整合意味着需要开发定制，也就是研发人力资源的支撑。很多公司对客服业务并不太重视，秉承着“能用就行”的原则，让客服依靠人力去支撑，实在是支撑不起来时，才开始想办法整改一下。我能理解这样做的原因，每个公司资源都是有限的，客服是成本部门，不会被优先照顾，总是排在最后才考虑。
基于以上现状，对于做客服系统的产品经理们来说，有时候的确挺尴尬的。想做的事情很多，但是资源非常有限。巧妇难为无米之炊，对吧？
如果是来到一个比较重视客服系统的公司呢？例如我司。状况会好一些，但是有些固有的难题也依然存在本质上，客服是做支撑业务的，TA是需要其他部门配合才能完成工作的。客服只是问题的入口，除了最基础的咨询类问题，很多业务问题都是要客服之外的其他部门来协助处理。
所以，客服系统需要依赖于其他系统，并不能单一系统运行。在多个系统之间来回切换操作，是一个非常典型的客服工作场景，也是我们一直在争取改进的一个点（尽量减少系统切换，在一个系统内完成操作）。
系统与系统之间一般是通过接口来调用。因客服系统迭代需要，向其他系统提接口需求，这就是我们日常工作的主要内容之一。问题是，其他业务部门是很忙的，他们也堆积一大堆需求待办，客服的需求，在他们眼里，优先级并不高。套用某领导的原话，就是客服系统这些所谓常规需求，“不做又不会死”。
的确，我也同意，大部分时候，大部分系统的大部分功能，都是“不做又不会死”的。只是，在其位谋其职，总得有活干，不是么？我不是在说“做一天和尚撞一天钟”的意思（将来报道出了偏差你们可得负责哟。。。），而是说，如果一个系统，TA有一两个改进点，好像不改问题也不大对吧，不过如果TA有几十个乃至上百个改进点，那就不是可以简单说“不做又不会死”的。
要知道，做内部系统，其实比做面向外部的系统，压力大很多（几百号人的客服部，系统出了点啥问题，在群里一喊，领导就都知道了。。。）。客服部以妹纸居多，也得小心哄着。。。
其实我很能理解领导们是怎么想的：你们这帮人整天捣鼓这个客服系统，两三周一个迭代，投入这么多人力，总得给我一些量化指标吧？例如操作效率提升了百分之多少之类的。。。一个内部系统，从无到有，可能确实效果显著，只是从有到更好，效果就不见得那么好衡量了。我又想起在以前公司的一个尴尬例子了，当时我们以为新系统能大幅减少客服处理每一单的操作时间，结果最后拉了数据一看，差别并不大，最后只能得出这么一个结论：单纯从每单操作耗时维度来看，客服工作已经没有多少可以改进的空间了，只能从其他角度来挖掘改进。
话说回来，做了这么久客服系统，也有那么点久病熬成医的意思了，还是多说点干货吧。
大部分客服系统，都以工单系统为核心。原因无他，方便用统一的载体来记录跟进每个客户的咨询信息。来电变成一个工单，邮件变成一个工单，在线咨询也变成一个工单，万物皆工单。
所以，如果公司有研发能力的话，建议自己做核心的工单系统，这个系统可以和其他内部系统，乃至外部系统，做深度整合。
工单系统的主流程就是工单这个载体是如何记录（创建）和流转的。每个公司的业务要求不一样，所以定制的流程节点也不太一样。最简单的可以是“新建>处理中>已关闭”，实际会更复杂一些。
至于工单系统之外，给客服同学用的一些周边配套系统，购买第三方还是自研，就见仁见智了。市面上成熟的客服系统供应商非常多，有卖一整套解决方案的，也有单独售卖某一类客服能力的（如呼叫系统、在线客服等）。你可以自己研发工单系统，然后配合外采一些系统来整合，这是比较常见的做法。
外采系统会涉及到选型的问题。如果你对系统整合要求不高，那么SAAS产品就够用了。如果是对系统整合要求很高，就不可避免要采取本地化部署和定制的方案了。市面上的客服系统供应商大部分都主打SAAS，能做本地化部署的很少，或者说，即便能做，可参考案例也不多（不缺钱的甲方，如银行类机构，必然是要求做本地化部署的）。我也是来到这边才知道，原来还能要求供应商介绍去他们的客户那里实际参观考察的。。。
我本人是不太赞成重复造轮子的，能用市面上成熟产品的话，尽量用。迫不得已才考虑自研。举个例子，在线客服（IM）这块，其实已经非常成熟，供应商也特别多，这种就没有必要自己重新发明一套了。
客服同事往往会提出很多需求，有时候不能简单靠“频次高不高”来决策做还是不做。例如有些出现概率很低的场景，按照一般理解，产品经理应该把这类需求优先级降低，但是某些场景一旦出现，会有破坏性的影响（如容易引发舆情或者造成重大损失），这种需求就还是得及时排期实现的。
时间管理四象限法，也可以用一用，但不能光靠这玩意儿来评估需求。确实有些需求拖了很久没做，不是因为不重要不紧急，而是因为没人力罢了。客服同学一直在喊，然而研发人力就这么多，只能摊手。
控制好客服同事的预期，是很重要的。虽然是内部系统，但也不是有求必应的。尤其是，客服流动性比较大，如果换了个对接人，可能TA就会推翻前任的一些系统打造的思路和方向。研发是最讨厌把系统改来改去的，表层的功能性改动还好，要是你让他们把底层逻辑也给推翻了，他们不气炸了才怪。所以，一开始的系统整体框架打造是十分关键的，要留好足够的扩展性，同时也得让客服的关键决策人理解，这些底层的最基本逻辑是不能随便改的。打个比方，你都盖了10层楼了，才和我说要重新挖地基，这不是开玩笑么。。。
另外，客服领导的想法，和一线坐席的想法，经常差别是挺大的。一味听领导的，迎合领导去做需求，容易被一线抵触，做出来的东西不受欢迎。可是，PM也不能光听一线人员的反馈，因为，他们受限于自己的岗位层级，看到的，和想到的，没有领导层那么深远。所以说，上层路线要走，多和领导通气，了解领导想要啥；群众路线也要走，多去一线看看，聊聊，听听一线的吐槽也挺好的，接地气，才能做出更好的产品。
在去客服部之前，好些同事都提醒我说，客服那边对产品部颇为不满，要小心处理好与客服的关系。去了之后，我发现还好，毕竟我是去给她们做系统的，我要是跑了，不就没人了嘛。。。同事们会这么说，也是有原因的。当我代表客服与其他业务线产品沟通某些需求时，经常被以“影响用户体验”或者“使用频次不高”为理由挡回来。可能，我还能站在产品的角度，与双边理性沟通一下，充当缓冲的作用？如果是以前，可能这种被拒绝的情形多了，客服自然会对产品部没有啥好印象了。
最后的最后，再说一句，其实客服系统本身真的不复杂，就是比较琐碎。基本框架搭建起来后，剩下的工作，都是纯粹处理业务性的需求。如果你想入坑，那么建议搞一些高端大气上档次的方向，如AI智能客服之类的，否则可能你会觉得，好像都挺平淡的（相比起做其他系统来说）。
然而生活大部分时候不也是挺平淡的么，习惯就好吧？