本文主要是介绍马云的蚂蚁金服很牛吧！深度解密背后的智能调度技术如何优化客服中心的资源调配，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
原文地址：https://blog.csdn.net/YMPzUELX3AIAp7Q/article/details/79434520
随着互联网人口红利的逐渐消失，智能手机销量的停滞不前，网民的增长也大幅趋缓，市场已非昔日盛况。但与此同时，过去这一年，用户每日在线时长的增长却已超过30%，甚至超出了网民的增速。只有精耕细作来服务好用户，深度挖掘现有用户的价值，才是“下半场”的正确玩法。
好的服务是互联网产品的根基和命脉。在人工智能浪潮下，已经可以在许多产品中看到智能机器人的影子，越来越多的公司开始尝试通过这种全新的交互形式，来优化或者升级自己的产品，逐步代替人工来解决用户问题，从而降低服务成本。智能机器人的解决率随着专家经验的积累而不断提升，但长尾问题仍普遍存在，用户对人工服务仍有依赖。如今服务已经进化成渠道多样、智能与人工相辅相成的复杂体系。
这套体系如何有效的运转，如何快速而精准的满足用户的个性化诉求，调度能力成为了这背后的关键。智能调度，就是在探索如何结合人工服务与机器人服务来做全局调度，优化客服中心的人员利用率，同时提升用户体验。
智能调度的现状
从服务的发展角度看，客服中心一共经历了三个阶段：第一阶段主要以人工服务为主，领域更多属于一个人力密集型行业，比较依赖人工通过电话、邮件、IM、论坛等沟通工具和渠道来解决问题；第二阶段，主要集中在以IT平台为主的自助服务，通过搜索引擎构建知识库让用户通过搜索来解决问题；到了第三阶段，则是提供以智能化为主的多渠道结合的服务，包括文字机器人、语音机器人、热线服务、在线服务、预约服务、自助服务，等等。
目前智能客服类产品可谓百花齐放，基本都是围绕“呼叫中心 + 智能机器人 + 在线人工对话”的方式来建设，差异化不大。产品定位更多是帮助一家公司能够快速建设服务能力，但是这么做服务质量没法保障，因为服务质量更多是由服务背后的调度能力和运营能力来决定的。现有的客服类产品都比较缺乏对服务的深度建设，所以市场上有很多做服务承接的外包类公司，但却很少听到用户反馈说某个服务产品背后的客户服务做的不错。当前已经有一些大型企业开始投入智能服务建设来替代人工服务诉求，降低成本和优化体验，但很多中小型企业，即使使用了云端智能客服类产品，却仍然无法享受到技术变革带来的红利，主要的原因就在大型企业里有智能化的运营调度类系统和服务运营人员。
痛点分析
蚂蚁金服当下的业务构成比较复杂，既有基于交易订单产生的支付订单类业务，也有基础账户和安全类业务，另外还包括金融领域的存投保消贷以及信用的相关业务。这对服务管控来说是一个很大的挑战。
从用户的角度来看，选择合适的求助渠道，得到满意的服务，尽快解决问题是最直接的诉求；然而实际情况是，目前蚂蚁虽然拥有多样化的接入渠道，但是用户并不了解自己的问题最适合求助哪个渠道，也不了解每个渠道下的繁忙程度，很多时候，用户在排队等待的过程中或者是在某个渠道下没法找到解决的方案就放弃了。
从运营人员的角度来看，如果能有合适的工具能帮助自己随时了解到服务现场的承接情况，快速定位问题并即时做出响应，并能通过数据分析来对历史服务结果进行复盘，进而优化运营策略，是最理想的状态；然而实际情况是，由于业务复杂，很多运营人员的现场决策只能解决服务现场局部承接的优化问题，而没法解决全局的优化问题，同时由于缺乏相应的运营工具，不少运营人员只能依靠经验和人肉盯盘的方式来发现问题，从发现定位到排查解决问题的效率很低。另外由于很难预估服务量，所以很难做好提前排班，一旦流量发生异常，就有可能会导致现场无法正常承接。
从服务人员的角度出发，由于同一通话务有多种承接的方式，所以如何整合机器人、自营客服人员、外包客服人员以及社会化客服人员，提升资源的利用效率，是一个比较难的领域问题。在保证用户满意度的前提下，如果机器能解决问题，却使用人力去承接（即使是外包服务人员），这是一种资源浪费；而如果自营客服人员本身能承接的话务，却因为和外包公司的商务合同没有达成，只能分流给外包客服人员来进行承接，这也是一种资源浪费。
客服领域调度探索
在客户服务现场需要这样一种能力，能够在用户诉求和承接资源之间建立一种动态管控的能力，一种能够提供跨渠道、跨人机、跨主被动的全局服务管控能力，我们将之称为调度大脑。
调度大脑首先应该具备的能力是感知能力，能够尽快捕获到现场出现的承接异常信息，帮助运营人员在最短的时间内定位问题，从而解放他们的生产力，让他们更多的关注如何优化整体的承接策略，更多的思考如何避免现场繁忙，而不是现场出现问题以后再考虑怎么来弥补。
接下来应该具备辅助决策能力，这建立在对现场的全局洞察之上。能够预测时段内的流量，能够明确用户求助更适合通过什么渠道来解决，能够大致判断用户接入渠道后需要等待多长时间才能得到服务，能够了解现场每位客服人员的工作状态，并协助运营人员针对现场实时状态做出合理判断和最优选择。
最后应该具备的是响应能力。对现场有了判断以后，剩下的就是响应执行了，这属于基础能力。繁忙时需要限流和引流，或者增加承接能力；空闲的时候则需要导流，引入新的承接任务。
感知
异常识别
数据的实时监控，是感知体系的基础，它能够透过数据看清现场，能够沉淀可以量化的运营标准，并为后续决策体系的建模提供基础数据。透过数据分析和异常识别，能替代运营人员传统的盯盘模式，自动识别现场发生的异常并同步给运营人员，帮助他们在第一时间了解到现场的准确状况并采取相应的补救措施。
常规的异常可以使用通用的文本分析、类目分析来检测；长尾的异常可以使用人工辅助运营、客服众包等模式来检测，对于周期性的异常则通过定期扫描来检测，突发性的新型异常则采用词频分析来检测。
监控大屏
目前蚂蚁金服客户中心每天有着数百万的机器人求助量以及几十万的话务求助量，现场同时运行着上千条的运营策略和多个调度模型，整体的管理成本非常高，基于这个背景蚂蚁金服建设了整体服务链路的监控大屏。
大屏主要包括了对求助来源、整体服务链路、调度节点、现场定时扫描、服务风险检测、舆情观测、当前咨询热点以及现场人力资源管控等模块，并提供了放大镜功能，能够针对核心调度节点的宏观表象与微观详情进行透析。
决策
决策主要分为三类：渠道决策用来为用户选择最合适的服务承接渠道；承接决策用来保持现场的稳定，让流入的话务能够被顺利的接起，尽量避免呼损的情况发生；资源管理本质上是为了优化现场资源利用率，同时管理好现场庞大的人力资源。服务中心本身拥有很多负责承接话务的客服人员，除此以外还有现场管理人员和众包客服人员，管理成本会比较高，如何发挥客服人员之间的协同效率，以及降低现场管理人员乃至全局的管理成本，是领域性质的难题。
渠道决策
目前业界主流的服务渠道仍然是热线服务、通过IM工具进行在线求助的在线服务，以及通过和对话机器人进行直接交流的自助服务。热线服务中通过多轮按键交互和机器人多轮对话的方式来对用户提出的问题做问题识别从而引导话务派单。在线服务里也主要通过机器人多轮对话的方式来识别用户问题并引导派单。机器人自助服务则是通过用户问题匹配最佳的知识点来推送给用户。
蚂蚁金服提供的则是一种跨渠道的解决方案：当用户到达场景入口以后，首先会根据用户基础信息，尝试在用户当下选择的渠道里解决用户的问题，如果当前渠道不足以解决，再依据承接渠道的繁忙程度、用户咨询的问题所属的类目、用户所问问题在各承接渠道下的解决率、用户的历史求助行为等特征综合建模，为用户推荐当下最优的渠道；并同时给出当前可选的渠道，让用户自主选择，用户选择了自己倾向的渠道以后，系统会同时把用户在前一个渠道里描述的问题透传到新的渠道，这样用户转接到别的渠道以后就不再需要重复描述问题，直接接受客服人员的服务。
例如在蚂蚁金服的客服咨询中，每天都有很多用户来电询问蚂蚁森林的游戏规则，现场决策就会对是否需要将用户引流至机器人自助渠道来解决进行评估；而账户被盗属于高风险的问题，现场决策就会在最短的交互后外露热线人工入口，引导用户直接进入热线人工服务。
承接决策
业务繁忙时提前为每条业务线准备好候补客服队伍，同一块业务能由不同的团队(包括同一个业务线里的不同团队和跨业务线的团队)来承接。接下来会对候补客服的助接能力进行评估打分。当现场出现繁忙的时候，可以通过实时调度在保证候补团队自身承接没问题的前提下，将承接出现紧张状况的团队的话务流量按照助接能力得分的高低分配给当下最适合助接的候补客服来进行承接。
如果引入候补客服助接仍无法缓解现场繁忙的状况，系统会提供预约回呼的服务，将无法承接的话务流量导流到能够保证现场承接的同时还有多余人力的时段来进行回呼。用户接受预约后，在预约回访时段，系统会通过系统双呼自动拉起用户与客服来进行回呼服务。
能够开放的预约名额也是有限的，并不能保证开放预约回呼服务后就能承接溢出的流量。在开放预约以后仍无法缓解现场繁忙状况时，系统会安排有承接能力的运营人员协助承接，同时把通过实时调度引入云客服人员来协助承接做为兜底方案。
首先会结合历史下一时段流量，以30分钟为粒度预测下一时段的流量，并考量预测结果，如果判断未来时段会出现繁忙，会先进行前置调度（比如收紧客服人员小休策略、将就餐时段适度推迟、动态调整在线客服的在线服务并发数等）。
考虑到客服人员每天的服务状态可能出现异常，系统引入了健康度模型（主要参考整体服务流程、客服服务态度、现场行为【小休，迟到，早退，缺勤等】、客服产能以及智能质检和用户评价等相关特征）来对客服做综合评估，如果存在不健康的状态，那么现场主管需要对其保持关注或做相关提醒。当现场出现繁忙时，针对热线坐席控制小休，针对在线坐席，控制客服人员的在线服务并发数。首先评估好人力缺口，然后根据缺口值来判断收紧多少位热线客服的小休策略与延迟就餐，提高多少位在线客服的在线服务并发数；当现场回归到空闲时，再放开管控策略，这样就能最大程度的保障现场的承接，当前在蚂蚁的业务场景下已经实现了60%左右比例的自动决策。
执行
当现场做出决策以后，剩下的就是响应执行，这也属于基础能力。这里介绍几种引导流量的方法。整体拉起采用了系统双呼的方案，首先将繁忙时段无法承接的话务通过预约的方式导流到流量波谷区，到了预约时间会通过系统自动拉起空闲客服和用户来完成预约回访功能。
削峰填谷
当流量超过现场人力承接的峰值（波峰）时，系统通过引入了资源预估模型来实时评估产能不饱和的时段与空闲名额（波谷），并将其提供给预约准入模型。预约准入模型会根据用户接受度来进行打分，并对得分高的用户开放预约入口。用户接受预约后，在预约回访时段，系统会通过系统双呼自动拉起用户与客服来进行回呼服务。这样做能有效降低呼损，稳定时段接通率。
资源预估模型建模依赖了当前排班和历史排班数据、当前流量和历史流量数据、日期数据等特征。预约准入模型建模则依赖了问题画像、历史求助轨迹、求助偏好等特征。
见缝插针
针对呼损类的场景：
在现场人力出现空闲的时候，即流量低谷期，可以把当天较早时候产生呼损的高价值用户未接通的话务自动的分配给当前空闲的承接资源进行主动回访。
当下机器人的服务能力还不足以解决所有的问题，当机器人服务不到位的时候，会直接面临用户流失的风险。这时候可以透过数据分析圈出这部分服务不到位的人群，利用主动回访来进行承接，可以避免用户的流失。
当用户在使用支付宝下的各类产品拥有不好体验的时候，经常会在各类社交媒体上发声，有时候还会导致舆情事件，针对这种情况，可以通过空闲的资源承接一些社交媒体的官方账号的解答和回应工作。
当用户通过支付宝钱包转账时转错款的时候，可以通过系统双呼拉起客服和错误的收款人来进行沟通调解，并在沟通完成后再通过双呼拉起客服人员和转错款的用户来同步沟通结果。这个场景引入系统双呼之前只能通过人肉手动操作的方式来处理，需要1天时间才能处理完，目前通过见缝插针的方式来解决，前后只需要1小时。目前已经使用同样的方式完成了一系列类似的复杂场景的外呼工作。
后续规划
目前蚂蚁金服在智能调度领域已经做了一些探索，希望通过后续的持续投入，来创造一些新的服务模式，建设能提供7x24小时服务的智能调度机器人。
这篇关于马云的蚂蚁金服很牛吧！深度解密背后的智能调度技术如何优化客服中心的资源调配的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
