背景
为什么客服需要调度？阿里集团客户体验事业群（CCO）目前承接了阿里集团以及生态体的客户服务业务，我们的客户通过各个渠道来寻求解决各类问题，每天的进线量巨大，而且经常伴随着突发性进线，比如天猫代金券出了问题，在几分钟内就会造成几千通热线或在线咨询。面对种类繁多、海量、突发的客户问题，我们的服务能力往往难以满足，常常造成用户排队，甚至放弃，自然我们产生了对调度的需求。
客服调度的核心问题是什么？提升客服资源的利用率和服务水平，用更少的客服资源获得更佳的用户体验。如果我们招聘大量的客服，也能让用户获得更好的体验，但是容易造成人力浪费，更多的人手意味着更多的培训成本、管理成本和人力成本。
与机器调度相比，客服调度有它的复杂点：
1）机房增加一台新物理机，机器虚拟化后就可以快速被使用，而招募一个新客服，得需要长时间的培训才能让他具备线上服务能力；
2）客服间差别大，不同客服的业务技能有区别，很难直接让B技能组的客服处理A技能组的任务，即使是掌握同一技能的客服，他们的服务能力也有大的差别，而机器差别不大，很多业务可以使用相同类型的机器；
3）客服是人，他有权利选择上班、小休，他的工作效率、质量会随着他的情绪、体验、服务的会员、工作时长等波动，调度时需要考虑他们的感受，而调度机器时无需顾忌；
4）突发场景多，业务问题、系统故障等都是无规律爆发，波动特别大，很难准确的提前排好一天的人力。
现场管理员是否能应对如此复杂的客服调度？答案是否定的。在没有调度系统之前，现场管理员基本靠手工来调度，随着体量越来越大，缺陷逐渐暴露：
1）响应慢：比如周末线上排队时，现场管理员可能会收到电话反馈，然后再打开电脑去手工放个临时班等等，从排队发生到调度生效超过十几分钟很正常；
2）不精准：缺乏数据指导，统筹优化能力弱。举个例子，A技能组排队时现场管理员想将A技能组的流量切一些到B里，切多少，分给谁，可能都是拍脑袋决定，决策结果也无法沉淀；
3）手段缺：可用的手段非常少，无非就是手动排班放班、手工切个流，管控下小休、发个公告等，没有充分挖掘出客服的能力和潜力。
明确了客服调度的核心问题，也知道了难点，更看到了目前的现状后，我们决定打造一款自动、智能的客服调度系统——XSigma。
1. XSigma大图
XSigma调度系统按功能模块可以分为手、脑、眼几块。手就是能提升客服资源利用率、客服服务水平以及提升客户满意度的手段，比如溢出分流、预约回拨、现场管控、激励、排班、应急放班、培训等。手段这么多，在不同业务不同场景下如何抉择是一个难点，这里需要大脑也就是调度中心来做决策。决策产生的复杂调度逻辑如何能让现场管理员、业务人员和开发人员更好地理解？我们通过可视化技术将复杂的调度逻辑转化为可以理解的实时图形界面，即调度系统的眼睛-调度大屏。手、脑、眼功能具备后，如何让他们磨合得越来越好？我们通过仿真演练系统来锤炼。
下面会对图里的模块一一介绍。
2. 提前准备：排好班
如果能预测好需，准备好供，那客服调度就成功了一半。在我们业务中，不同类型的客服排班模式不同。云客服采用的是自主选班模式，管理员只需设置好每个时间段的选班人数，让云客服根据自己的时间来自行选班。而SP（合作伙伴）采用的是排班模式，需要管理员根据每个时间段的话务量来安排每一个客服，既要能够保证每个时间段的接通率达到最大，又要能够协调好客服人员的休息和工作时间，保证每个客服人员的总工时大致相等，这非常考验管理员的统筹能力，当客服数目变多后，人工排班给管理员带来了巨大挑战。
不管哪种模式，都需要提前预测未来两周的需要服务量（业务上按1~2周的粒度排班），这其实是个标准的时间序列预测问题。结合历史数据，我们可以按照部门-技能组的粒度预测出未来2周的服务量，当然，这种离线的预测只是一种近似，很难精准预测。
对于合作伙伴公司客服的排班，可以抽象为多约束条件下的优化问题，在实际场景中，我们采用了组合优化算法。
3. 水平扩容：预测式应急放班
提前排班很难精确预估服务量，我们不可能提前知道下周一13点25分会出现个代金券问题导致大量用户进线咨询。
对于这种突发性质的流量或者比上班服务量大的流量，我们能不能像调度机器一样，快速水平扩容一批客服来上班。对于社会化的云客服，我们可以做到，比如排队数超过某值时，自动触发云客服的应急放班。通过实践发现云客服从选班到上班一般需要十多分钟时间，如何进一步节省这十多分钟的黄金处理时间？将应急放班升级为预测式应急放班！提前几分钟预测到即将到来的大流量，提前放班。
这里涉及两个模型，一个是服务量实时预测模型，该模型能根据实时数据如会员的操作行为，会员在小蜜的行为，故障场景，并结合历史进线量来综合预测某一技能组未来30分钟每一分钟的进线量。
有了服务量预测数据输入后，应急放班模型就可以结合当前服务会员情况，未来30分钟客服排班情况、会员消耗速度、溢出关系等综合指标，来推断出是否要触发应急放班以及放班的服务量。一旦触发应急放班后，线下通知模块会通过电话、短信等手段来通知合适的客服来上班。
与调度机器不同，我们需要时刻考虑客服感受，为了避免打扰没有上班意愿的客服，我们让客服自主设置是否要接收通知。
4. 负载均衡：溢出、分流
尽管预测式应急放班效果不错，但目前只针对云客服有效，对于SP类这种非选班类的客服怎么办？我们发现，线上排队时，往往是某几个技能组出现大量排队场景，比如商家线爆了，消费者线的客服可能处于空闲状态。如何解决这种忙闲不均问题？一个直观的极端想法就将所有的组变成一个大池子组，通过负载均衡分配让每一个客服都处于繁忙状态，从而达到效率最大化。而事实上并不是所有的技能组之间都能互相承接，这里既要权衡业务，又要线下培训让客服具备多技能。
XSigma提供了技能组相互分流、溢出的配置功能，只要满足触发条件，就能实时分流溢出，解决了以往靠现场管理员手工改客服技能组的痛苦。
对于一些场景而言，技能组间的溢出粒度有点粗，比如设置了A技能组排队可以溢出到B技能组，并不是B技能组的每一个客服都能承接A的业务，只有进行了培训的客服才能承接，XSigma同样提供了给客服打技能标签的功能。
5. 垂直扩容：弹性+1
有些业务比较复杂，很难找到其他技能组进行溢出，我们将注意力转到正在上班的客服上。在线客服可以同时服务多个会员，如果一个客服最大服务能力是3，那么他最多同时服务3个会员，这个值由管理员根据客服的历史服务水平来设置。
我们发现尽管很多小二的最大并发能力是相同的，在他们满负荷服务会员时，他们的服务水平有很大不同，他们的忙闲程度也有非常大的差异，为什么？
● 小二本身水平有差异
如下图所示，某技能组的客服最大服务能力都是3，最近一个月这个技能组的客服在同时服务3个会员场景下的平均响应时间分布（平均响应时间正比于客服回复速度），可以看到数据呈一个大致正太分布，说明小二服务水平有差异。
● 场景不同
举个例子，A和B两个客服最大服务能力都是5，同样都在处理5个会员，但是A的5个会员差不多都到会话结束尾声了，B的5个会员都才刚刚开始，这个例子下A和B两个客服当下的忙闲程度明显不同。
既然小二的服务水平有差别，实际场景千差万别，那能不能在技能组排队时刻让那些有余力的小二突破最大服务上限？
XSigma提供了两种策略来让小二突破服务上限。
1）主动+1模式
当技能组达到触发条件时，XSigma会主动点亮客服工作台的+1按钮（如下图红框所示），客服可以点击来主动增加一个会员进线，这种方式相当于是将扩容权利交给客服，因为只有客服自己知道目前忙不忙。
2）强制+1模式
如果某些技能组是强管控类型，可以选择开启强制+1模式，XSigma会结合数据自动选择一些合适的客服来突破服务能力上限，比如他之前最大服务能力是5，我们会同时让他服务6个会员。
6. 削峰填谷：预约回拨
对于热线来说，小二不可能同时接好几个电话，而且业务上可承接的线下客服也少，这时候如果出现大面积排队怎么办？
通过数据分析发现，很多技能组在一天内的繁忙度在波动，有高峰也有低峰，下图所示展示了某技能组的剩余服务数，可以看到有两个繁忙时间段，10~13点，17~21点，这两个时间段的空闲服务数很多时候都是0，而其它时间段相对比较空闲，如果能将这些繁忙时间段的进线量腾挪到非繁忙时间段，这样就能大大提升客服的人员利用率，也能避免客户排队的烦恼。
怎么做呢？通过预约回拨，将当下服务转变为未来服务。如下图所示，主要有两个模块构成。
1）预约触发器。用户电话进来后，预约触发器会根据技能组的繁忙情况，来判定是否要触发预约；
2）回拨触发器。采用系统主动外呼模式，一旦发现技能组繁忙度处于低峰，就会触发回拨，只要用户电话被接通，就会以高优先级进入到分配环节，从而让客服人员在有效的工作时间内都在真正的与客户通话。
7. 最优分配
调度的目标是：“提升客服资源的利用率和服务水平，用更少的客服资源获得更佳的用户体验”。前面这些策略的关注点更多是在提升客服资源利用率上，有没有什么策略能提升用户的满意度？我们从分配这一环节入手。
本质上我们要解决的是“会员（任务）-客服匹配优化”问题。在传统模式下，分配就是从某技能组的排队队列中找到一个等待时间最长的会员，然后再找一个该技能组下最空闲的客服完成匹配。这种公平分配方式考虑维度单一，未能在全局层面上掌握和调度分配有关的会员、客服、问题等各类信息。
匹配优化问题其实是二部图匹配问题，如图所示，在某一时刻，我们可以得到某技能组下未分配的客户（任务）以及具备剩余服务能力的客服，如果能知道每个任务与每个客服之间的匹配概率，那就可以通过稳定婚姻算法找到最佳匹配。
如何求得任务与客服之间的匹配概率？抽象为分类回归问题，核心在于构建大量样本（x1,x2,x3,…,xn）(y)。针对一通历史会话任务，y是客户评分或会话时长（目标可选），而x既包含了客服特征如过去30天的满意度、平均响应时间等等离线指标，以及客服当前会话的服务会员数、最大会员数等实时指标，也包含了任务的特征，如问题类型、等待时间、订单编号、重复咨询次数等等。样本有了后，下面就是选择分类算法进行训练，最终我们采用了CNN。
在迭代过程中发现，模型会将流量更多分配给好的客服，而指标相对较差的客服的流量则变少，为了避免少量客服上班接不到客反弹的情景，我们将公平性的指标引入到模型中。
8. 智能培训：大黄机器人
通过最优分配来提升满意度的一个重要原因是将流量更多分给了能力强水平高的客服，而这部分客服的占比不高，为什么？为了应对11、12这两个特殊月份的高流量，业务团队要招募培训大量的云客服。这些新手涌入必然会对满意度带来影响，换句话说，如果要想进一步提升满意度指标，必须提升新手客服的服务水平。
对于新手，在上岗前提升他们水平的唯一方式就是培训，传统的培训都是通过线下让云客服看视频等学习资料，然后进行笔试，通过后就直接上岗，带来的问题是很多新客服对平台的工具、解决方案都不熟悉就直接服务会员，会员体感较差。
对比练车场景，我们发现练车有科目1、科目2、科目3等不同流程，科目1学习理论，科目2和科目3实战模拟，如果我们引入这种实战模拟就能大大提升新客服的服务水平。
我们创新的提出了使用机器人（大黄）来培训客服这一全新的客服培训模式（已申请专利）。新客服在培训租户里，通过点击大黄头像，会产生一通非常真实的模拟会话，通过和会员聊天，不断学习平台工具使用，不断提升解决客户问题能力。一旦会话结束后，大黄机器人会对这通会话进行评价，并会告知应该使用某种具体的解决方案来回答用户问题。
对于新客服，目前必须完成大黄80通会话后才能上岗，整个财年培训客服几万人，服务会话量达到几百万轮次。abtest显示通过大黄试岗的客服不管在满意度、不满意、平均响应时间、平均服务时长等各项指标上都有非常明显提升。
9. 统一的调度中心
从上面可以看到我们的客服调度策略多且复杂，每种策略都起到了一定提升客服资源的利用率和服务水平的作用。现在的问题来了，不同场景下这么多策略如何选择？比如现在技能组A突然排队100个会员，这个时候是直接溢出到其他技能组，还是触发主动+1或触发应急放班呢？这里需要一个大脑来做决策。
如何让这个大脑适用于各种复杂的业务场景是难点。我们平台目前租户就有几十个，仅淘系这一个租户就划分了几十个客服部门，每个部门下又细分了一系列技能组，不同部门间业务场景不同。在严重缺乏历史数据积累情况下，很难直接通过训练一个决策模型来适应多种业务。于是我们的思路就转换为直接利用现场管理员的专家知识，让他们将决策逻辑沉淀为一条条的规则。
目前平台上已经配置了上万条规则，每天生效的规则也有几千条，这些数据的沉淀让我们可以通过智能优化技术实现真正的智能调度决策大脑。
10. 调度监控大屏
客服调度策略繁多、逻辑复杂，调度结果会切实影响整个环节参与者的感受，因此我们搭建了XSigma调度大屏，方便大家理解。在实践过程中发现调度大屏能建立起使用方对调度系统的信任感，降低开发人员和管理员发现、定位并解决系统问题的成本。举个例子，管理员在XSigma平台上设置一些规则，比如A技能组排队数>=1触发溢出到B技能组，设置完后他心里没底，他也不知道设置的逻辑是否生效，往往会让开发同学再次确定下有没有生效，而现在有了可视化调度大屏，既能观察到各个技能组的服务量、剩余服务量等实时监控数据，也能看到实时调度各种策略生效的过程，以及每天调度的实时汇总明细数据。
11. 仿真演练
在调度优化场景中，如何评估调度系统的好坏至关重要。有没有一种手段能评估XSigma是否能适应各种场景？能提前证明在双11这种大促期间也能顺畅的调度？能及时发现调度过程中出现的问题？这不仅是我们也是业务同学迫切需要知道的。
仔细思考发现，要解决的问题和技术的全链路压测要解决的问题很相似，我们要做的其实是业务上的全链路压测，于是我们搭建了客服调度的仿真演练系统。
基于大黄机器人，我们已经能模拟会员进线，通过定制改造，机器人可以制造各种主题类型的题目，比如双十一类型场景等。在此基础上，结合业务同学的预估量，可以设置出各个技能组的进线量。
在双十一之前，业务同学使用这套演练系统大规模演练过两次，由于是基于真实服务量进行演练，而不是以前的口头相传的方式，让调度上下游每一个参与的同学都有压力感。在演练过程中发现的一些问题改进后，大大提升了我们应对大促突发流量的信心。
12. 小结
XSigma智能客服调度系统采用自动化配置、机器学习等技术，将复杂的调度问题分层处理，并在日益增长的会员任务基础上，不断精细化调度模型依赖的状态预估数值，不断提高调度模型的多目标规划能力，同时通过大量运用平台可视化技术，以实时、图表化的方式将系统运行状态呈现出来，最终在客服效率和用户体验时间上得到优化效果。该系统上线后，相比于往年，服务不可用时长这一业务核心指标直接下降98%。
本文作者：力君
本文来自云栖社区合作伙伴“阿里技术”，如需转载请联系原作者。