本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Amazon Connect 工作負載中的卓越營運
操作效能包括可讓您執行和監控系統以實現商業價值，以及持續改善支援流程與程序。本節包含設計原則、最佳實務以及有關 Amazon Connect 工作負載卓越營運的問題。
## 準備
請考慮以下幾個方面來準備 Amazon Connect 工作負載。
### AWS 帳戶
透過 AWS Organizations，您可以為開發、預備和品質保證環境的每個層級設定多個 AWS 帳戶。這可讓您在 AWS上隨著工作負載的增長和擴展，集中管理您的環境。無論您是成長中的新創公司還是大型企業，Organizations 都能協助您集中管理帳單、控制存取、合規和安全性，以及跨 AWS 帳戶共用資源。這是使用 AWS 服務以及雲端採用架構的起點。
### 區域選擇
Amazon Connect 區域選擇取決於資料控管需求、使用案例、各區域可用服務，以及與客服人員、聯絡人和外部轉接端點地理位置有關的延遲。
### 電話語音
+ **電話號碼移植**盡可能在待定的上線日期之前提交移植請求。
移植關鍵工作負載的電話號碼時，請在上線日期前幾個月將所有需求和使用案例資訊包括在聲明/移植號碼中。包括要求即時切換支援、切換之前、期間和之後的通訊、監視，以及任何您使用案例特定的其他內容。
如需移轉您電話號碼的詳細資訊，請參閱 [將目前的電話號碼移轉至 Amazon Connect](port-phone-number.md)。
+ 美國**電信業者多樣性**，您應該針對美國的免付費電話號碼使用 Amazon Connect 電話服務，讓您以主動式的方式將免費流量路由到多個供應商，而且無需額外付費。在將傳入流量轉送至 Amazon Connect 電話號碼的情況下，您應該要求跨多個電話語音提供者的備援 DID 或免付費電話號碼。如果您要在美國境外取得或移植多個 DID 或免費電話號碼，則應要求將這些號碼請求或移植到各種電話語音供應生，以提高恢復能力。
+ **國際免費電話和高併發 DID** 如果您正在使用現有的免付費國家服務將入站流量重定向到 DID，則應在多個電話供應商之間請求 DID 電話號碼。此組態的一般建議是每個 DID 100 個工作階段，而您的 AWS 解決方案架構師可協助進行容量計算和設定。
+ **測試**徹底測試所有使用案例情境，最好使用與您的客服人員和客戶相同或類似的環境。請務必測試數個傳入和傳出案例的體驗品質、來電者 ID 功能，並測量延遲，以確保其落在您使用案例的可接受範圍內。目標客服人員和客戶環境之間的任何偏差都需要進行測量和計算。如需更多詳細資訊，包括使用案例測試指示和條件，請參閱 [使用聯絡控制面板 (CCP) 診斷故障問題。](troubleshooting.md)。
### 客服人員工作站
Amazon Connect 通話控制面板 (CCP) 具有特定的網路和硬體需求，必須符合這些要求，以確保為您的客服人員和聯絡人提供最高品質的服務：
+ 設定您的網路以供 CCP 使用，並確保您的客服人員硬體符合最低需求。
+ 請確定您已在與客服人員相同的網路區段上使用 Amazon Connect Check Amazon Connectivity Tool，以確認您的網路和環境已正確設定以供 CCP 使用。
+ 計算客服人員和聯絡人較遠的地理位置上所需的 PSTN 延遲
+ 檢閱 [使用聯絡控制面板 (CCP) 診斷故障問題。](troubleshooting.md) 部分以建立執行手冊和程序手冊，供您的客服人員和主管在遇到問題時遵循。
+ 為您的客服人員工作站設定監控，並考慮監控通話品質的合作夥伴解決方案。監視客服人員工作站的目標應該是能夠識別任何潛在網路和資源競爭的來源。例如，假設客服人員的軟體電話網路連線路徑到 Amazon Connect：
![\[客服人員工作站監控。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/architecture/agentworkstation-oe.png)
如果沒有在本機 LAN/WAN AWS、路徑和客服人員工作站層級設定監控，很難且通常無法判斷語音品質問題是否來自客服人員的工作站、其私有 LAN/WAN、ISP AWS或聯絡人本身。主動設定日誌和提醒機制，對於判斷根本原因和最佳化您的語音品質環境至關重要。
### 設定您現有的目錄
如果您已經使用 Directory Service 目錄來管理使用者，則可以使用相同的目錄來管理 Amazon Connect 中的使用者帳戶。這必須在您建立 Amazon Connect 執行個體時決定和設定。建立執行個體後，您所選的身分選項就無法變更。例如，如果您決定變更為執行個體啟用單一登入 (SSO) 的目錄，您可以刪除執行個體再建立新的執行個體。刪除執行個體時，會失去所有組態設定和指標資料。
### Service Quotas
檢閱工作負載中涉及的每個服務的預設 Service Quotas，以及 Amazon Connect 的預設 Service Quotas 和請求增加 (如適用)。請求增加 Amazon Connect 時，請務必使用預期值，無需新增額外的波動。當您提出請求時，系統會自動考慮波動。
### AWS 企業支援
AWS 企業支援建議用於業務和/或關鍵任務工作負載 AWS。使用 AWS 解決方案架構的企業支援和 Well-Architected 檢閱，都需要滿足 Amazon Connect 服務水準協議 (SLA) 的品質。
### AWS 架構良好的審核
在將任何遷移或實作到 Amazon Connect 之前，請使用 AWS Well-Architected Framework 卓越營運，遵循我們的最佳實務。架構可為您提供一致的方法來評估架構並實作設計，這些架構將根據五大支柱 (營運卓越性、安全性、可靠性、效能效率和成本最佳化) 進行擴展。我們也建議使用 AWS Enterprise Support 來處理業務和關鍵任務工作負載 AWS。企業支援和 Well-Architected Review 與您的 AWS 解決方案架構師都必須符合 Amazon Connect 服務水準協議的資格。
## 操作
請考慮以下幾個方面來操作 Amazon Connect 工作負載。
### 日誌記錄和監控
請參閱 [使用 CloudWatch 監控 Amazon Connect 執行個體](monitoring-cloudwatch.md) 和 [使用 記錄 Amazon Connect API 呼叫 AWS CloudTrail](logging-using-cloudtrail.md)。
### 聯絡屬性
Amazon Connect 可讓您動態設定和參考流程中的聯絡屬性，為聯絡建立動態和個人化體驗、建立功能強大的自助式服務應用程式、資料驅動的 IVR、與其他 AWS 服務的整合、簡化電話號碼管理，並允許自訂即時和歷史報告與分析。以下是您可以遵循的最佳做法和注意事項，以降低複雜性、防止資料遺失，以及確保聯絡擁有一致的體驗品質。
請注意下列注意事項：
+ 資料大小 – 為防止截斷，您可以在設定聯絡屬性區塊設定聯絡屬性的大小限制，會根據所使用的字元集、編碼和語言而有所不同。雖然聯絡通常僅需少部分資料即可完成，但仍有可能超過此限制，截斷任何超過 32KB 大小的屬性集。
+ 敏感資料 – 請注意，如果設定、查詢和參照的任何屬性是敏感資料，或是屬於任何監管準則，請確保資料已根據您的使用案例進行適當處理。
+ 資料持續性 – 使用設定聯絡屬性區塊設定的任何屬性都會包含在聯絡的聯絡記錄中，並且可使用 Streams API 的任何自訂客服人員桌面彈出畫面。只要在流程中參照屬性並啟用流程的記錄功能，該屬性的名稱和值都會記錄到 Amazon CloudWatch。
**最佳實務**
+ 監控用量 – 當您實作新功能、啟動新業務單位以及對現有流程進行迭代時，請在聯絡搜尋中查詢目前的屬性使用情況、將屬性複製到文字編輯器、新增屬性，並確保不會超過 32KB 大小限制。請務必考慮可變長度欄位，例如，名字和姓氏，並確保即使在欄位中使用了最大空間，仍然低於 32KB 的大小限制。
+ 清理 – 如果不需要資料持續性，您可以使用相同名稱和空白值設定屬性，以防止資料儲存到聯絡記錄，或使用 [Amazon Connect Streams](https://github.com/aws/amazon-connect-streams) API 將快彈出畫面傳遞給客服人員，同時釋放聯絡記錄資料以其他方式使用的位元組資料。
+ 敏感資料 – 使用 **儲存客戶輸入** 區塊從您的聯絡收集敏感的 DTMF 輸入，並使用封套加密來保護原始資料和用於加密的資料金鑰。將敏感資料儲存在需要持續性的個別資料庫中，使用 **設定記錄行為** 流程區塊在，參考敏感資訊時停用記錄，以及使用先前概述的 **設定聯絡屬性** 區塊清理方法移除、清理或模糊敏感資料。如需詳細資訊，請參閱[Amazon Connect 中的合規驗證](compliance-validation.md)。
### 電話語音
在美國，盡可能使用免付費電話號碼，以便在多個電信業者之間進行負載平衡，以獲得額外的路線和電信業者備援。相較於由單一電信業者管理的 DID 電話號碼相比，這也有助於減少解析時間。在使用 DID 的情況下，多個電信業者之間進行負載平衡，可用時，也可以提高可靠性。請確定您已適當處理流程中的所有錯誤路徑，並實作位於 [使用聯絡控制面板 (CCP) 診斷故障問題。](troubleshooting.md) 中的最佳做法、需求和建議。
如果您要將現有電話語音供應商的電話號碼轉接至 Amazon Connect，請確保運營團隊定義並充分理解將轉接目的地變更為備用 DID/免費電話號碼或以其他方式刪除轉寄的流程。確保您擁有專門用於生產準備程度評估、電話號碼移植和轉接程序的執行手冊和程序手冊，以及疑難排解從現有電話語音供應商轉接來電時可能出現的音訊問題。您也需要一個讓您營運團隊可以遵循的可重複程序，以判斷這些音訊問題是來自 Amazon Connect 還是您現有的電話語音供應商。
### Amazon Connect API
Amazon Connect 限流配額是依照帳戶，而不是依照執行個體。使用 Amazon Connect API 時，您應該考慮下列最佳實務：
#### 實作快取/佇列解決方案
為了減少 API 資料查詢的額外費用並避限流，您可以使用 Amazon DynamoDB 等中繼資料庫來存放 API 呼叫結果，而不必從 API 資料感興趣的所有端點呼叫 API。例如，下圖表示使用來自需要使用此資訊的多個來源的 Amazon Connect 指標 API：
![\[實作快取和佇列解決方案。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/architecture/amazonconnectapis-oe.png)
您可以讓單一 AWS Lambda 函數將所有有趣的資料寫入 Amazon DynamoDB，而不是擁有個別的函數，每個 AWS Lambda 函數都有自己的輪詢需求。不是讓每個端點直接前往 API 來擷取資料，而是指向 DynamoDB，如下圖所示：
![\[此圖顯示指向 DynamoDB (而非從 API 擷取資料) 的端點。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/architecture/amazonconnectapis2-oe.png)
此架構可讓您視需要變更輪詢間隔並新增端點，而不必擔心超出 Service Quotas，讓您能夠擴展至資料庫解決方案所支援的多個同時連線。您可以使用這個相同的概念來查詢 Amazon Connect 的任何即時資料饋送。對於需要執行 API 動作的情況，例如傳出 API 呼叫，您可以搭配 Amazon Simple Queue Service 使用 AWS Lambda 搭配 SQS 來將 API 請求排入佇列。
#### 指數退避和重試策略
您可能會遇到超過 API 限流限制的情況。當 API 呼叫失敗，而且在未實作快取或佇列解決方案的情況下，重複重試或直接從多個並行端點進行時，就可能會發生這種情況。為了避免超出您的服務配額並影響下游程序，您應該考慮在 AWS Lambda 函數中結合快取和佇列使用指數退避和重試策略。
### 變更管理
將工作負載移至 Amazon Connect 的兩個主要驅動因素是靈活性和上市速度。為了確保卓越營運而不犧牲靈活性，請遵循下列最佳實務：
+ **模組化流程**：Amazon Connect 中的流程類似於現代應用程式，相較於整體式替代方案，更小、專用的元件可提供更高的彈性、可控性和易於管理。您可以透過 **轉接至流程** 區塊將模組化流程結合為端對端體驗，讓流程變得更小且可重複使用。這種方法可讓您降低實作變更期間的風險，允許您測試單一、較小的變更，而不是對整個體驗進行迴歸測試，而且可以更輕鬆地在測試期間識別和解決流程問題。
+ **儲存庫**：使用聯絡流程匯入/匯出作為變更管理程序的一部分，將所有流程的所有版本備份到您選擇的儲存庫。
+ **按百分比分佈**：為了減少在變更管理期間遇到的風險並為聯絡實驗新體驗，您可以使用 **按百分比分佈** 區塊將流量的子集路由到新流程，同時將其他流量留在原始體驗中。
+ **衡量結果**：資料驅動的決策是成功推動業務進行有意義變化的關鍵。擁有關鍵指標來衡量您的變化是絕對有其必要。對於您正在進行的所有變更，您需要計劃如何衡量成功。例如，如果您正在為聯絡實施自助式服務功能，您希望自助式服務有多少百分比的聯絡才可視為工作負載成功，或者您會使用什麼其他指標衡量成功？
+ **復原**：確保有清晰、明確定義且明確瞭解的程序，以取消對先前狀態指定進行的任何變更。例如，如果您發佈新的流程版本，請確保變更指示包括有關如何復原至先前流程版本的文件。
### 轉接設定檔
了解 Amazon Connect 中的優先順序、延遲和溢位轉接的運作方式，對於提高客服人員生產力、縮短聯絡等待時間以及確保聯絡人的最佳體驗品質至關重要。
### Amazon Connect 中的轉接
Amazon Connect 中的聯絡轉接是透過一系列佇列和轉接組態 (稱為轉接描述檔) 完成。佇列等同於客服人員對該佇列的服務聯絡，所需具備的技能或熟練程度。可以檢視轉接描述檔，您可以根據聯絡的需求設定一組技能
在流程中，您可以提示其他資訊，如果他們需要聯絡客服人員，您可以使用流程設定將其放置在適當的佇列中。在下列範例中，「儲蓄」、「檢查」和「貸款」是個別的佇列或技能，而三個轉接描述檔是唯一的技能組合或技能群組：
![\[依佇列群組進行轉接。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/architecture/routingprofile1.png)
每個各服人員只會根據其技能組合指派至一個轉接描述檔，而許多具有相似技能組合的客服人員可以共用相同的轉接描述檔：
![\[通過技能組合轉接。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/architecture/routingprofile2.png)
每個電話號碼或聊天端點將與一個流程相關聯。流程執行其邏輯，這可能涉及提示客戶提供資訊，以確定聯絡人的需求，並最終將聯絡人轉接到適當的佇列。下圖說明轉接描述檔、佇列及流程如何共同運作，以為聯絡人提供服務：
![\[顯示轉接設定檔、佇列和流程如何搭配運作以處理聯絡的轉接圖。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/architecture/routingprofile3.png)
若要說明如何判斷轉接描述檔的各種佇列、轉接描述檔和客服人員指派，請考慮下列表格：
![\[依佇列群組進行轉接。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/architecture/routingprofile4.png)
在第一行中，您已經確定了自己的技能或佇列。在左欄中，您有客服人員清單，在中間，您已經檢查每個客服人員支援的技能。您可以根據常見技能需求，在客服人員名單中進行分組排序。這有助於將轉接描述檔標記為綠色方塊 (其由兩個佇列組成)，您可以將客服人員指派給這些描述檔。本練習的結果是，您已識別四個轉接描述檔，並相應地將 13 個客服人員指派給它們。
根據前面的表格，需要儲蓄技能之聯絡人的來電，可由三個轉接描述檔 1、2 和 4 中的三組客服人員提供服務，如下圖所示：
![\[依佇列群組進行轉接。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/architecture/routingprofile5.png)
### 優先順序與延遲
使用不同轉接描述檔中的優先順序與延遲組合，您可以建立彈性的轉接策略。
![\[此圖顯示轉接設定檔中建立轉接策略的優先順序和延遲。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/architecture/priorityandelay.png)
上述轉接描述檔範例顯示一組佇列及其各自的優先順序和延遲。數字越低，優先順序越高。必須先處理所有優先順序較高的通話，才能處理優先順序較低的通話。這與最終將根據加權因素處理優先級較低的通話系統有所不同。
您也可以為每個轉接描述檔內的每個佇列新增延遲。進入佇列的任何通話都會在指定佇列的指定延遲期間內保留。即使客服人員有空，通話也會在延遲期間保留。您可以在保留一組客服人員來協助您滿足服務水準協議 (SLA)，但會以其他方式指派給其他任務或佇列。如果在指定的時間段內沒有接聽來電，這些客服人員將有資格接受來自指定佇列的通話。例如，請考量下圖：
![\[顯示 Savings 佇列將通話轉接給有空客服人員的圖表。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/architecture/priorityandelay2.png)
此圖表顯示 30 秒的 SLA。進入 Savings 佇列的通話。Savings 佇列會立即在 Savings 轉接描述檔中尋找客服人員，因為佇列的描述檔設定為 0 延遲。由於資深客服人員的設定為 15 秒延遲，他們在 15 秒內將無法接受 Savings 聯絡。經過 15 秒後，該聯絡就可供資深客服人員使用，而 Amazon Connect 會在兩個轉接描述檔中尋找最長的有空時間。
### 服務路徑
當您在 Amazon Connect 中設計客戶體驗時，請計劃以確保提供服務路徑。在 Amazon Connect 流程中遍歷客戶體驗時，有許多計劃和未計劃的事件可能會影響客戶體驗。下列客戶體驗範例顯示一些建議的檢查，以確保聯絡的品質體驗一致：
![\[此圖顯示服務對可能影響客戶服務的非計劃性事件進行回應的路徑。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/architecture/pathtoservice.png)
此範例客戶體驗會將計劃的事件列入考量，例如假日和上班時間，以及未計劃的事件，例如在上班時間沒有客服人員上班。使用此邏輯，您還可以應對緊急情況，例如因惡劣天氣或服務中斷而關閉聯絡中心。請考慮下列概念，如圖表所示：
+ **自助式服務**：在典型的 IVR 中，您可以包含任何問候語和免責聲明訊息，例如預先的通話錄音通知，接著是自助式服務選項。自助式服務為您的客服中心帶來成本和效能最佳化，並可讓您的組織全年無休地為客戶提供服務，無論假日、工作時間或客服人員是否有空。如果客戶無法使用自助式服務並需要人工協助，請始終包括此服務路徑。例如，如果您使用 Amazon Lex 機器人進行自助式服務，您可以利用後援意圖來升級對話以取得人工協助。
+ **假日**：許多企業客戶都有一個儲存公司假日的中央儲存庫。您可以使用 AWS Lambda 函數將資料浸入該儲存庫，並為客戶提供假日處理方式。此外，您還可以將公司假日，以及每個假日的自訂訊息一起儲存在 DynamoDB。例如，如果您的企業將 12 月 25 日視為聖誕節，您可能會出現假日提示或文字轉換語音：「我們目前因聖誕節假期關閉。請於 12 月 26 日回電，我們將恢復正常營業時間。」
![\[顯示 Amazon Connect 如何使用 AWS Lambda 和 DynamoDB 向客戶播放訊息的圖表。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/architecture/holidays.png)
+ **營業時間**：假日通過驗證後，您可以檢查營業時間，如果在營業時間以外，您可以動態變更聯絡人的體驗。如果聯絡發生在營業時間，您可以識別客戶的通話意圖，並對應至聯絡中心中的某些佇列，從而增加找到正確客服人員的可能性，並減少聯絡到達服務所需的時間。強烈建議您對應預設值，因為客戶很有很能以您預期以外的原因致電，或是以您預期外的方式回應。
+ **緊急訊息**：確定客戶通話的意圖後，建議實施緊急檢查處理。如果發生影響您聯絡中心的緊急情況，您可以在 DynamoDB 之類的中介資料庫中儲存緊急情況是真/假旗標。若要允許您的主管和管理員在不使用程式碼的情況下動態設定此旗標，您可以建立單獨的 IVR，根據 ANI 和 PIN 碼驗證來驗證 Amazon Connect 管理員，僅供內部使用。在緊急情況下，您的主管可以從他們的電話撥打該專用線路，並在驗證後，將緊急標誌設定為真的，例如由於惡劣天氣或聯絡中心的實際位置的 ISP 中斷，導致聯絡中心關閉等情況。
+ **緊急訊息 API**：您也可以考慮使用後端的 AWS Lambda 函數建置 AWS API 閘道，以在資料庫中安全地將緊急旗標設定為 true/false。您的主管可以通過 Web 安全地訪問該 API 以切換災難模式或動態切換，以回應外部事件。在您的 Amazon Connect 執行個體中，透過流程傳入的每個聯絡人都會使用 AWS Lambda 來檢查該緊急旗標，如果是災難模式，您可以動態公告並提供客戶服務路徑。這將進一步確保業務連續性，並減輕這類情況對您客戶造成的影響。
+ **檢查客服人員配置**：在轉接至流程中的佇列之前，您可以檢查客服人員的配置，以確保客服人員以登入，為聯絡提供服務。例如，您可能有一位客服人員正忙於為其他聯絡人提供服務，而該客服人員可能會在接下來的五分鐘內變成有空，或者您可能根本沒有任何客服人員登入系統。在這些執行個體期間，您會偏好不同的客戶經驗，而不是讓他們在佇列中等待客服人員變得有空。
+ **轉接到服務**：將通話轉接到佇列時，您可以使用 Amazon Connect 轉接描述檔提供佇列回呼、佇列溢位或分層轉接，為符合服務等級要求的來電者提供一致、高品質的體驗。
## Resources
**文件**
+ [DevOps 和 AWS](https://aws.amazon.com/devops/)
+ [Amazon Connect 服務 API 文件](https://docs.aws.amazon.com/connect/latest/APIReference/welcome.html)
**部落格**
+ [如何使用 Amazon Connect 處理預期外的聯繫高峰](https://aws.amazon.com/blogs/contact-center/how-to-handle-unexpected-contact-spikes-with-amazon-connect/)
**影片**
+ [Amazon 的 DevOps](https://www.youtube.com/watch?v=esEFaY0FDKc.pdf)