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