CTI论坛(ctiforum.com)（编译/老秦）： 很容易让人误以为您可以使用基本的云自动呼叫分配 (ACD) 服务来满足企业或其他大规模需求。毕竟，云承诺“它只是工作”和“它只是扩展”。
注册这样的服务和调试队列很容易；为队列命名，映射一个或两个直拨内线 (DDI)，分配座席成员/技能，然后完成工作。
但仔细观察，你会开始看到挑战：
- 云 ACD 是否会管理您所有工作负载的服务水平协议 (SLA)？
- 是否有将座席从外向撤出以满足内向需求的混合规则？
- 是否有针对多会话座席的行为规则？
它归结为几乎所有具有无状态设计的云 ACD（直到现在，这仍然是云服务的圣杯）。令人不安的事实是，为了支持企业 ACD 功能，云设计必须是有状态的。让我们分解传统的企业 ACD 来看看原因：
设计挑战
至少需要 5 层工作，并且它们的复杂性会增加：
1、队列机制
制作一个基本的呼叫排队系统并不需要太多努力。使该排队系统无状态将涉及对队列中呼叫的引用的一些持久存储以及查询具有正确技能的座席是否可用的方法。
但是这种设计是有代价的；每次队列需要决定将呼叫连接到座席时，它必须收集状态信息（队列中的呼叫、可用座席和技能水平）并做出决定。
如果您使用状态缓存引擎，此过程每次可能需要几十毫秒。对于一个简单的用例，体积不是问题。
2、队列相互依赖
接下来，考虑座席将具备服务许多队列的技能。在我们干净的云模型中，队列是相互独立的。但在现实生活中，一个人采取的行动会从另一个人的可用座席池中删除座席。
排队系统现在必须在所有队列中以串行方式做出决定。在更大规模的联络中心，“几十毫秒”现在成为一个问题。
3、每个队列的 SLA
必须针对 SLA 管理所有队列，这意味着必须调整队列与座席配对呼叫的顺序以保持 SLA 目标。在无状态模型中，这意味着“队列管理器”每秒会多次轮询状态的当前快照。
4、呼入/外呼混合
这就是无状态模型变得不可行的地方。混合需要实时监控入站需求、座席技能和现有请求，以便在呼入/外呼工作负载之间进行推送和拉取。
5、多渠道、多会话
座席可以跨多个会话实时执行聊天，并且这些会话交互。座席可能也处理语音，也可能不处理，而且会话之间也存在交互。
这种设计复杂性对于交付自动化决策并使服务易于订阅者使用的 ACD 是必要的。如果您有 1000 个座席处理呼叫，则 ACD 每秒最多会做出 5000 个状态驱动的处理决策。
那么，如何制作可用作云服务的企业 ACD？
为成功而设计
简短的回答是你必须有一个有状态的 ACD 引擎来完成你需要的一切。忘记我们前面提到的圣杯吧。
将其作为云服务开发和交付需要纪律。 ACD 引擎必须尽可能小（即每个租户一个 ACD 实例）和可生存的房东架构。
其他基本设计要求是：
1、服务必须“只做一项工作”。由于 ACD 的“一项工作”非常复杂，因此 ACD 决策（以及传达这些决策）业务之外的任何内容都不属于 ACD。
2、应用程序编程接口 (API) 必须是故障友好的。由于上述第一个要求，ACD 是一个使用状态并通过已发布协议 (API) 传递状态决策的过程。这意味着一切都是请求，而不是命令。
3、必须为多路复用和服务发现设计协议和路由机制。应用程序不必知道或关心它与之交谈的事物在哪里或它们有多少。应用程序使用的框架应该将其隐藏起来。
那么，云中全功能 ACD 的价格是多少？供应商面临的一些挑战与无状态密切相关。
声明：版权所有 非合作媒体谢绝转载
原文网址：https://www.nojitter.com/cloud-communications/enterprise-acd-cloud-service-facing-challenge
