携程：上万坐席呼叫中心异地双活架构及系统设计

另外两种状态就是在登录过程中发现问题,如果是CTI出现问题,则会直接向异地进行登录请求,如果是统一登录平台出现了问题,我们会进行二次确认,如果二次确认登录不成功的话,则会向异地再发起一个请求,进行异地登录.

技术特点：

• 支持故障情况下在线座席自动双活切换
• 支持按系统、按地域、按座席技能组等不同维护进行计划内的手工切换
• 支持1000+ 并发在线座席异地双活自动切换

演练效果：

我们当时做了一个演练,这个演练也比较符合Google的一个理念,定期演练并根据演练结果进行修正.在做演练过程中,你会发现计划内目标是否完成的,是否有一些计划外的事情.而在实际演练中也确实发现跟我们计划稍微有点出入,具体数据如下：

后期我们针对演练发现的问题,进行了修复和调整,并在测试环境进行压测验证,最终实现1000+座席自动切换在2分钟内全部完成.

未来

未来的方向,这也是我们公司目前正在做的两个方向

• 客户端全软件化,取消硬件电话限制
• 客户端移动化,任意地点可接入

客户端全软件化,其实现在的很多的都已经全软化的,全部在软件上实现,这个从技术上我们在尝试,而且也做demo,之所以我们这边并没有全部推推广,也是跟我们的公司的战略有关.

现在我们客户端几乎是全部是虚拟云桌面,运行在后台的虚机上面,如果我们的语音功能在虚机上运行的话,我的后台配置要求高,成本也会比较高.当然如果运行在普通PC机上,我们是可以采用全软化的方式,这个就不会存在我们前面所说的一些瓶颈限定.

还有就是客户端移动化,我们现在也做了一些尝试,我们自己开发了一个APP,座席可在任意地点接入,就可以登录到系统里面去.只是因业务发展的需求做了一些业务的分类,目前只用于外呼.对于呼入,我们现在还没有去应用,呼入会涉及到一些话务分配的问题,分配到哪个座席,我们要解决他的状态,这些是一个难点,所以我们现在还没去规划.

但对于外呼业务的话,由于主动权在我们手里,也无严格的分配话务要求,任何一地点都可以接入,这个可以尝试,也是在未来的发展方向,当然可能其他厂商或者其他的公司也有一些不同的接入方式,大家可以讨论一下.

我今天主要是讲一些针对我们携程自身接地气的一些技术实现,也是跟业务需求做的一些开发和尝试.我今天就讲这么多,有什么问题大家可以现场问一下.

四、提问环节

Q1：

我问一下像呼叫中心这个全软化方向,现在你们有没有实际的案例或者实际的可用的解决方案是全软件化的?

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!