手把手教你做客服产品——（四）体量阶段判判断

在搭建客服系统时，我们会需要对业务模式、核心指标与系统架构进行构建，而除此之外，我们还需要对当前的业务体量进行评估，并衡量好当前业务体量情况下的工作重点。那么这个阶段我们要如何进行？一起来看看作者的分析与解读。

前面三节我们已经大致对业务模式、核心指标和系统架构做了介绍，当我们进入一家公司开始从0到1搭建客服系统时，面对繁杂的业务场景和对接系统，千头万绪如何找到切入的第一根线，系好第一颗扣子，就是我们本节要回答的核心问题。

那么，下面我们就进入正篇部分的最后一节，如何评估当前业务体量，以及各业务体量下工作重点。

一、概述

业务体量或者说业务阶段，并不是新概念，经常接触产品工作的朋友一定都见过这张图。横轴代表时间，纵轴代表用户量或者营收，体现一款产品在完整生命周期中核心指标的变化。每个周期都需要针对制定策略让产品尽快进入下一个周期或在当前周期停留更长时间。

区别于TO C产品，类似客服产品的体量评估要综合考虑客服工作量和整体业务成熟度。在此我们将客服产品分为三个阶段，并对每个阶段去做具体阐释：

• 小体量定型阶段；
• 单一业务成长期；
• 大体量及多业务并行阶段。

二、各业务阶段阐释

1. 小体量定型期

• 阶段特征：业务模式不成熟，产品未定型迭代速度快，客服工作量小。
• 工作重心：配合业务模式探索，以发现和反馈问题为重点。

严格来说在此阶段并不需要客服产品，产品初创期一切为增长和商业模式验证服务，此时用户量较小，对应所需客服人数较少（3-5人）甚至部分工作由运营和产品直接处理。

产品工具方面，通过站内用户反馈、400电话和第三方通讯工具（QQ/微信等）可以直接满足沟通诉求，记录层面使用在线文档等工具也可快捷实现。

2. 单业务成长期

• 阶段特征：业务模式基本定型，产品数据高速增长，服务引发率高，客服工作量快速增加。
• 工作重心：规范客服工作流程，引入第三方工具过渡使用，开展系统基础建设。

业务模式验证后开始大规模投放引流，此时产品会迎来快速增长，同时由于新用户对产品熟悉度低和细节流程不完善，客服工作量增幅会高于业务增长速度。以电商举例，月订单量300w，月增速10%，服务引发率在2%左右波动（成熟业务一般在1%以下），客服团队所需人数30左右，并会快速增加。

此时需要客服产品逐步提供产品工具，满足逐渐规模化发展的客服团队诉求。同时由于在业务高速增长期，整体后台建百废待兴，审核、财务、风控、权限和数据平台等系统都在建设阶段，开发资源相对有限，以及业务流程细节不完善，对应的客服处理流程也经常变动。因此系统建设的切入点要把握好两个原则：

1）急需落地工具可先引入第三方服务

如IM通讯系统，市场上已有较为成熟的产品（七鱼、环信、UDESK等），基本可以实现快速引入，引入时需对数据安全问题着重考虑，比如订单、用户信息在第三方系统的呈现，个人建议比较好的选择是仅对部分用户信息披露，客服可识别进线用户即可，其余信息在内部系统查询使用。

一般完整的第三方服务还会提供任务记录、数据分析等功能，利用好这些能力，可以在初期就开始沉淀数据，为后面的数据看板等功能做数据储备。

2）高敏模块和基础架构提前搭建

高敏模块在客服业务中的表现是投诉系统，因为涉及到赔款、纠纷判责等场景，尤其是涉及资金部分，必须优先保障安全。这里需要强调强烈不建议客服使用财务系统操作资金事宜，员工角色和角色之间，系统之间需要保持边界，而边界是B端产品实践中最重要的部分。

基础架构指任务中心尤其是任务引擎部分，任务引擎做为客服系统的核心能力，主要作用是推动流程节点，同时满足任务的创建、分配、完成、回收。不仅可以满足客服各个系统使用，同时可以作用于审核、权限、审批等各个系统，是可以做为中台化的模块。

备注：这里是我们从第一节后首次提到中台的概念，有别于对某项业务定制的后台模块，中台是多业务线可抽象能力的集合，关于是否应该存在中台，个人理解在部分业务中是合理的，以客服、审核、财务系统为代表，后面我们在番外一中再详细聊聊。

3. 大体量及多业务并行期

• 阶段特征：业务成熟，市场占有率较高，公司多业务线并存，客服团队较庞大并引入外包。
• 工作重心：实现从第三方到自建迁移，逐步抽象中台能力，BP到业务线精细化运营。

如果我们所在的公司最终走到了这一阶段，举例参考，某OTA平台客服人数5000+，某短视频平台审核人数3W+，并且该团队需要同时服务于内部多条业务线，且已经有员工分级和自营外包区分。这阶段我们将要并行去做三件事情：

1）第三方服务到自建系统迁移

数据是一个公司的核心资产，第三方服务的形式决定我们无法在系统和系统之前是先完全意义的信息共享，即无法做到信息闭环，这对客服后续的精细化运营效率提升将造成最大的障碍。

自建是精细化运营的开始也是必由之路，在初期需要注意的是两个系统迁移过程中的数据继承及员工操作习惯的保留，值得提醒的是我们并非要做一套和第三方服务完全不一样的公司，而是在保留员工操作习惯的同时，改变产品内核，为以后的产品优化做准备。

2）逐步搭建客服中台

如果公司仍是单一业务线运营模式，可以忽略这部分，不过有野心的公司，在进入成熟期末尾时，为避免衰退一般都会扩大自身边界。因为有之前的成功经验和人才积累，新业务会跑得更快，要求其中如客服审核相关的支撑系统，即敏捷又稳定。

这时整个客服系统在针对新业务的服务时，更多像是一个公司内部的第三方服务系统，需要提供的更多是模块化的基础能力，参考比较主流的租户形式，实现数据间的完全隔离，将客服的基础功能模块化，供给各业务团队使用。

3）精细化运营

第二和第三并不冲突也没有先后，无论任一业务进入成熟期，都可以做精细化运营，通过各种手段，提升相关指标。

核心还是用户评价和效率，分支我们可以通过比如用户自助、交易流程优化、机器人服务改进、信息闭环深入、模块操作易用性提升等手段和方式，深入到客服业务中，发现和解决问题。

同时这一阶段我们可能会存在庞大的外包团队，以及客服同岗位员工内部分级，需要我们在权限设计、分配逻辑设计中考虑同岗多角色情况；以及会对接其他多系统的多个角色，必要时需要实现系统和系统间的信息传递。谨记核心要义，无论内部系统模块间还是各个系统间，确认好边界，高聚合低耦合。

三、最后说两句

到此为止，我们该系列的四篇正文就结束啦，其实可以深入的东西还有很多，比如每个系统模块的建设规则具体是什么，有几个信息层级，对应多少个页面，甚至原型应该怎么画，更多讲的还是偏宏观的内容。确实也很难通过短短四节内容讲好每个细节，更多是想陈述作为一个客服产品，我们在每个阶段该做什么事情，以及我们为什么要做这些事情，至于具体怎么做，只是在第三节做了框架描述。

略有遗憾不过暂时也可以作为方法论的收尾了，后面两篇番外我们继续聊聊对中台的认识和客服中台怎么做。有机会再继续分享每个模块的设计细节吧，老坑未填新坑已至，感谢看到这里的同学，谢谢。

​Read More