CTI论坛(ctiforum.com)3月10日消息(编译/老秦): 向全面的云联络中心骨干飞跃更多的是一种承诺,而不是一种成就。
![](http://www.ctiforum.com/uploadfile/2022/0310/20220310090528335.jpg)
Sytel的一个常见问题是:"联络中心即服务 (CCaaS) 已经到来,但我应该在什么时候计划摆脱传统系统并采用它?"
我们尝试使用这样的问题作为教学时刻。CCaaS已经到来。但在大多数情况下,可用的服务产品提供的服务很简单。例如,如果您想要基本的呼叫和媒体队列,CCaaS可以帮助您实现这一目标。如果您想开展 IVR/聊天机器人活动,您也可以这样做。
如果您想要一个包含拨号器和社交媒体的企业级混合自动呼叫分配 (ACD),那么从云中提供与您的业务流程无缝集成的多会话和多渠道是一个更大的问题。大多数主要品牌的CCaaS产品(我们谈论的是真正的CCaaS产品,而不是安装在 Amazon Web Services (AWS) 中的一些虚拟机上的传统 ACD)都遵循无状态微服务模式。这样的产品可以实现线性扩展,但代价是没有做企业解决方案所期望的一切。
是否有可行的企业联络中心即服务(CCaaS)解决方案?
近二十年来,Sytel一直在努力解决这个问题。我们很早就与互联网服务提供商CosmoCom等合作伙伴进行云合作,并且从那以后在这个问题上花费了很多年的时间。
仅有微服务设计是不够的;您必须查看所有内容如何组合和部署,解决方案的哪些部分必须位于核心平台中,以及为业务集成公开了哪些接口。以下是我们研究的惊人结论:
- ACD 不能完成企业 ACD 所期望的所有事情并且仍然是无状态的。为简单起见,您必须使用演员模型,但构成 ACD/拨号器"大脑"的演员必须在处理中。因此,一个成熟的 ACD 必须是有状态的。这与云思维背道而驰,并对弹性和规模提出了一些挑战。解决这个问题需要不同的方法。
- 实时服务水平协议 (SLA) 遵守和负载平衡必须成为核心 ACD 的一部分。在公共云上实时连接劳动力优化是不切实际的。
- 您必须将多会话行为设计到 ACD 中。拥有一个座席桌面环境非常容易,它允许您在处理语音的同时与聊天和电子邮件进行交互。但是,如果您没有一种正交方法来管理所有媒体类型的多会话作为 ACD 的一部分,那么这将否定进行自动混合和服务级别管理的能力。
- 云 ACD 不仅需要完成成熟 ACD 解决方案所做的一切,而且还必须处理具有不同行为的多会话座席和媒体。由于这种复杂程度,主管不再能够实时管理资源。 ACD 必须发展成为自动会话分发器 (ASD)。
- 数据密集型操作(如列表管理和客户数据集成)需要采用不同的云正统方法。您必须在设计中包含缓存和 TP 监视器行为。该设计必须适用于云中保存的客户数据和企业数据中心。
- API需要围绕业务集成接触点进行设计,并在这些集成脱机或没有及时响应时继续运行。
- 编排需要智能化,以考虑构成全方位服务CCaaS产品的所有不同组件的通信和处理负载要求。租户门户是本机 Web 是不够的。房东和系统管理也必须是本地网络。
尽管如此,对这个问题的简短回答是"是的,有一个可行的企业CCaaS解决方案。"Sytel的第一个全球企业客户于 2020 年使用我们的云平台上线,并在 42 个国家/地区推出,而且还在不断增加。此次推出是在许多小型(300-2000 个并发座席)CCaaS提供商的成功部署以及这给我们公司带来的学习经验的基础上进行的。
自动化是成功的关键,这意味着融合 ASD 提供的所有媒体服务。这种组合可确保无论您的工作负载是什么形状,ASD 都能尽最大可能保持 SLA 并提供最大的人工座席利用率。自动化的好处是主管可以花时间管理和指导他们的团队以提高输出质量,而不是忙于分配座席。
作为最后的想法,也许要问任何CCaaS提供商的问题是"您的企业客户是否使用您的云产品来端到端地满足他们的联络中心要求?"许多企业客户使用CCaaS为短期项目提供单点解决方案,但向全面的云联络中心骨干的飞跃仍然是一个承诺而不是成就!
声明:版权所有 非合作媒体谢绝转载
作者:Sytel公司Michael McKinlay
原文网址: