本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 設定 Amazon Connect 中的轉接
在 Amazon Connect 中轉接包含三個部分：佇列、轉接描述檔和流程。本主題討論佇列和轉接描述檔。如需流程的資訊，請參閱 [Amazon Connect 中的流程](connect-contact-flows.md)。
佇列會將在等候客服人員接聽的聯絡案例予以保留。您可以使用單一佇列或多個佇列來處理所有來電的聯絡人。
佇列是透過轉接設定檔連結到客服人員。在您建立轉接設定檔時，您需要指定：
+ 其中包含哪些佇列。
+ 某個佇列是否應優先於其他佇列。
+ 客服人員會在聯絡控制面板 (CCP) 中處理哪些頻道。
+ 每個通道可以同時處理多少個聯絡人客服人員。
+ 個別佇列是否適用於所有通道，還是特定通道。
+ 客服將能夠手動排定工作優先順序的通道和佇列組合。
每個客服人員都會被指派一個轉接設定檔。
**Topics**
+ [轉接的運作方式](about-routing.md)
+ [佇列：「標準」和「客服人員」](concepts-queues-standard-and-agent.md)
+ [佇列：優先順序和延遲範例](concepts-routing-profiles-priority.md)
+ [以佇列為基礎的轉接](concepts-queue-based-routing.md)
+ [頻道和並行數量](channels-and-concurrency.md)
+ [建立佇列](create-queue.md)
+ [暫時停用佇列](disable-a-queue.md)
+ [刪除佇列](delete-queue.md)
+ [設定佇列容量](set-maximum-queue-limit.md)
+ [根據佇列容量路由聯絡人](route-based-on-queue-capacity.md)
+ [設定操作時數](set-hours-operation.md)
+ [建立轉接描述檔](routing-profiles.md)
+ [Amazon Connect 如何使用轉接設定檔](concepts-routing.md)
+ [刪除路由描述檔](delete-routing-profiles.md)
+ [設定以佇列為基礎的轉接](set-up-queue-based-routing.md)
+ [根據客服熟練度設定轉接](proficiency-routing.md)
# 轉接如何在 Amazon Connect 中運作
透過聯絡中心轉接的聯絡案例是根據下列因素：
+ 指派給客服的轉接設定檔。
+ 特定佇列的操作時數。
+ 您在流程中定義的轉接邏輯。
例如，您使用轉接描述檔，將特定類型的聯絡案例轉接至具有特定技能組合的客服人員。如果沒有具備所需技能組合的客服人員可提供協助，您可以將聯絡案例安排在流程中所定義的佇列。
以下是 Amazon Connect 用來轉接聯絡案例的邏輯：
+ 佇列中的聯絡人會自動排列優先順序，並轉接至下一個有空的客服人員 (也就是閒置最久的客服人員)。
+ 如果完全沒有可接聽的客服人員，該聯絡案例的通話將予以保留。服務順序由排隊時間決定，依先到先服務的原則行之。
+ 如果有多位客服人員能接聽聯絡人，則來電的聯絡人預設會轉接給已經處於**有空**狀態時間最久的客服人員。
**提示**
如需佇列優先順序和延遲如何運作的相關資訊，請參閱[佇列：優先順序和延遲範例](concepts-routing-profiles-priority.md)。
處理輸入或輸出聯絡人會導致客服程式下降到輸入聯絡人清單的底部。您可以選擇**撥出電話不應影響轉接順序**選項，將[轉接設定檔](routing-profiles.md)設定為忽略此計算中的外撥聯絡人。如果您的組織希望客服人員接聽撥出電話，並且仍然獲得相當大的入站聯絡人份額，請考慮選擇此選項。
例如：
+ 名為 Joe 的客服處於閒置狀態。他排在第三個接收撥入聯絡人。他寧願處理撥入聯絡人而非外撥聯絡人，因為他知道他將與客戶交談，而外撥聯絡人可能無法接電話。與撥入聯絡人交談會增加他在角色中獲得認可的機會。
+ 因為他處於閒置狀態，Joe 決定在積壓時進行出站聯絡以芯片。他可能會也可能不會聯絡到某人。
+ 根據預設，當 Joe 進行輸出聯絡人時，他會從第三行移至等待接收輸入聯絡人的專員清單底端。(如果有 10 個客服人員，將他移到第 10 位)。如果他應保留在第三位，則可覆寫預設行為。
+ 轉接設定檔可針對某個佇列指定較其他佇列更高的優先性，但佇列之中的優先順序，則一律按照聯絡人加入佇列的順序來排定。
+ 如果聯絡人屬於**僅**列示在轉接設定檔手動指派區段下的佇列和通道組合，則該聯絡人**不會**自動轉接至指派給該轉接設定檔的客服。
## 轉接轉移的運作方式
如上一節所述，在 Amazon Connect 中處理佇列中聯絡人的順序取決於多個因素，包括佇列時間、轉接存留期調整和聯絡優先順序。不過，如果聯絡人經歷轉移，Amazon Connect 會稍微不同地處理轉接存留期調整：這取決於聯絡人是由客服轉移，還是由流程或 API 中佇列到佇列的轉移所轉移。
下列兩個案例示範 Amazon Connect 如何處理轉接存留期調整。
+ **客服使用快速連線轉移聯絡人**：聯絡人最初會在時間 **X** 排入佇列，然後由客服處理。然後，客服會在時間 **Y** 使用快速連線將其轉移回佇列。在此案例中：
+ 原始排入佇列時間 **X** 用來計算此聯絡人在後續佇列中排名的順序。
+ 任何轉接存留期調整都會相對於該聯絡佇列時間進行套用。
+ **佇列至佇列轉移**：聯絡人從時間 **S** 開始在佇列中，最終在時間 **T** 轉移到不同的佇列。在此案例中：
+ 新的排入佇列時間 **T** 用來計算聯絡人排名的順序。
+ 任何轉接存留期調整都會相對於該聯絡佇列時間進行套用。
## 轉接如何與多個頻道搭配運作
當您設定路由描述檔來處理多個頻道時，您必須指定客服是否可以在已經在其他頻道上處理聯絡人。這稱為跨通道並行。
使用跨通道並行處理時，Amazon Connect 會檢查提供客服人員的聯絡人，如下所示：
1. 它會檢查客服人員目前正在處理的聯絡人/頻道。
1. 根據他們目前處理的通道，以及客服人員轉接設定檔中的跨通道組態，判斷客服人員是否可以轉接下一個聯絡人。
如需設定跨通道並行時 Amazon Connect 路由如何聯絡的詳細範例，請參閱 [使用跨通道並行路由聯絡人的範例](routing-profiles.md#example-routing-concurrency)。
## 轉接如何使用手動指派
當您設定路由描述檔，其中列出要手動指派的佇列和頻道時， Amazon Connect 不會自動路由這些聯絡人。
具有此轉接設定檔的客服可以根據其安全性設定檔設定，在其客服人員工作區的工作清單應用程式中檢視排入佇列的聯絡人 (目前僅支援任務、電子郵件和聊天)，並決定要指派給自己的下一個重要工作項目。
## 進一步了解轉接
若要進一步了解轉接，請參閱下列主題：
+ [佇列：優先順序和延遲範例](concepts-routing-profiles-priority.md).
+ [Amazon Connect 如何使用轉接設定檔](concepts-routing.md)
+ [將客戶轉接至特定聯絡中心客服人員的佇列型轉接](concepts-queue-based-routing.md)
+ [設定以佇列為基礎的轉接](set-up-queue-based-routing.md)
# Amazon Connect 聯絡中心的標準佇列和客服佇列
佇列有兩種類型：
+ **標準佇列**：將聯絡人轉接給客服人員以及在客服人員接受之前，會在此位置等候。
+ **客服人員佇列**：當您將客服人員新增到您的聯絡中心時，系統會自動建立這些佇列。
只有在作為流程的一部分，明確傳送到該位置時，才會將聯絡人轉接到客服人員佇列。例如，您可能會將聯絡人轉接給負責某些客戶問題的特定客服人員，例如帳單或付費支援。或者，您可能會使用客服人員佇列來轉接到客服人員的語音信箱。
在客服人員佇列中等候的聯絡人，其優先順序高於在標準佇列中等候的聯絡人。客服人員佇列中的聯絡人具有最高優先順序和零延遲：
+ 最高優先順序：如果基本佇列中有另一個聯絡人，Amazon Connect 會選擇先將來自客服人員佇列的聯絡人轉接給客服人員。
+ 零延遲：如果客服人員有空，會立即將聯絡人轉接給他們。
## 指標報告中的佇列
在[即時指標報告](real-time-metrics-reports.md)中，您可以監控標準佇列和客服人員佇列中有多少聯絡人。下圖顯示即時指標「佇列」報告範例，其中已新增「客服人員」表和「客服人員佇列」表。它顯示：
+ **BasicQueue**，這是標準佇列。它顯示一個客服人員 (John) 在線上。
+ **客服人員** 表格顯示客服人員 John 已將其 CCP 設定為 **可用**，且已準備好接待聯絡人。主管可以從這裡更改客服人員的狀態。例如，設定為 **離線**。
+ **客服人員佇列** 表格，顯示 John 的客服人員佇列。它顯示 John 在線上，也可以從此佇列中接受聯絡人。
![\[具有「客服人員」表和「客服人員佇列」表的佇列報告。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/rtm-standard-and-agent-queues.png)
當客服人員收到來自標準佇列的聯絡人時，該聯絡人絕不會顯示在客服人員佇列中。會直接交給客服人員。
在[歷史指標報告](historical-metrics.md)中，依據預設，客服人員佇列不會顯示在「佇列」表格中。若要顯示它們，請選擇 **設定** 圖示，然後選擇 **顯示客服人員佇列**。
![\[資料表設定頁面上的客服佇列下拉式功能表。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/hmr-queues-settings-agent-queues.png)
**提示**
指標 API 不支援客服人員佇列。
## 預設佇列：BasicQueue
Amazon Connect 包含名為 **BasicQueue** 的預設佇列。搭配[預設流程](contact-flow-default.md)和預設轉接描述檔 (名為 **基本轉接描述檔**)，它可以為您的客服中心提供動力，因此您不需要進行任何自訂。因此您可以快速開始使用。
# 協助您平衡 Amazon Connect 聯絡人負載的佇列優先順序和延遲範例
本主題為佇列提供數個範例優先順序和延遲設定，並說明如何在每個案例中轉接聯絡人。使用這些範例，以使用優先順序和延遲功能來平衡聯絡人負載。
## 範例 1：優先順序不同，但延遲相同
例如，將一群客服人員指派給銷售轉接描述檔。由於其主要任務是銷售，因此銷售佇列為優先順序 1，延遲為 0。但他們也可以為支援中心提供協助，因此佇列為優先順利 2，延遲為 0。如以下表所示：
| 佇列 | Priority | 延遲 (單位：秒) |
| --- | --- | --- |
| 銷售 | 1 | 0 |
| 支援 | 2 | 0 |
如果銷售佇列中沒有聯絡人，客服人員將會看到來自支援佇列的聯絡人。
## 範例 2：優先順序相同，但延遲不同
假設您將支援佇列設為優先順序 1，延遲 30 秒，如下表所示：
| 佇列 | Priority | 延遲 (單位：秒) |
| --- | --- | --- |
| 銷售 | 1 | 0 |
| 支援 | 1 | 30 |
因為延遲為 0，所以這些客服人員一律會先從銷售佇列取得聯絡人。不過，當**支援**佇列中的聯絡人存留超過 30 秒，該聯絡人也會視為優先順序 1。然後，客服人員會看到來自**支援**佇列的聯絡人。
## 範例 3：優先順序和延遲皆不同
以下是支援轉接描述檔的更複雜範例：
| 佇列 | Priority | 延遲 (單位：秒) |
| --- | --- | --- |
| 第 1 層支援 | 1 | 0 |
| 第 2 層支援 | 1 | 0 |
| 第 3 層支援 | 2 | 20 |
| 第 4 層支援 | 3 | 80 |
每個轉接描述檔的優先順序都是 1，因此此轉接描述檔會將第 1 層支援和第 2 層支援佇列設為相同的優先順序。
+ 在下列情況下，客服人員可能會從第 3 層支援佇列取得聯絡人：
+ 第 3 層支援的客戶等待的時間為 20 秒或更久。
+ 而且第 1 層支援或第 2 層支援佇列中沒有聯絡人。
+ 在下列情況下，客服人員可能會從第 4 層支援佇列取得聯絡人：
+ 第 4 層支援佇列中的客戶已等待超過 80 秒。
+ 而且第 1 層支援、第 2 層支援或第 3 層支援佇列中沒有聯絡人。
**優先順序優先**。(當聯絡人位於第 1 層支援、第 2 層支援或第 3 層支援中，您可能會認為代理人會從第 4 層支援中取得聯絡人，並等待 20 秒或更長時間，但這並不正確。)
## 範例 4：相同的優先順序和延遲
在此範例中，轉接設定檔只有兩個佇列，而且它們具有相同的優先順序和延遲：
| 佇列 | Priority | 延遲 (單位：秒) |
| --- | --- | --- |
| 銷售 | 1 | 0 |
| 支援 | 1 | 0 |
對於此轉接設定檔，系統會先轉接傳送最舊的聯絡人。它會先被轉接到已經閒置了最長時間的客服人員。
## 範例 5：客服閒置且聯絡人位於 30 秒延遲佇列中
假設客服閒置且聯絡人處於延遲狀態 (對於 30 秒延遲佇列，聯絡人存留 15 秒)。發生什麼情況？
轉接設定檔中的**延遲**設定表示必須先經過 X 秒，然後才能將此聯絡人提供給具有此轉接設定檔的客服。客服是否閒置不會納入考量。因此，在這種情況下，在聯絡人至少存留 30 秒之前，不會將聯絡人提供給此客服。
## 範例 6：不同的轉接設定檔、相同的佇列、不同的優先順序
例如：
| 客服人員 | Priority | 佇列 |
| --- | --- | --- |
| 客服 A | 1 | 1 |
| 客服 B | 5 | 1 |
+ **這兩個客服皆可用。誰會接到電話？ 這取決於 ... **
+ 轉接一律會先嘗試轉接到可用時間最長的客服。
客服 A 的設定檔具有佇列 1 的優先順序 1，而客服 B 的設定檔具有佇列 1 的優先順序 5。當這兩個客服都可用時，聯絡人 Z 會新增至佇列 1。在此情況下，聯絡人 Z 一律會轉接到任何可用時間較長的客服。如果客服 B 的可用時間較長，則聯絡人 Z 將轉接至客服 B。
+ 佇列的優先順序與搜尋個別客服的佇列有關。它不會確定聯絡人將轉接多個可用客服中的哪個客服。
假設聯絡人 Y 位於佇列 2 中，並且在那裡的時間超過佇列 1 中的聯絡人 Z。即使客服 A 較新，聯絡人 Z 仍會轉接該客服。這是因為佇列 1 在客服的設定檔中有較高的優先順序。
+ **是否只有在優先順序較高的客服無法使用時，優先順序 5 客服才會取得通話？**
否。只有在其他優先順序佇列為空白時，優先順序 5 客服才會接收來自該佇列的通話。一個客服的佇列優先順序設定不會影響佇列相對於其他客服的聯絡人轉接順序，而是相對於客服設定檔中的其他佇列。
如需有關如何設定轉接描述檔的指示，請參閱 [在 Amazon Connect 中建立轉接設定檔，將佇列連結至客服](routing-profiles.md)。
# 將客戶轉接至特定聯絡中心客服人員的佇列型轉接
在企業中，您可能會想要根據特定條件 (例如客服人員的技能)，將客戶轉接給特定的客服人員。這樣的功能稱為以佇列為基礎的轉接，也稱為以技能為基礎的轉接。
例如，航空公司可能有一些客服人員負責處理講英語的客戶的預訂，其他客服人員則處理講西班牙語的客戶，以及第三組客服人員會處理這兩種類型的客戶，但方式只限定電話處理。
下圖顯示您可以執行的動作：
+ 將相同的轉接描述檔指派給多個客服人員。
+ 將多個佇列指派給轉接描述檔。
+ 將佇列指派給多個轉接描述檔。
![\[四個轉接描述檔的圖形。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/routing-profile-example2.png)
如需有關設定以佇列為基礎的轉接的步驟概觀，請參閱[設定以佇列為基礎的轉接](set-up-queue-based-routing.md)。
# 在 Amazon Connect 中轉接聯絡人的頻道和並行
客服可以在 Amazon Connect 中處理語音、聊天、任務和電子郵件。當您設定轉接描述檔來處理多個頻道時，您有兩個選項：
+ 選項 1：設定客服人員，當他們已經在其他頻道時可以處理聯絡人。這就是所謂的*跨頻道並行*。
+ 選項 2：設定客服，以便在客服完全閒置時為他們提供語音、聊天、任務或電子郵件，取決於佇列中的內容。如果您選擇此選項，當客服人員開始處理來自某個頻道的聯絡人之後，將不再提供來自任何其他頻道的聯絡人。
使用跨頻道並行處理時，Amazon Connect 會檢查要為哪一位聯絡人提供客服人員，如下所示：
1. 它會檢查客服人員目前正在處理的聯絡人/頻道。
1. 根據他們目前處理的頻道，以及客服人員轉接描述檔中的跨頻道組態，判斷客服人員是否可以轉接下一個聯絡人。
1. 如果優先順序和延遲相等，Amazon Connect 會優先處理等待時間最久的聯絡人。即使它同時評估多個頻道，仍然會尊重先進先出的順序。
如需設定跨頻道並行時 Amazon Connect 如何轉接聯絡人的詳細範例，請參閱 [使用跨通道並行路由聯絡人的範例](routing-profiles.md#example-routing-concurrency)。
若要進一步了解客服人員在處理多個聊天時，在聯絡控制面板中的體驗，請參閱 [使用 Amazon Connect 聯絡人控制台 (CCP) 與聯絡人互動](chat-with-connect-contacts.md)。
# 使用 Amazon Connect 管理員網站建立佇列
本主題說明如何使用 Amazon Connect 管理員網站建立佇列。若要以程式設計方式建立佇列，請參閱 *Amazon Connect API 參考*中的 [create-queue](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/connect/create-queue.html) AWS CLI 或 [CreateQueue](https://docs.aws.amazon.com/connect/latest/APIReference/API_CreateQueue.html)。
**我可以建立多少個佇列？** 若要檢視**每個執行個體的佇列**配額，請於 [https://console.aws.amazon.com/servicequotas/](https://console.aws.amazon.com/servicequotas/) 開啟 Service Quotas 主控台。
**建立佇列**
1. 登入 Amazon Connect 管理網站，網址為 https：//*instance name*.my.connect.aws/。使用**管理員**帳戶，或在其安全性設定檔中具有**轉接** - **佇列** - **建立**許可的帳戶。
1. 在 Amazon Connect 管理員網站上的導覽功能表中，選擇**轉接**、**佇列**、**新增佇列**。
1. 加入合適的佇列相關資訊，並選擇**新增佇列**。
下圖顯示 BasicQueue 的佇列資訊。
![\[基本佇列的編輯佇列頁面。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/add-a-new-queue.png)
如需有關上述各個領域的詳細資訊，請參閱下列主題：
1. [使用 Amazon Connect 為佇列設定營業時間和時區](set-hours-operation.md)
1. [在 Amazon Connect 中設定外撥來電者 ID](queues-callerid.md)
1. [在 Amazon Connect 中設定電子郵件](setup-email-channel.md)
1. [使用 Amazon Connect 設定佇列中的聯絡人數量上限](set-maximum-queue-limit.md)
1. [在 Amazon Connect 中建立快速連線](quick-connects.md)
佇列會自動啟動。
1. 將佇列指派給轉接設定檔；如需詳細資訊，請參閱[在 Amazon Connect 中建立轉接設定檔，將佇列連結至客服](routing-profiles.md)。轉接設定檔會將佇列和客服人員連結在一起。
1. 新增標籤以識別、組織、搜尋、篩選和控制誰可以存取此佇列。如需詳細資訊，請參閱[在 Amazon Connect 中將標籤新增至資源](tagging.md)。
若要了解佇列的運作方式，請參閱 [Amazon Connect 如何使用轉接設定檔](concepts-routing.md) 和 [將客戶轉接至特定聯絡中心客服人員的佇列型轉接](concepts-queue-based-routing.md)。
## 用於建立和管理佇列的 API
使用下列 API 以程式設計方式建立和管理佇列：
+ [CreateQueue](https://docs.aws.amazon.com/connect/latest/APIReference/API_CreateQueue.html)
+ [DeleteQueue](https://docs.aws.amazon.com/connect/latest/APIReference/API_DeleteQueue.html)
+ [DescribeQueue](https://docs.aws.amazon.com/connect/latest/APIReference/API_DescribeQueue.html)
+ [ListQueues](https://docs.aws.amazon.com/connect/latest/APIReference/API_ListQueues.html)
+ [SearchQueues](https://docs.aws.amazon.com/connect/latest/APIReference/API_SearchQueues.html)
+ [UpdateQueueHoursOfOperation](https://docs.aws.amazon.com/connect/latest/APIReference/API_UpdateQueueHoursOfOperation.html)
+ [UpdateQueueMaxContacts](https://docs.aws.amazon.com/connect/latest/APIReference/API_UpdateQueueMaxContacts.html)
+ [UpdateQueueName](https://docs.aws.amazon.com/connect/latest/APIReference/API_UpdateQueueName.html)
+ [UpdateQueueOutboundCallerConfig](https://docs.aws.amazon.com/connect/latest/APIReference/API_UpdateQueueOutboundCallerConfig.html)
+ [UpdateQueueOutboundEmailConfig](https://docs.aws.amazon.com/connect/latest/APIReference/API_UpdateQueueOutboundEmailConfig.html)
+ [UpdateQueueStatus](https://docs.aws.amazon.com/connect/latest/APIReference/API_UpdateQueueStatus.html)
# 使用 Amazon Connect 暫時停用佇列
您可以暫時停用佇列，以快速控制聯絡案例到佇列的流程。當佇列被停用時，它會處於離線模式。沒有新的聯絡案例會轉接到佇列，但佇列中已有的任何現有聯絡案例都會轉接到客服人員。
只有其安全設定檔具有**轉接** - **佇列** - **啟用/停用**許可的使用者，才能停用佇列。
![\[安全性設定檔許可表，其中顯示已選取 [建立] 核取方塊的佇列資料列。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/disable-queue.png)
**暫時停用作用中的佇列**
1. 登入 Amazon Connect 管理網站，網址為 https：//*instance name*.my.connect.aws/。使用**管理員**帳戶，或在其安全性設定檔中具有**轉接** - **佇列** - **啟用/停用**許可的帳戶。
1. 在 Amazon Connect 管理員網站上，於導覽功能表上，選擇**路由**、**佇列**。
1. 對於您要停用的佇列，請將**狀態**切換為**已停用**，如下圖所示。
![\[佇列頁面，狀態切換。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/disable-queue-power-button.png)
1. 選擇**停用**以確認您要停用佇列，如下圖所示。如有需要，您可以將按鈕切換回**已啟用**，以立即重新啟用佇列。
![\[停用佇列確認方塊。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/disable-queue-confirm.png)
# 從 Amazon Connect 執行個體刪除佇列
有三種方式可從 Amazon Connect 執行個體刪除佇列：
+ Amazon Connect 管理員網站
1. 登入 Amazon Connect 管理網站，網址為 https：//*instance name*.my.connect.aws/。使用**管理員**帳戶，或在其安全性設定檔中具有**轉接** - **佇列** - **刪除**許可的帳戶。
1. 在 Amazon Connect 管理員網站上的導覽功能表中，選擇**轉接**、**佇列**，然後選取刪除圖示。
![\[佇列頁面、狀態選項和刪除選項。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/delete-queue.png)
**重要**
您無法復原已刪除的佇列。若要暫時停用佇列，請將其狀態切換為**已停用**。
+ [DeleteQueue](https://docs.aws.amazon.com/connect/latest/APIReference/API_DeleteQueue.html) API
+ [delete-queue](https://docs.aws.amazon.com/cli/latest/reference/connect/delete-queue.html) AWS CLI
# 使用 Amazon Connect 設定佇列中的聯絡人數量上限
依預設，佇列最多可包含語音、聊天、任務和電子郵件的[服務配額](amazon-connect-service-limits.md)：
+ **每個執行個體同時進行有效通話數**
+ **每個執行個體同時進行有效聊天數 (包含 SMS)**
+ **每個實例的並發活動任務**
+ **每個執行個體的並行作用中電子郵件**
若要增加其中一個配額，您必須請求增加配額。如需詳細資訊，請參閱[Amazon Connect 服務配額](amazon-connect-service-limits.md)。
在某些情況下，您可能希望特定佇列允許的聯絡人數量少於允許的配額。例如：
+ 您有一個專門用於呼叫複雜問題的佇列，這些問題平均需要 15 分鐘才能解決，您可能希望將佇列中允許的呼叫數量限制為少於**每個執行個體的並行作用中呼叫**。這樣可以防止客戶等待數小時。
+ 您可能有專用於聊天的佇列。您的服務配額為 100，但您一次最多只需要 20 個聊天。您可以設定該值，以便 Amazon Connect 限制路由到該佇列的使用中聊天數。
+ 您有一個組合多個通道的隊列，並且設置了自定義值。請注意，無論聯絡人的分佈為何，佇列都會在達到該號碼後停止接受新聯絡人。例如，如果您將值設定為 50，而前 50 位聯絡人為聊天，則語音通話不會路由傳送至此佇列。
本主題說明如何在這些情況下減少佇列中允許的聯絡人數目。
## 減少佇列中允許的聯絡人數目
若要同時減少[標準佇列](concepts-queues-standard-and-agent.md)中允許的聯絡人數目，您可以為標準**佇列設定佇列中的聯絡人**數目上限。此設定不適用於[客服佇列](concepts-queues-standard-and-agent.md)。
![\[跨所有頻道設定佇列中聯絡人數量上限的選項。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/maximum-contacts-in-queue3.png)
當您在**佇列中的聯絡人數量上限**中輸入數字時，Amazon Connect 會驗證該數字是否少於同時作用中聯絡人 Service Quotas 的總和：**每個執行個體的並行通話** \$1 **每個執行個體的並行作用中聊天** \$1 **每個執行個體的並行作用中任務** ＋ **每個執行個體的並行作用中電子郵件**。
**重要**
您必須將**佇列中的聯絡人數量上限**設定為小於以下合計配額的總和：**每個執行個體的並行通話** \$1 **每個執行個體的並行作用中聊天** \$1 **每個執行個體的並行作用中任務** ＋ **每個執行個體的並行作用中電子郵件**。
來電和排入佇列的回呼會計入佇列大小限制。
如需預設 Service Quotas 與如何請求提高配額的相關資訊，請參閱 [Amazon Connect 服務配額](amazon-connect-service-limits.md)。
**減少特定佇列中允許的聯絡人數量**
1. 在導覽功能表上，選擇**路由**、**佇列**、**新增佇列**。或者，編輯現有的佇列。
1. 在**佇列中的聯絡人數**上限中，選擇**設定所有頻道的限制**。如果佇列也用於聊天、任務和電子郵件，則所有頻道都將被限制在相同的上限。
1. 在方塊中指定在佇列視為滿載之前，佇列中可以有多少聯絡人。該值不得超過**每個執行個體的並行作用中通話** \$1 **每個執行個體的並行作用中聊天** \$1 **每個執行個體的並行作用中任務** ＋ **每個執行個體的並行作用中電子郵件**的總和。
![\[用於設定佇列中聯絡人數量上限的輸入欄位，其中顯示的值為 7。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/maximum-contacts-in-queue2.png)
## 佇列已滿時來電會發生什麼情況
+ 來電：理想情況下，您已[設定排入佇列的回撥](setup-queued-cb.md)，或已實作另一個緊急項目。若不是，下一個來電會聽到重新排序音 (又稱為快速忙碌音)，這表示所撥的號碼沒有可用的傳輸路徑。
+ 排隊的回調：下一個排隊的回調被路由到錯誤分支。
## 如果佇列中的聯絡人數上限設為 0，會發生什麼情況
如果您將**佇列中的聯絡人數上限**設定為 0，則會使佇列無法使用。行為與佇列已滿時相同。
## 佇列最大限制例外
有時候，您可以將更多的聯絡人新增至佇列中的聯絡人數目限制，而不是設定的**佇列中最大聯絡人數**限制。
+ 在佇列達到容量限制的時間到流程中強制執行此限制之間，可能會稍有延遲。這種延遲可能會導致傳入的聯絡人在這段時間內排入佇列，尤其是在流量爆發期間。
此外，針對下列例外情況，Amazon Connect 還為佇列容量提供 20% 的緩衝區：
+ 聯絡人已轉換為排入佇列的回呼，排程在 X 時使用流程中的**初始延遲**設定將其新增至佇列。但是，當排定的時間到達時，目標佇列已達到其**佇列中的容量上限**。在這個案例中，Amazon Connect 允許將佇列回呼排入**佇列中最大容量**限制的 20% 緩衝區。
+ 先前排入佇列 1 的聯絡人現在正透過流程將聯絡人傳輸到 Queue2。不過，嘗試傳輸時，佇列已達到**佇列最大容量**。在這個案例中，Amazon Connect 允許傳輸繼續，佇列 2 的最大容量緩衝區達到**佇列中最大容量**限制的 20%。
+ 客服人員透過快速連線，將聯絡人手動轉移到佇列中。不過，嘗試傳輸時，佇列已達到**佇列中的容量上限**。在這個案例中，Amazon Connect 允許傳輸繼續進行，最高可達**佇列中最大容量限制**的 20% 緩衝區。
# 使用 Amazon Connect 根據佇列容量轉接聯絡人
若要根據佇列容量定義路由決策，請使用 [轉接至佇列](transfer-to-queue.md) 區塊來檢查佇列是否已滿 ([佇列中的聯絡人數上限](set-maximum-queue-limit.md))，然後相應地路由聯絡人。
[轉接至佇列](transfer-to-queue.md) 區塊會檢查[佇列中的聯絡人數上限](set-maximum-queue-limit.md)。如果沒有設定限制，該佇列的上限會受限於下列配額的聯絡案例並行總數量：
+ 每個執行個體的有效任務
+ 每個執行個體的並行作用中電子郵件
+ 每個執行個體的並行通話數
+ 每個執行個體並行聊天數
# 使用 Amazon Connect 為佇列設定營業時間和時區
本主題說明如何使用 Amazon Connect 管理員網站設定操作時數。若要以程式設計方式設定時數，請參閱[操作時數動作](https://docs.aws.amazon.com/connect/latest/APIReference/hours-of-operation-api.html)。
當您在設定佇列時，第一個要做的事便是指定操作時數和時區。該時數可能會在流程中做為參考。例如，當轉接聯絡人到客服人員時，您可以先使用 [檢查操作時數](check-hours-of-operation.md) 區塊，然後轉接該聯絡人到適當的佇列。
![\[具有覆寫的營業時間頁面。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/hoop-listpage.png)
**Topics**
+ [我可以建立多少營業時間和覆寫？](#howmany-hours)
+ [設定操作時數](#set-hoop)
+ [如何指定午夜](#set-hours-operation-midnight)
+ [範例](#set-hours-operation-examples)
+ [新增午餐和其他休息時間](#add-lunch-breaks)
+ [日光節約時間](#daylight-savings-time)
+ [流程如何利用操作時數](#use-check-hours-of-operation-block)
+ [為延長、縮短和假日營業時間設定覆寫](hours-of-operation-overrides.md)
+ [檢視說明有效營業時間的行事曆](view-hours-of-operation-calendar.md)
## 我可以建立多少營業時間和覆寫？
若要檢視**每個執行個體的操作時數**配額，請於 [https://console.aws.amazon.com/servicequotas/](https://console.aws.amazon.com/servicequotas/) 開啟 Service Quotas 主控台。
## 設定操作時數
1. 使用 Amazon Connect 管理員帳戶或具有**路由 - 操作時數 - 建立**安全性設定檔許可的帳戶登入管理員網站。
1. 在瀏覽功能表上，選擇**路由**、**操作時數**。
1. 若要建立一組操作時數，請選擇**新增一組小時**，然後輸入名稱和描述。
1. 選擇**時區**並選擇一個值。
1. 選擇**營運時數**來設定新的時數。
1. 或者，在**標籤**區段中，新增標籤以識別、組織、搜尋或篩選可存取此時數作業記錄的使用者。如需詳細資訊，請參閱[在 Amazon Connect 中將標籤新增至資源](tagging.md)。
1. 選擇 **Save** (儲存)。
1. 現在，您可以在[建立佇列](create-queue.md)時指定這些操作時數，然後在 [檢查操作時數](check-hours-of-operation.md) 區塊中選擇它們。
## 如何指定午夜
若要指定午夜，請輸入上午 12:00。
例如，若要將時數設為上午 10:00 到午夜，請輸入：上午 10:00 到上午 12:00。客服中心會持續開放 14 小時。以下是其數學算式：
+ 上午 10:00 - 下午 12:00 = 2 小時
+ 下午 12:00 - 上午 12:00 = 12 小時
+ 總計 = 14 小時
## 範例
**排定為全年無休**
![\[每週 24 小時聯絡中心排程的範例。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/set-hours-of-operation-24x7.png)
**排定為週一到週五上午 9:00 到下午 5:00**
選取按鈕以**展開至個別日期**。
從排程中移除週日和週六。
![\[從聯絡中心排程中移除日子的範例。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/set-hours-of-operation-closed-weekends-remove.png)
## 新增午餐和其他休息時間
選取 **\$1 在操作時數區段底部新增更多時間**以建立更多資料列，然後設定每天的時數範圍。例如，如果週六小時為 8-11，則小時為 1-5：
![\[顯示聯絡中心排程中午餐休息時間的圖表。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/hours-of-operation-lunch.png)
大多數的聯絡中心休息時間是交錯開來的。例如，有些客服人員在吃午餐，其他客服人員仍然可以處理聯絡案例。您可以在客服人員的聯絡控制面板 (CCP) 中[新增自訂客服人員狀態](agent-custom.md)，而不是在操作時間內指定此項目。
例如，您可以建立名為**午餐**的自訂狀態。當客服人員去吃午餐時，他們會將他們在 CCP 的狀態從**有空**變為**午餐**。在此期間，系統不會將任何聯絡案例轉接給他們。當他們從午餐回來並準備再次服務聯絡案例時，他們會將狀態變更回**有空**。
主管可以使用即時指標報告來變更客服人員的狀態。
如需詳細資訊，請參閱以下主題：
+ [將自訂客服人員狀態新增至 Amazon Connect 聯絡人控制台 (CCP)](agent-custom.md)
+ [聯絡人控制台 (CCP) 中的客服狀態。](metrics-agent-status.md)
+ [在聯絡人控制台 (CCP) 中變更指標報告中的「客服活動」狀態](rtm-change-agent-activity-state.md)
## 夏令時間期間發生的事
Amazon Connect 會使用該時區判斷佇列是否有效日光節約時間，並針對所有觀察日光節約時間的時區**自動調整**。聯絡人進入時，Amazon Connect 會查看聯絡中心的營業時間和時區，以判斷聯絡人是否可以轉接到指定的佇列。
**重要**
Amazon Connect 提供 EST5EDT, PST8PDT, CST6CDT等的選項。例如，EST5EDT 被定義為：
[東部標準時間 (EST)](https://en.wikipedia.org/wiki/Eastern_Time_Zone) 在遵循標準時間時使用。它比國際標準時間 (UTC) 晚五個小時。
[東部夏令時間 (EDT)](https://en.wikipedia.org/wiki/Eastern_Time_Zone) 在遵循夏令時間時使用。它比國際標準時間 (UTC) 晚四個小時。
我們建議您研究您選擇的時區，以確保您了解它。
### 範例
1. 有一個人員與您的聯絡中心起始通話或聊天。
1. Amazon Connect 會立即查看您客服中心的營業時間。
+ 聯絡人來自時區 A。
+ 您電話中心的營業時間是時區 B 的上午 9 點至下午 5 點。
+ 如果時區 B 的目前時間是下午 2 點，則通話或聊天會排入佇列。
+ 如果時區 B 的目前時間是上午 7 點，則通話或聊天不會排入佇列。
## 流程如何利用操作時數
流程可設定為檢查聯絡案例是否在區塊定義的操作小時內或之外。然後，流程可以分支以根據結果遵循不同的路徑，例如，因此訊息會在下班後播放，在操作恢復時提供回呼。若要深入了解，請參閱[檢查操作時數](check-hours-of-operation.md)。
# 識別您需要覆寫標準營業時間的日期
您可以覆寫未來日期的標準操作時數，其中操作將會關閉、減少時數，或開啟時間會比平常更長。
**注意**
每個操作資源小時最多可建立 50 個覆寫。此配額不可調整。
**建立覆寫**
1. 導覽至**路由**功能表並開啟**操作時數**。
1. 選取記錄的名稱以開啟記錄。
1. 在**覆寫**區段中，選取**建立**。
**注意**
如果您有僅限檢視的許可，則不會看到此動作。
1. 透過選擇下列選項來建置您的覆寫清單：
1. **新增重複事件** — 用於假日和遵循重複模式的其他日期 （例如每個月的最後一個星期五提早關閉）。
1. **建立臨時時數** — 用於非標準時數的非週期性日期，其中設定的時數必須取代該日期/範圍的所有其他設定。
1. **從另一個營運時間複製** - 當將已在其他記錄上設定的覆寫彙總在一起時，使用 ，但您希望 選項進行變更 （例如，移除特定日期）。
**注意**
與其直接設定日期和時間清單，您可以連結到在不同的操作時間資源上設定的覆寫。如果您想要共用在一個位置維護的主清單，請使用此方法。
1. 遵循開啟視窗上的指示。
1. 選取**套用** （套用） 以遞交您選取的日期和時數。
1. 選取操作資源頁面右上角的**儲存**。
![\[操作時數會覆寫資料表動作下拉式清單。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/hours-of-operations-overrides.png)
**週期性事件**
如果您選擇週期性事件：
1. 為此覆寫提供有意義的**名稱**。
1. 選取此覆寫的**有效日期**。
**注意**
流程會使用這些日期來判斷是否應考慮此覆寫。如果今天的日期在此範圍之前或之後，則會忽略覆寫。
1. 指出操作為**關閉**或**開啟**。
1. 選擇**週期模式**。根據您的選擇，您將能夠提供其他詳細資訊。
在此範例中，無論操作位於哪一天，操作都會在每年的特定日期關閉：
![\[用於新增一週中任何一天的週期性事件的對話方塊。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/add-annual-recurring-hours-of-operation-override.png)
在此範例中，已設定每隔一週的延長時數：
![\[每隔一週新增重複事件的對話方塊。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/add-daily-recurring-hours-of-operation-override.png)
**暫時時數**
如果您選擇臨時時數：
1. 為此覆寫提供有意義的**名稱**。
1. 選取此覆寫的**有效日期**。
**注意**
流程會使用這些日期來判斷是否應考慮此覆寫。如果今天的日期在此範圍之前或之後，則會忽略覆寫。
1. 選取指定日期的**時數** （將取代星期的標準排程）。
**注意**
重複的開啟/關閉覆寫優先於暫時時數。
在此範例中， 操作只會每隔一天開啟一次，並持續部分小時：
![\[用於每隔一天建立暫時時數的對話方塊。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/create-temporary-hours-of-operations.png)
**複製覆寫**
如果您選擇**從其他營運時間複製**：
1. 尋找父資源並選取它。
1. 接下來，按一下**儲存連結**。
![\[用於從不同操作小時複製覆寫的對話方塊。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/copy-hours-of-operation-overrides.png)
複製清單後，覆寫記錄與其*來源不同*。它們不會受到對該原始清單所做的變更影響 （例如，如果人力日從關閉變更為半天）。
**注意**
複製的覆寫會計入 50 個覆寫服務配額。
**注意**
如果您想要改為依賴全域清單，並確保您的覆寫日期和時間自動保持同步，請遵循*連結*的指示，而不是複製。
**連結覆寫**
在操作記錄數小時內設定覆寫清單的替代方法是連結到另一個包含主清單的資源。例如，您可以設定「父」小時的操作來存放全球公司假日清單，而另一個則用於區域封鎖日期，以此類推。每個連結到父項記錄的「子項」都會繼承其覆寫。隨著對父項進行變更，子項會自動受益，而無需額外努力。
![\[來自不同操作時數資料表的連結覆寫。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/linked-hours-of-operations.png)
若要建立連結，以便從另一個小時的操作繼承覆寫：
1. 開啟記錄並導覽至**連結的操作時數**區段。
1. 選取按鈕以**新增連結**。
![\[用於連結不同操作時數覆寫的對話方塊。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/link-hours-of-operation-overrides.png)
1. 選擇名為 **Inherit** 的連結模式。
1. 搜尋將提供來源覆寫清單的操作時數。
1. 選取**儲存連結**按鈕。
1. 視需要重複執行。
**注意**
父覆寫不會計入 50 個覆寫服務配額。
**注意**
一個子系最多可連結至 3 個父系。此配額不可調整。
**注意**
在一小時的操作記錄成為子系之後，就不能有子系本身。
若要建立共用覆寫的連結：
1. 開啟記錄並導覽至**連結的操作時數**區段。
1. 選取按鈕以**新增連結**。
1. 選擇名為**共用**的連結模式。
1. 搜尋您想要為其提供覆寫的操作時數。
1. 選取**儲存連結**按鈕。
1. 視需要重複執行。
**注意**
可以參考相同父項的子項數量不受限制。執行個體中的所有操作小時都可以共用相同的父覆寫清單。
**注意**
在一小時的操作記錄成為父系之後，就無法擁有父系本身。
連結清單中的覆寫清單無法以任何方式從子記錄修改。只能從父項記錄進行變更。如果連結發生錯誤，則可以將其移除。
如果只有具有編輯操作時數許可的使用者子集才能存取父項記錄，您可以設定精細的存取控制。如需詳細資訊，請參閱[在 Amazon Connect 中套用標籤型存取控制](tag-based-access-control.md)。
**具有競爭覆寫的日期**
有時候，特定操作資源時數的覆寫可能會彼此衝突。Connect 會排定各種類型的優先順序，如下所示：
1. 已關閉的重複覆寫會優先考慮。
1. 接下來會考慮開啟重複覆寫。
1. 接下來會考慮暫時時數。
1. 標準day-of-the-week幾時數視為最後時間。
在下列範例中，有許多競爭組態，但由於經常性關閉時數涵蓋整天，因此會忽略其他覆寫和操作時數。聯絡中心關閉整天。
![\[要關閉的營運時數覆寫範例。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/hours-of-operation-overrides-example-1.png)
在不同的範例中，標準營業時間通常不會在週日開放。不過，這是特殊的例外狀況，因為公司很想在一年中最忙碌的購物日支援客戶。在此情況下，聯絡中心的營業時間為上午 10 點到晚上 10 點。
![\[操作時數覆寫在正常關閉日期開啟的範例。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/hours-of-operation-overrides-example-2.png)
在最後範例中，聯絡中心會在上午 8 點開啟，然後從中午至下午 4 點關閉，然後在下午 8 點關閉之前重新開啟兩小時。
![\[具有多個覆寫類型的操作時數覆寫範例。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/hours-of-operation-overrides-example-3.png)
**注意**
測試任何會影響客戶的組態，以確保它們產生所需的結果。
**檢視覆寫的稽核歷史記錄**
覆寫的稽核歷程記錄會出現在**營業時間**頁面上，與標準營業時間稽核歷程記錄不同。每個稽核記錄都是指相關操作記錄時數的 ID。
![\[操作時數會覆寫稽核歷史記錄表。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/hours-of-operation-overrides-audit-history.png)
**注意**
AWS CloudTrail 會追蹤所有資源變更的歷史記錄。如需詳細資訊，請參閱使用 AWS CloudTrail 記錄 Amazon Connect API 呼叫。
# 檢視說明有效營業時間的行事曆
您可以在行事曆中一起檢閱操作時數和覆寫。選取詳細資訊頁面頂端的在**行事曆中檢視**按鈕。
![\[有效營業時間的行事曆檢視。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/hours-of-operation-calendar-view.png)
選擇天、週或月，以查看營業時間和營業時間。覆寫名稱會在適用時提供。
# 在 Amazon Connect 中建立轉接設定檔，將佇列連結至客服
本主題適用於管理員和聯絡中心管理員。它說明如何使用 Amazon Connect 管理員網站建立路由設定檔。如需用來以程式設計方式建立和管理轉接設定檔的 API，請參閱 [用於建立和管理轉接設定檔的 API](#apis-routing-profiles)。
佇列是聯絡人的「等待區域」，轉接設定檔則是佇列與客服人員的連結。在您建立轉接設定檔時，您需要指定：
+ 頻道：哪些頻道 (語音、聊天、任務和電子郵件) 轉接至此客服群組；是否同時允許這些頻道。
+ 佇列：轉接設定檔中有哪些佇列；是否應將一個佇列優先於另一個佇列。
每個客服人員都會被指派一個轉接設定檔。如需有關轉接設定檔和佇列的詳細資訊，請參閱 [Amazon Connect 如何使用轉接設定檔](concepts-routing.md)。
**我可以建立多少個轉接設定檔？** 若要檢視**每個執行個體轉接設定檔**的配額，請開啟 Service Quotas 主控台，網址為 [https://console.aws.amazon.com/servicequotas/](https://console.aws.amazon.com/servicequotas/)。
**建立轉接設定檔**
1. 在導覽功能表上，選擇**使用者**、**轉接設定檔**、**新增轉接設定檔**。
1. 在**轉接設定檔詳細資料**區段的**名稱**方塊中，輸入可搜尋的顯示名稱。在**描述**方塊中，輸入設定檔的用途。
1. 在**頻道設定**區段中，輸入或選擇下列資訊：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/routing-profiles.html)
1. 在**佇列**區段中，輸入下列資訊：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/routing-profiles.html)
1. 選擇性地新增標籤，以識別、組織、搜尋、篩選及控制誰可以存取此轉接設定檔。如需詳細資訊，請參閱[在 Amazon Connect 中將標籤新增至資源](tagging.md)。
1. 選擇 **Save** (儲存)。
## 頻道和並行數量的設定提示
+ 使用**頻道可用性**來切換指派給設定檔的客服是否取得語音、聊天、任務和電子郵件聯絡人。
例如，有 20 個佇列指派給某個描述檔。所有佇列都已啟用語音、聊天、任務和電子郵件。藉由移除在轉接描述檔層級的**語音**選項，您就可以在描述檔中的所有佇列中停止對這些客服人員的所有語音通話。當您想要重新啟動這些客服人員的語音聯絡案例時，請選擇**語音**。
+ 使用**跨通道並行**處理時，Amazon Connect 會檢查提供客服人員的聯絡人，如下所示：
1. 它會檢查客服人員目前正在處理的聯絡人/頻道。
1. 根據他們目前處理的頻道，以及客服人員轉接描述檔中的跨頻道組態，判斷客服人員是否可以轉接下一個聯絡人。
1. 如果優先順序和延遲相等，Amazon Connect 會優先處理等待時間最久的聯絡人。即使它同時評估多個頻道，仍然採取先進先出。
請參閱 [使用跨通道並行路由聯絡人的範例](#example-routing-concurrency)。
+ 針對設定檔中的每個佇列，選擇要用於語音、聊天、任務、電子郵件，還是所有頻道。
+ 如果您希望佇列同時處理語音、聊天、電子郵件和任務，但想要為每個頻道指派不同的優先順序，請新增佇列兩次。例如，在下圖中，語音是優先順序 1，但聊天、任務和電子郵件是優先順序 2。
![\[佇列組態顯示兩個具有不同頻道和優先順序設定的 BasicQueue 項目。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/set-channels-and-concurrency-2.png)
## 使用跨通道並行路由聯絡人的範例
例如，假設客服人員已指派給具有下列影像中所示頻道設定的路由描述檔。它們可以轉接語音，聊天、任務和電子郵件聯絡人。他們可以在執行任務時接收跨頻道聯絡人。
![\[建立路由配置文件頁面，頻道設定部分。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/routing-profile-cross-channel-concurrency.png)
客服人員將會遇到下列路由行為：
1. 假設客服人員完全閒置。接下來，客服人員接受聊天並開始對其進行處理。同時，一個任務進入隊列。
+ 聊天設定為**不允許其他頻道**。
+ 因此，即使隊列中有任務，也不會將其提供給此客服人員。
1. 接下來，有一個在隊列中的聊天。
+ 該客服人員的最大聊天並發性為 2，因此他們被路由另一個聊天，總共 2 個聊天。客服人員繼續處理這兩個聊天。
1. 佇列中沒有其他對話。客服人員完成兩個聊天 (關閉 ACW)。
+ 隊列中仍有一個任務正在等待。
+ 此時，工作會提供給客服人員，因為它們再次完全閒置。客服人員會開始處理工作。
1. 另一個聊天進入隊列。
+ 任務設定為**同時允許其他通道**。因此，即使客服人員已經在處理任務，仍然可以為他們提供聊天。
+ 聊天被路由到客服人員，他現在同時處理 1 聊天和 1 個任務。
1. 現在有一個語音通話在隊列中。
+ 該客服人員仍在進行 1 個聊天和 1 個任務。
+ 即使**任務**設定為**同時允許其他頻道**，客服人員仍在處理 1 個聊天，而且聊天在**聊天**聯絡人上時，**會設定為無其他管道**。因此，語音通話不會路由至客服人員。客服人員繼續處理聊天和任務。
1. 客服人員完成聊天，但仍可處理工作。
+ 現在，由於仍然指派給客服人員的唯一聯絡人是工作，而**任務**設定為**同時允許其他頻道**，這表示可以為客服人員提供語音通話。
+ 客服人員接聽語音通話，現在同時處理語音通話和工作。
1. 現在隊列中有另一個任務。
+ 客服人員目前正在進行語音通話和工作。再一次，Amazon Connect 會檢查跨通道設定，並**在客服人員處於語音聯絡人時，語音設定為沒有其他通道**。
+ 由於客服人員正在進行語音通話，因此在使用語音通話完成之前，無法提供任何工作。
+ 此外，由於**任務**設定為**每位客服人員的最大聯絡人數上限**為 1，因此即使在客服人員處理語音通話之後，仍然不會提供工作，直到他們完成目前的工作。
## 用於建立和管理轉接設定檔的 API
使用下列 API 以程式設計方式建立和管理路由設定檔：
+ [CreateRoutingProfile](https://docs.aws.amazon.com/connect/latest/APIReference/API_CreateRoutingProfile.html)
+ [DescribeRoutingProfile](https://docs.aws.amazon.com/connect/latest/APIReference/API_DescribeRoutingProfile.html)
+ [UpdateRoutingProfileConcurrency](https://docs.aws.amazon.com/connect/latest/APIReference/API_UpdateRoutingProfileConcurrency.html)
+ [UpdateRoutingProfileQueues](https://docs.aws.amazon.com/connect/latest/APIReference/API_UpdateRoutingProfileQueues.html)
+ [UpdateRoutingProfileDefaultOutboundQueue](https://docs.aws.amazon.com/connect/latest/APIReference/API_UpdateRoutingProfileDefaultOutboundQueue.html)
# Amazon Connect 如何使用轉接設定檔
轉接描述檔會決定客服人員可以接聽哪些類型的聯絡案例，以及轉接的優先順序。
+ 每個客服人員都會被指派一個轉接設定檔。
+ 轉接描述檔可以有多個指派至其中的客服人員。
![\[顯示對應至轉接描述檔的客服人員群組的圖形。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/agents-routing-profile.png)
Amazon Connect 使用轉接描述檔，讓您可以大規模管理您的聯絡中心。若要快速變更客服人員群組的功能，您只需在下列位置進行更新：轉接描述檔。
## 預設轉接描述檔：基本轉接描述檔
Amazon Connect 包含名為 **基本轉接描述檔** 的預設轉接描述檔。搭配[預設流程](contact-flow-default.md)和預設佇列 (名為 **BasicQueue**)，它可為您的聯絡中心提供動力，因此您不需要進行任何自訂。因此您可以快速開始使用。
## 轉接描述檔連結佇列和客服人員
在您建立轉接設定檔時，您需要指定：
+ 客服人員將支援的頻道。
+ 客服人員將處理的客戶佇列。您可以使用單一佇列或多個佇列來處理所有來電的聯絡人。佇列是透過轉接設定檔連結到客服人員。
+ 佇列的優先順序和延遲。
下圖顯示對應至轉接描述檔的客服人員群組圖形。轉接描述檔會為客服人員指定多個頻道和佇列。
![\[顯示對應至轉接描述檔的客服人員群組的圖形。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/routing-profile-3.png)
# 從 Amazon Connect 執行個體刪除轉接設定檔
有三種方式可從 Amazon Connect 執行個體刪除路由設定檔：
+ Amazon Connect 管理員網站：在左側選單上，選擇**使用者**、**轉接設定檔**，然後選取刪除圖示。
![\[轉接設定檔頁面，刪除選項。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/delete-routingprofile.png)
**重要**
您無法復原已刪除的轉接設定檔。
+ [DeleteRoutingProfile](https://docs.aws.amazon.com/connect/latest/APIReference/API_DeleteRoutingProfile.html) API
+ [delete-routing-profile](https://docs.aws.amazon.com/cli/latest/reference/connect/delete-routing-profile.html) AWS CLI
# 在 Amazon Connect 中設定佇列型或技能型轉接
以下是設定以佇列為基礎的轉接的步驟概觀：
1. [建立佇列](create-queue.md)，例如，針對要用於轉接的每個技能建立一個佇列。
1. [建立轉接描述檔](routing-profiles.md)：
+ 指定此轉接描述檔支援的頻道。
+ 指定佇列：頻道、優先順序和延遲。
1. [設定客服人員的設定](configure-agents.md)以將轉接描述檔指派給他們。
[建立流程](create-contact-flow.md)時，您會將佇列新增至其中。例如，如果聯絡案例選擇以西班牙文與客服人員交談，系統會將這些聯絡案例轉接至西班牙文保留區佇列。
如需有關轉接運作方式和以佇列為基礎的轉接的資訊，請參閱下列主題：
+ [轉接如何與多個頻道搭配運作](about-routing.md#routing-profile-channels-works)
+ [將客戶轉接至特定聯絡中心客服人員的佇列型轉接](concepts-queue-based-routing.md)
# 根據客服熟練度在 Amazon Connect 中設定轉接
以下是根據客服熟練度設定轉接的步驟概觀：
1. [建立將聯絡轉接至客服人員的預先定義屬性](predefined-attributes.md)
+ 您可以建立您要用來做出轉接決策的預先定義屬性。在下一個步驟中，您可以個別使用預先定義的屬性，也可以使用 `AND` 或 `OR` 運算子來組合它們，以形成轉接步驟。
1. [將熟練度指派給 Amazon Connect 執行個體中的客服人員](assign-proficiencies-to-agents.md)
+ 您可以選取預先定義的屬性，並將與客服建立關聯。所有符合相同佇列中聯絡人轉接步驟需求的可用客服人員都會被視為相配。
1. 設定轉接條件
+ 使用 [設定轉接條件](set-routing-criteria.md) 流程區塊，手動或動態設定轉接條件。
1. 轉接至佇列
使用 [轉接至佇列](transfer-to-queue.md) 流程區塊，將聯絡人轉移至佇列。在轉移聯絡人之後，Amazon Connect 會執行轉接條件。
![\[精通度轉接 4 步驟圖表。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/proficiency-routing-chart.png)
## 使用客服人員熟練度進行轉接的範例
假設聯絡人進入佇列**一般波入佇列**輸入佇列，而客服人員 1 和客服人員 2 則可使用的案例。一位會說法文的客戶正在尋求 AWS DynamoDB 相關的協助。這是他們第二次針對相同問題致電，您希望將他們與 AWS DynamoDB 的專家配對。為了保留客戶體驗，您想要實作下列轉接要求：
+ 首先前 30 秒尋找熟練**法文 (>=4)**，以及 **AWS DynamoDB 專家 (> = 5**) 的客服人員。
+ 如果目前找不到客服人員，請在接下來的 30 秒內尋找熟練**法文 (>=3)** 且熟練 **AWS DynamoDB (>=** 5) 的客服人員。對法文的要求放寬，以進一步擴大符合條件的客服人員，以滿足有關要求。
+ 如果此時未加入，請尋找熟練**法文 (>=3)** 且熟練 **AWS DynamoDB (>=4)** 的客服，並繼續尋找，直到找到客服為止。在此，AWS DynamoDB 要求已放寬，以擴展符合要求的合格客服人員人員集合。
**注意**
對於法規或法規遵循使用案例，您可以使用到期計時器的**永不過期**選項，以確保加入聯絡的任何客服人員都符合最低要求。
**若要將聯絡人轉接到上述要求，請完成下列步驟：**
1. **建立預先定義的屬性**：例如，在**使用者管理**、**預先定義的屬性**中新增 `Technology` 作為預先定義的屬性，並搭配 `AWS DynamoDB` 作為其中一個值。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/proficiency-routing.html)
**注意**
**連接：法文** 已作為系統屬性**連接:語言**中的值為預先定義的屬性使用。您可以在轉接條件中使用此選項。您也可以將最多 128 種客戶語言新增為**連接:語言**的值。
1. **建立熟練度與使用者的關聯**：有 2 個客服人員 (Agent1 和 Agent2)，他們會說法文且熟練使用 AWS DynamoDB，如下所示。在**使用者管理**中，**顯示進階設定**會將下列熟練度與客服人員 1 和客服人員 2 建立關聯。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/proficiency-routing.html)
1. **設定轉接條件**：使用此流程區塊來手動或動態建立下列轉接條件，方法是使用透過調用 Lambda 函式建立的 JSON，如潛在撥入流程中所示。建立下列轉接條件：
1. 步驟 1：connect:Language(connect:French) >=4 **AND** Technology (AWS DynamoDB) >=5 **[30 秒]**
1. 步驟 2：connect:Language(connect:French) >=4 **AND** Technology (AWS DynamoDB) >=4 **[30 秒]**
1. 步驟 3：connect:Language(connect:French) >=3 **AND** Technology (AWS DynamoDB) >=4 **[永不過期]**
下圖顯示為了依客服熟練度進行轉接而設定的撥入流程範例。此流程包含下列區塊：[AWS Lambda 函數](invoke-lambda-function-block.md)、[設定轉接條件](set-routing-criteria.md)、[設定工作佇列](set-working-queue.md)、[轉接至佇列](transfer-to-queue.md) 和 [中斷連線 / 掛斷](disconnect-hang-up.md)。
![\[為了依客服熟練度進行轉接而設定的流程。\]](http://docs.aws.amazon.com/zh_tw/connect/latest/adminguide/images/proficiency-routing-example-flow-block.png)
1. **轉移到佇列**：在聯絡人轉移到「一般撥入佇列」之後，Amazon Connect 會立即開始執行轉接條件。在聯絡人加入 Agent1 之前，將會執行下列步驟。
1. **轉接步驟 1**：由於前 30 秒 (不相符) 兩個客服的 AWS DynamoDB 熟練度都未 >= 5，Amazon Connect 將不會與任何客服配對。
1. **轉接步驟 2**：在接下來的 30 秒內 (不相符) 因為兩個客服人員都不同時精通 (>=4) 法文和 AWS DynamoDB
1. **轉接步驟 3**：上一個步驟過期後，Amazon Connect 就會立即尋找可用的客服，Agent1 (法文 3、AWS DynamoDB 4) 精通法文且熟練使用 AWS DynamoDB。因此，聯絡人會與 Agent1 比對。
「佇列的即時指標結果」表格中的[只要按一下即可向下深入](one-click-drill-downs.md)，顯示佇列中有效聯絡人所使用的轉接步驟清單。您可以在 [Amazon Connect 中的指標定義](metrics-definitions.md) 下找到轉接步驟特定指標的定義。
## 聯絡人記錄、聯絡事件串流和客服事件串流更新，用於客服熟練度
列各節中已新增熟練度轉接的模型：
+ [Amazon Connect 聯絡人記錄的資料模型](ctr-data-model.md)
+ [Amazon Connect 中的客服人員事件串流資料模型](agent-event-stream-model.md)
+ [聯絡人事件資料模型](contact-events.md#contact-events-data-model)
## 常見問答集
+ **佇列是否仍然相關？**
+ 是，佇列仍實屬必要。轉接條件只有在聯絡人排入佇列時才會啟動。客服人員熟練度可額外控制佇列中的特定客服人員。
+ **我們什麼時候應該將特定項目建模為熟練度而不是佇列？**
+ 這屬於商業決定。在使用客服人員熟練度時，您應該考慮對消除和合併的佇列數量的影響。
+ **客服熟練度是否跨所有頻道都適用？**
+ 是，使用客服熟練度的轉接適用於所有頻道。
+ **如何移除轉接條件？**
+ 您可以使用客戶佇列流程中斷轉接條件。
+ 您也可以使用這種方式更新轉接條件。
+ **我可以對排入佇列的聯絡人變更轉接條件多少次？**
+ 您可以無限次變更轉接條件。不過，只有最新的 3 個轉接條件更新會存放在聯絡人記錄中。
+ **在客服熟練度下，佇列優先順序和延遲是否會正常運作？**
+ 是，佇列優先順序和延遲會如在非客服熟練度環境中一樣操作。
+ **建立轉接條件支援的運算子？**
+ 以下是支援的布林運算子：
+ AND
+ 或
+ 支援下列比較運算子：
+ >=
+ 您也可以定義最低和最高熟練度層級的範圍，例如：
+ connect:English(1-3)
+ connect:Chat(4-4)
+ 您無法在運算式中多次使用相同的屬性。例如，不允許 connect:English(1-3) AND connect:English(5-5)。
+ NOT (用於排除) - 在轉接時，您可以使用 NOT 運算子排除具有特定熟練度的客服，例如：
+ NOT connect:French(1-5)
+ **哪些字元可用於預先定義的屬性？**
+ 預先定義的屬性名稱和值的樣式為 `^(?!(aws:|connect:))[\p{L}\p{Z}\p{N}_.:/=+-@']+$`。例如，它可以包含任何字母、數值、空格或 `_.:/=+-@'` 特殊字元，但不能以 `aws:` 或 `connect:` 開頭。
+ **我可以在轉接條件中多次新增相同的屬性嗎？**
+ 是，您可以在轉接條件中多次使用相同的屬性。
+ **觸發轉移 (快速連線) 時，是否可以設定轉接條件？**
+ 您可以在移轉流程中使用 [設定轉接條件](set-routing-criteria.md) 區塊，在轉移的聯絡人區段上設定轉接條件。加入客服人員後，無法將先前聯絡人的轉接條件轉移至新聯絡人區段。
+ **如果聯絡人在轉接前，將佇列傳送到佇列，轉接條件會發生什麼情況？**
+ 如果聯絡人在加入客服前已被轉移，則轉接條件會從新佇列中的第一個步驟開始。為此，我們會將先前聯絡人的轉接準則轉移至由於佇列轉移而建立的新聯絡人區段。
+ **聯絡人記錄是否具有相符客服熟練度的快照？**
+ 否，聯絡人記錄不會包含客服的熟練度。
+ 客服事件串流會有客服加入時的熟練度快照。
+ **我們是否可以使用 API 依熟練度搜尋客服？**
+ 否，不支援。
+ **如果我們刪除作用中聯絡人上的屬性，會發生什麼情況？**
+ 您可以刪除有效聯絡人所使用的屬性。不過，任何具有該屬性的轉接步驟都將找不到相符的客服，且聯絡人會留在佇列中，直到轉接條件到期為止。
+ 具有該屬性的所有新聯絡人都會開始在流程中的 [設定轉接條件](set-routing-criteria.md) 區塊上取得錯誤分支。
+ **當客服人員拒絕通話時，轉接條件步驟/到期時會發生什麼情況？**
+ 轉接會在客服人員接受聯絡人並完成連結時，將連接視為完成。當客服拒絕聯絡人時，轉接引擎會繼續執行轉接條件，計時器會持續執行。
+ **當轉接再次執行時，拒絕該步驟的客服人員是否會成為集區的一部分？**
+ 是，當轉接再次執行時，客服會繼續成為集區的一部分。
+ **歷史指標是否可用？**
+ 否，分析中未提供歷史指標。
+ 聯絡人記錄、客服事件串流和聯絡人事件串流包含所有必要的資訊。
+ **我在何處可以找到用於設定轉接標準的 Lambda 函數範例？**
+ 如需設定轉接條件的 Lambda 函式範例，請參閱[設定轉接條件的 Lambda 函數範例](set-routing-criteria.md#set-routing-criteria-sample-lambda-function)。
+ **如果聯絡人轉移到客服佇列，在聯絡人上設定的轉接條件會發生什麼情況？**
+ 轉接條件不會影響存在於客服佇列中的聯絡人。如果具有轉接條件的聯絡人從客服佇列轉移至標準佇列，則轉接條件會轉送至由於佇列轉移而建立的新聯絡人區段。