CTI論壇(ctiforum.com)（編譯/老秦）： 很容易讓人誤以為您可以使用基本的云自動呼叫分配 (ACD) 服務來滿足企業(yè)或其他大規(guī)模需求。畢竟，云承諾“它只是工作”和“它只是擴展”。
注冊這樣的服務和調試隊列很容易；為隊列命名，映射一個或兩個直撥內線 (DDI)，分配座席成員/技能，然后完成工作。
但仔細觀察，你會開始看到挑戰(zhàn)：
- 云 ACD 是否會管理您所有工作負載的服務水平協(xié)議 (SLA)？
- 是否有將座席從外向撤出以滿足內向需求的混合規(guī)則？
- 是否有針對多會話座席的行為規(guī)則？
它歸結為幾乎所有具有無狀態(tài)設計的云 ACD（直到現在，這仍然是云服務的圣杯）。令人不安的事實是，為了支持企業(yè) ACD 功能，云設計必須是有狀態(tài)的。讓我們分解傳統(tǒng)的企業(yè) ACD 來看看原因：
設計挑戰(zhàn)
至少需要 5 層工作，并且它們的復雜性會增加：
1、隊列機制
制作一個基本的呼叫排隊系統(tǒng)并不需要太多努力。使該排隊系統(tǒng)無狀態(tài)將涉及對隊列中呼叫的引用的一些持久存儲以及查詢具有正確技能的座席是否可用的方法。
但是這種設計是有代價的；每次隊列需要決定將呼叫連接到座席時，它必須收集狀態(tài)信息（隊列中的呼叫、可用座席和技能水平）并做出決定。
如果您使用狀態(tài)緩存引擎，此過程每次可能需要幾十毫秒。對于一個簡單的用例，體積不是問題。
2、隊列相互依賴
接下來，考慮座席將具備服務許多隊列的技能。在我們干凈的云模型中，隊列是相互獨立的。但在現實生活中，一個人采取的行動會從另一個人的可用座席池中刪除座席。
排隊系統(tǒng)現在必須在所有隊列中以串行方式做出決定。在更大規(guī)模的聯(lián)絡中心，“幾十毫秒”現在成為一個問題。
3、每個隊列的 SLA
必須針對 SLA 管理所有隊列，這意味著必須調整隊列與座席配對呼叫的順序以保持 SLA 目標。在無狀態(tài)模型中，這意味著“隊列管理器”每秒會多次輪詢狀態(tài)的當前快照。
4、呼入/外呼混合
這就是無狀態(tài)模型變得不可行的地方。混合需要實時監(jiān)控入站需求、座席技能和現有請求，以便在呼入/外呼工作負載之間進行推送和拉取。
5、多渠道、多會話
座席可以跨多個會話實時執(zhí)行聊天，并且這些會話交互。座席可能也處理語音，也可能不處理，而且會話之間也存在交互。
這種設計復雜性對于交付自動化決策并使服務易于訂閱者使用的 ACD 是必要的。如果您有 1000 個座席處理呼叫，則 ACD 每秒最多會做出 5000 個狀態(tài)驅動的處理決策。
那么，如何制作可用作云服務的企業(yè) ACD？
為成功而設計
簡短的回答是你必須有一個有狀態(tài)的 ACD 引擎來完成你需要的一切。忘記我們前面提到的圣杯吧。
將其作為云服務開發(fā)和交付需要紀律。 ACD 引擎必須盡可能小（即每個租戶一個 ACD 實例）和可生存的房東架構。
其他基本設計要求是：
1、服務必須“只做一項工作”。由于 ACD 的“一項工作”非常復雜，因此 ACD 決策（以及傳達這些決策）業(yè)務之外的任何內容都不屬于 ACD。
2、應用程序編程接口 (API) 必須是故障友好的。由于上述第一個要求，ACD 是一個使用狀態(tài)并通過已發(fā)布協(xié)議 (API) 傳遞狀態(tài)決策的過程。這意味著一切都是請求，而不是命令。
3、必須為多路復用和服務發(fā)現設計協(xié)議和路由機制。應用程序不必知道或關心它與之交談的事物在哪里或它們有多少。應用程序使用的框架應該將其隱藏起來。
那么，云中全功能 ACD 的價格是多少？供應商面臨的一些挑戰(zhàn)與無狀態(tài)密切相關。
聲明：版權所有 非合作媒體謝絕轉載
原文網址：https://www.nojitter.com/cloud-communications/enterprise-acd-cloud-service-facing-challenge
