在具有小組指派的非技術佇列中，您可以將代理組織成小組，然後將這些小組組合成通話分派群組 (CDG)。 您可以設定每個群組之間的延遲時間以管理通話流程。

通話分派群組可協助定義多個代理層級，這些代理在設定的時間間隔內有資格處理此佇列中的聯絡人。 聯絡人根據其小組的層級指派給代理。 如果沒有代理可用，則聯絡人將駐留預先設定的持續時間，然後再擴展以包含下一組小組。 此過程會繼續，直到代理可用或檢查完所有群組為止。

您可以設定以下類型的團隊：

• 各個小組： 代理可以組織成代表特定組織職能的小組，然後可以成為佇列的一部分，以便可以將聯絡人路由到這些小組中的代理。 您可以將一個代理標記為多個小組，以處理來自不同佇列的聯絡，以實現高效的路由。
• 基於容量的團隊： 基於容量的團隊 (CBT) 是一項將語音呼叫定向到基於容量的直接號碼 (DN) 的功能，在該號碼中，容量決定了可以同時處理的呼叫數。 它支援將通話路由到電話號碼，而無需代理登入系統，使其適用於通過語音郵件、應答機或搜尋群組 (而非傳統呼叫中心代理) 應答通話的方案。 在此設定中，沒有為團隊指派特定的客服，他們不使用 Webex Contact Center Agent Desktop.

在此範例中，有三個通話分派群組，它們允許目標擴展，這意味著在設定的時間間隔內跨團隊擴展到更多代理。

第一個通話分派群組包含小組 1，該小組已設定 3 個代理–A1、A2 及 A5。

第二個通話分派群組包含 TEAM 2，其中配置了 3 個代理–A2、A3 及 A4。

第三個 (也是最後一個) 通話分派群組包含 TEAM 3，其中配置了 2 個代理–A6 和 A7。

聯絡人排入佇列時，系統會先在第一個通話分派群組中搜尋符合的代理。 若未找到客服，則在將目標展開至下一個群組之前，會將聯絡人駐留配置的持續時間。 這會在現有團隊的基礎上添加新團隊。 重複此過程，直到找到匹配項或展開所有組。

「檢查代理可用性」功能使得聯絡人若在目前群組中找不到符合的代理，會立即擴展到後續的通話分派群組。 這可以在流程中的佇列聯繫人活動<連結到部分 3.1.1> 中啟用。

此設定會導致以下情況：

1. A2 屬於團隊 1 和團隊 2。如果 A2 選擇小組 1 登入 Agent Desktop，則系統會將 A2 視為小組 1 的一部分，因此只會視為第一個通話分派群組。
2. 但是，A5 屬於 TEAM 1，也可能是他們當前登錄的組織中其他團隊的一部分。因此，A5 不被視為團隊 1 的一部分，並且不與此佇列關聯。

具有團隊指派的佇列提供了如此強大的功能，代理只需在登入時選擇團隊即可在佇列之間移動。

可用的路由型式：

• 最長可用

非技能型佇列是指派代理池直接指派給佇列的佇列類型。 與其他佇列類型 (間接確定指派給它們的代理池) 不同，這些佇列允許管理員直接及手動選擇代理。 例如，小組指派佇列根據代理的登入小組指派代理，而技術指派佇列則根據所需的專長比對代理。 相反的，管理員可以直接將客服新增到這些佇列中而成為佇列的一部分。 這為管理代理分配提供了一種直接的方法，而無需依賴系統驅動的分配。

具有代理指派的佇列提供簡單而有效的路由演算法，有助於在代理池之間分配聯絡。 他們不考慮代理路由聯絡的專長。 但可以在每個佇列中排序代理，在將聯絡人路由到代理時會考慮這一點。 在此上下文中，團隊主要充當監督人員的組織結構，而不是簡化佇列管理的客服 - 佇列關聯和聯繫人路由決策中的一個因素。

這種類型的佇列最適合於以下情況：代理的靜態分配和代理 - 佇列關聯的管理對於操作控制是可行和可取的，並且路由演演演算法的選擇適用於代理之間的工作分配。 對於多種類型的客戶查詢需要專業知識的情況，這些佇列也特別有用，這些專業知識可以由預先創建的專家代理部分提供服務。

但是，複雜的聯絡中心組織可能會發現，手動管理這些佇列中的代理指派變得困難。 他們可以從提供動態路由和代理 - 佇列關聯的其他佇列類型中獲益更多。

在此範例中，佇列中有一組按特定順序 (如 A4、A9、A7 等) 對應的代理。 此順序在將來電聯絡人與代理比對的特定路由演算法中發揮作用。 系統會根據聯絡人的可用性和所選的路由演算法將這些聯絡人與這些代理進行配對。

與具有團隊分配的佇列不同，沒有目標隨時間間隔擴展 的概念 。 如果所設定的代理皆無法路由此聯絡人，其將一直駐留在佇列中，直到其中一個代理在駐留逾時之前可以處理聯絡人。 目標擴展 不適用於這些佇列。

可用的路由型式：

• 最長可用
• 圓
• 線性/自上而下

管理員可以為佇列指派技能條件。 具有技能條件的技能佇列允許管理員直接在佇列中配置所需的技能。 組織中所有透過直接技術設定檔具備佇列所有必要技能的代理，都會隱式加入此佇列。

此設置可説明管理員憑藉技能即時查看映射到佇列的代理。 在高容量或低容量等情況下，管理員可以考慮調整佇列所需的技能和代理技能配置檔，以根據需要擴展或收縮代理池。

此類型的佇列與基於團隊指派的佇列不同，因為不存在通話分派群組設定，這意味著團隊在代理與佇列的關聯中不扮演任何角色。 此外，所需的技能在此佇列中靜態配置，這與基於團隊的技術佇列不同，在基於團隊的技能佇列中，流注入 (靜態或可變) 所需的技能。 因此，從技術上講，技能是佇列的一部分，而不是聯繫人本身。

組織中完全滿足佇列技術條件 (具有直接技術設定檔中的技能) 的任何代理都會隱式與此佇列關聯。 小組在與這些佇列的客服關聯中不扮演任何角色。 出於管理和運營目的，這些代理可以是任何團隊的一部分。

排入此佇列的每個聯絡人都將自動採用佇列中定義的技術標準。 單個聯繫人無法定義或覆蓋自己的技能要求/條件，這與具有團隊指派的基於技能的佇列不同。

在此範例中，

• 僅代理 A1、A3 及 A7 完全符合佇列中設定的技術標準，因此只有這些代理會與此佇列關聯。
• 部分符合條件的代理 A2、A4 及 A6 或是缺少相關技能的 A5 無法與此佇列關聯。

更新代理的技術設定檔 (稱為技術重設) 使其符合佇列的技術條件，會自動動態地使該代理成為此佇列的一部分。 或者，更新佇列技術條件本身，使更多 (或更少) 代理滿足更新的技術條件，亦會自動動態地在此佇列中新增 (或移除) 代理。

與具有團隊分配的佇列不同，沒有目標隨時間間隔擴展 的概念 。 如果聯絡人無法與任何關聯的代理配對，則會將其駐留在佇列中，直到其中一個代理在駐留逾時之前可以處理聯絡。

基於技能的佇列最適合於靜態技能指派和佇列到代理關聯管理可行且需要操作控制的情況。 當路由演算法的選擇適合於代理之間的工作分配時，它們也適用。 這些佇列對於不同類型的客戶查詢需要特定技能的情況也特別有用，這些技能可以由預先派生的專家代理部分提供服務。

複雜的聯絡中心組織可能會發現，與具有代理分配的佇列 (必須手動將每個代理添加到清單中) 相比，在基於技能的佇列中管理佇列到代理的分配更容易，這對於大型組織尤其麻煩。

在流程中分配了技能要求的基於技能的佇列是 Webex Contact Center 中的一種基於團隊指派的佇列，其中一組團隊配置為多個級別，稱為通話分派組。 若登入這些設定小組的代理也完全符合聯絡人的技能要求，則會根據其小組在佇列中設定的通話分派群組層級，從此佇列指定聯絡人。

在此類佇列中，代理小組被分組為多個通話分派群組，它們之間具有可設定的時間延遲。 若無代理可接聽聯絡人，該請求將會駐留，且在延遲之後，路由將擴展至下一個通話分派群組。 此過程會繼續，直到指派代理或耗盡所有群組為止。 同時，如果先前核取的群組中的代理在此過程中變為可用，則會選取該代理。

代理透過直接指派給代理的技能設定檔取得技能。 代理專長根據登入期間的團隊選擇確定。

每個聯絡人都可以選擇在流程中指定技能需求，這些需求與可用座席的技術相匹配，以選擇最合適的座席。

此外，聯絡人還可以按設定的時間間隔指定技能放鬆。 這些是一組經過修改的技術要求，在設定的時間間隔後會覆寫聯絡活動的原始技術要求。 這允許駐留在佇列中的聯絡人修改 (通常用於“放寬”) 其技能要求，以便更多代理可以符合這些寬鬆的技能要求。

通過呼叫分派組擴展目標可以與技能放鬆週期同時進行 - 兩者都旨在更快地將駐留的聯繫人與符合條件的代理匹配，從而減少總體等待時間並提高佇列的服務級別。

與具有團隊分配的非技術佇列一樣，它具有三個呼叫分配組，允許“目標擴展”，即在配置的時間間隔內擴展到跨團隊的更多代理。

• 第一個通話分派群組包含 TEAM 1，該團隊配置了 3 個代理–A1、A2 和 A5。
• 第二個通話分派群組包含 TEAM 2，其中配置了 3 個代理–A2、A3 及 A4。
• 第三個 (也是最後一個) 通話分派群組包含 TEAM 3，其中配置了 2 個代理–A6 和 A7。

但是，有兩件主要事情需要注意：

• 排入此佇列的每個聯絡人都將定義其技能要求，並在整個流程中放鬆技能。
• 代理可以配置技能 (通過技能配置檔 - 直接或繼承自登錄團隊)。

雖然 A2 設定為小組 1 與小組 2 的一部分，但根據此代理在登入期間選擇的小組而定，在其目前的作業階段中，他將被視為該小組的一部分，因此也將從該小組繼承技術設定檔 (以及技術值)(除非此代理的直接技術設定檔組態已覆蓋此設定) 。

這是具有團隊指派的佇列所提供的強大功能，客服只需在登入期間選擇團隊即可在佇列之間移動。

再加上從所選團隊繼承技能設定檔設定的能力，代理也可以使用不同的技術組合。

在此範例中，

• 從流程升級期間，初始技能需求 (sk_1 >= 6) 的聯絡人排入佇列，在設定的時間間隔後技能放鬆 (sk_1 >= 3)。
• 在所有通話分派群組的所有代理中，僅 A1、A3、A6 及 A7 具備滿足佇列聯絡之初始技能需求的技能。
• 其餘的代理要麼具備技能 (sk_1)，但不滿足技能要求 (例如，團隊 1 中的 A2 和團隊 2 中的 A4)，要麼根本不具備此技能 (例如團隊 2 中的 A5、A2)。
• 隨著時間的推移，在技能放鬆后，A2 和 A4 現在也滿足聯繫人的“放鬆”技能要求。

對於排入此佇列的每個聯絡人，系統會嘗試在第一個通話分派群組中尋找完全滿足該聯絡人目前技能要求的相符代理。 若找不到符合的代理，則在第二個通話分派群組進行目標展開之前，該聯絡人將駐留設定的持續時間。 在第二個通話分派群組中設定的所有小組亦會從第一個群組新增到現有的小組。 現在系統嘗試在展開的組中查找匹配的代理。 請注意，當此功能發生時，技能放鬆也會按設定的時間間隔更新聯絡人的技能要求，而且系統會使用更新的技能要求來符合目前通話分派群組中的可用代理。

此操作會一直持續到所有設定的通話分派群組展開，並且套用所有技能放鬆為止，除非之前找到相符的代理。

可用的路由型式：

• 最長可用
• 最佳可用

當可用代理的數量多於佇列中的聯絡人數時，會發生代理過剩情況。 在這種情況下，當客戶互動 (聯繫人) 排隊時，系統會立即嘗試為此特定聯繫人查找匹配的代理，如果找到匹配的代理，則無需將聯繫人駐留在佇列中並等待匹配的代理稍後可用。

每次聯絡人透過通話分派群組進行擴充，或透過放鬆技能，系統都會再次嘗試立即為此特定聯絡人找到相符的代理。

為特定聯絡人尋找符合的代理時，會使用佇列中所設定的路由型式。

Webex Contact Center 提供跨不同類型的佇列的多種路由模式，使組織能夠通過最大限度地減少等待時間、平衡代理工作負載並確保客戶與具有滿足其特定需求的必要技能的代理連接來優化客戶服務。 有關路由型式的詳細資訊，請參閱路由型式部分。

當傳入的客戶互動 (或聯絡) 數量超過可用座席時，就會發生聯絡剩餘路由。 這種情況通常發生在高峰時段或接觸量意外激增期間。 聯繫剩餘路由的主要目標是有效地管理這種溢出，確保在需求過剩的情況下保持客戶服務標準。 對於剛剛加入特定通道的代理，聯絡人剩餘路由的工作是在此代理關聯的所有佇列中，在所有駐留的聯絡人中，尋找並指派適當的聯絡人。

在代理可用性有限的情況下高效執行聯絡人路由的關鍵策略包括：

• 佇列排名

  佇列排名使管理員能夠指定佇列的相對重要性。 管理員可以定義佇列排名，以設定每個團隊的通話從佇列路由到登入團隊的客服的順序。

  例如，假設登入小組 A 的代理與「帳單」與「銷售」兩個佇列相關聯。 管理員可以使用佇列排名為「帳單」佇列分配更高的排名，這樣當聯絡人進入佇列時，「帳單」中的聯絡人將被路由到小組 A 的代理，然後再路由到「銷售」佇列中的聯絡人。 即使可能有較老和優先順序較高的聯繫人可能正在「銷售」佇列中等候 - 僅僅因為「計費」佇列的佇列排名高於「銷售」佇列，也會發生這種情況。 僅當「帳單」佇列中不再有等候聯絡時，系統才會將小組 A 中的代理路由至與其關聯的「銷售」（及任何其他）佇列中的聯絡。

  以下是佇列排名的一些重要特徵：

  • • 如果等級僅指派給某些佇列，則這些佇列中的通話將優先於未指定等級的佇列中的通話。
    • 在所有媒體類型中，最多可以對 50 個佇列設置佇列排名，值範圍介於 1 到 50 之間，其中 1 為最高排名。
    • 您可以將相同的等級指派給多個佇列。
    • 如果啟用佇列排名，則未分配任何顯式排名的佇列將被視為低於所有排名佇列。

    • 佇列排名在相同的媒體類型中運作。

      例如，如果「佇列銷售」是排名為 2 的語音媒體類型佇列，而「佇列計費支援」是小組 A 的聊天佇列，則即使排名為 2，小組 A 中語音通道上可用的代理還是會先收到語音通話。

      但是，請考慮團隊 B 的兩個聊天佇列 - 佇列排名為 2 的佇列信用卡和佇列排名為 1 的佇列轉帳卡。然後，將首先向團隊 B 中的可用代理提供佇列轉帳卡中的聯繫人。

    • 佇列排名不適用於基於容量的團隊。

• 聯絡人優先順序

  聯絡在佇列中時，可透過指定從 1 (最高) 到 10 (最低，預設值) 的層級重要性來定義其優先順序。 此優先順序可確保根據某些聯繫人的重要性、緊迫性或對組織的戰略價值更快地處理這些聯繫人。 當代理可以處理其關聯的所有佇列中所有駐留聯絡人中的下一個聯絡人時，所有佇列中最高優先順序的聯絡人會路由給代理 (前提是滿足其他條件，例如技能符合等條件)。

  對於佇列中無任何明確優先順序的聯絡，預設優先順序為 10 (最低)。 在多個具有相同優先順序的聯絡中，佇列中等待時間最長的聯絡會先路由到可用且合格的代理。

• 等待最久的聯絡

  此為基本原則，可確保所有佇列中等待時間最長的聯絡人路由至代理。

  當佇列中具有相同佇列等級及相同聯絡人優先順序的多個聯絡人正在等待處理時，此為最終準則。

實際上，對於剛有空的代理而言，聯絡人剩餘路由意味著選擇符合以下條件的單個聯絡人：

• 的媒體類型與代理可用的媒體類型相同
• 駐留在此代理關聯的任一佇列中
• 此代理全部滿足其技能要求 (如果有)
• 駐留在其等級高於代理小組中設定的其他佇列的佇列中
• 在所有此類聯絡中具有最高優先順序
• 是相同優先順序的聯絡中等待最久的聯絡

在上面說明聯絡人剩餘情景的範例中，代理 A1 已登入 TEAM 1 並可處理多種媒體類型的聯絡。

A1 與 3 個佇列相關聯– Q1、Q2 和 Q3 。 TEAM 1 還定義了佇列排名，其中 Q1 排名最高，然後是 Q2 和 Q3 。

所有這些佇列中已駐留聯絡，但為每個聯絡定義了技能要求和優先順序。

現在，聯繫人剩餘方案的工作原理如下：

• 在這些佇列中所有駐留的聯絡人中，只有 4 個聯絡人可以路由至 A1 – C2 、C7 （從佇列 2）和 C3 、C8 （ 從佇列 3）。

  只有這 4 個聯繫人的技能要求才能完全滿足 A1 的技能。

• 在這 4 個聯絡中，來自佇列 2 （即 C2、C7）的聯絡人 優先，因為 佇列 2 的佇列排名較高。

  請注意，即使 佇列 1 是排名最高的佇列，也無法將駐留的聯絡人路由到 A1，因為 A1 無法滿足他們的技能要求。

• 在 C2 和 C7 之間 ，最高優先順序的聯絡活動是 C7。 因此，最終選擇是 C7，系統將其路由到 A1。

  即使 C2 較早排入佇列，也會發生這種情況，因為聯絡人優先順序優先於排入佇列的時間。

透過多媒體設定檔組態，Webex Contact Center 允許代理跨不同媒體類型 (語音、聊天、電子郵件和社交) 為聯絡人提供服務。 基於此配置，代理將獲取每種媒體類型配置的通道。

只要代理正在處理該聯絡，路由至代理的每個聯絡都會使用該媒體類型的一個通道。 代理只能有一個語音通道，但最多可以有五個其他媒體類型的通道。

多媒體設定檔 中的 混合路由設定允許管理員控制如何為每個代理同時使用不同的通道。 這使組織能夠為客戶提供專門的關注，促進更好的服務品質、改善的客戶體驗和更高的轉化率。 此外，當某些通道中的負載不均勻時，組織可以跨媒體通道平衡負載，從而有效地利用座席。

共有三種選擇：

• 排除 –代理一次只能處理任何媒體類型的一個聯絡。

  當組織期望代理一次完全專注於一項工作時，此功能很有幫助。

• 混合 –可以同時處理每種介質類型的任意數量的聯繫人，最多可達配置的通道容量。

  當組織期望代理執行多項工作並處理不同媒體類型的多個聯絡活動時，此功能很實用。

• 混合即時 –與混合相同，但語音和聊天是互斥的。 如果正在處理語音，則不會顯示聊天聯絡，反之亦然。

  當組織期望代理執行多項任務，但仍允許代理專注於單個“即時”聯繫人 (語音或聊天) 以便代理可以完全關注另一端的最終客戶時，此功能非常有用。

有關配置多媒體配置檔的詳細資訊，請參閱 管理多媒體配置檔。

Webex Contact Center 中基於技能的路由模式根據解決查詢所需的特定技能 (例如語言熟練程度或技術專長) 將傳入的客戶交互定向到代理。 這些模式可確保每個客戶都連接到最合格的座席，從而提高服務效率和客戶滿意度。 好處包括縮短處理時間、提高解決率，以及通過將座席的專業知識與客戶需求保持一致來優化座席資源的使用。

使用基於技能的路由型式時，首先使用聯繫人的技能要求 (在流程中分配) 或分配給佇列的技能標準來篩選技能完全滿足這些要求/條件的可用代理。 然後，在已過濾的代理中，會根據設定的路由型式為聯絡人選取一個代理。

Webex Contact Center 還支援各種非基於技能的路由模式，這些模式側重於分發傳入的客戶交互，而不考慮座席的特定技能或專業知識。 與基於技能的路由型式不同，這些路由型式不考慮座席技能，也不需要聯絡人或佇列來定義技能要求/路由條件。 相反，它們優先考慮可用性、工作負載分配和預定義序列等因素，從而允許基於操作邏輯而不是單個代理能力有效地處理聯繫人。 這些模式在交互相對統一或不需要專門處理的環境中特別有用。

代理型路由是將聯絡人直接路由或排入佇列至指定 (「偏好」) 代理的功能。 使用代理的電子郵件地址或代理的 ID 進行的代理查詢會將聯絡路由到首選的代理。 流程中的「佇列至代理」活動有助於實現基於代理的路由。 有關詳細資訊，請參閱 佇列到代理 活動。

聯絡人可以具有與一個或多個首選代理的映射，這些代理通常可以在 Webex Contact Center 之外的外部應用程式中進行管理。 聯絡人的首選代理查詢是透過 HTTP 請求 活動完成的，該活動會從外部應用程式擷取對應。 若要路由或駐留聯絡人與偏好的代理，請使用代理的 Webex Contact Center ID 或電子郵件地址設定「佇列至代理」活動。 如果首選代理不能立即可用，也可以針對該首選代理駐留該聯絡。

基於代理的路由在以下場景中非常有用：

• 首選座席路由：客戶可以將聯繫人分配給專門的座席或關係主管。 在這種情況下，基於代理的路由將聯繫人直接路由到該首選代理。
• 上次代理路由：當聯絡人多次回撥聯絡中心與代理互動時，代理型路由可以將聯絡路由到最後一位處理該聯絡的代理。

在這兩種使用案例中，聯絡人和代理對應的詳細資料都存儲在 Webex Contact Center 之外。

「聯絡人佇列」活動可讓您將聯絡人排入組織的活動入站佇列，以便匹配聯絡人並將其路由至該佇列中的正確代理。

可以通過此活動管理佇列的以下方面：

• 優先順序 - 為排隊的聯絡人指定從 1 (最高) 到 10 (最低，預設值) 的層級重要性。
• 技能要求 - 設定技能佇列中的代理必須滿足的技能條件，才有資格路由聯絡。
• 技能放鬆 - 在一段時間后調整、修改或刪除以前設置的技能要求，以提高找到代理的機會。
• 檢查代理可用性 - 允許系統在找不到可用代理的所有通話分派群組中立即展開，以避免等待時間。

有關優先順序、技術組態與代理可用性如何在路由聯絡中發揮作用的更多資訊，請參閱 路由。

一旦「連絡人佇列」活動成功地將連絡人排入佇列，

• 如果已經有符合的代理可用，系統會嘗試將聯絡人路由至代理。

  這會中斷 主流 執行，並且進一步的事件可以觸發相應的 事件流（如果已配置）。

• 如果找不到相符的代理，該聯絡人將駐留在佇列中，並等待相符的代理變為可用。

  然後，流程執行將繼續在「佇列聯絡人」活動之後附加的活動，從而提供以下功能：

  • 通過附加 PlayMusic 活動，向在佇列中等待的客戶播放預配置的音樂。
  • 根據客戶的請求註冊回調 - 通過附加 回 調活動。
  • 重新排隊，即從當前佇列中移除聯絡人並新增到新佇列 - 方法是附加另一個 佇列聯絡 人或 佇列到代理 活動。

當符合的代理可用時，系統會嘗試將聯絡人路由至該代理。

如果成功，這將中斷 主流 執行，並且其他事件可以觸發相應的 事件流（如果已配置）。

在這種情況下，活動會導致失敗，並且流執行將移動到 錯誤處理 路徑。

有關活動設置、使用方式和輸出變數的詳細資訊，請參閱 >佇列聯繫人構建和管理流。

「佇列至代理」活動可讓您在 Webex Contact Center 中尋找聯絡人的唯一代理 ID 或電子郵件地址，將聯絡人直接排入其佇列。

可以通過此活動管理佇列的以下方面：

• 優先順序 - 為排入同一代理佇列的聯絡指派較高/較低的重要性。
• 報告佇列 - 指定要用於配置的佇列，例如錄製和佇列中的預設音樂以及報告聯繫人的用途。
• 恢復佇列 - 確定在無法將聯絡人路由到指定的首選代理時用作後援的佇列。

在「佇列至代理」活動成功地將聯絡人排入佇列後，

• 如果代理已可用，聯絡將路由至代理。

  這會中斷 主流 執行，並且進一步的事件可以觸發相應的 事件流（如果已配置）。

• 如果代理可用，但選擇拒絕、不接聽或無法接收聯絡，則會將其移至提供的恢復佇列。

  在復原佇列中，聯絡將被路由至可用時間最長的代理，且沒有任何技能支援。

• 若代理不可用且選取 了「 若代理不可用則駐留聯絡人」選項，則該聯絡人將被駐留並等待代理轉接可用。

  然後，流程執行將繼續在「佇列到代理」活動之後附加的活動，從而能夠：

  • 通過附加 PlayMusic 活動，向在佇列中等待的客戶播放預配置的音樂。
  • 回 調活動。
  • 重新排隊，即將另一個 「連絡人」附加至「代理 」或 「連絡人 佇列」活動，以將其從目前佇列移除並新增至新佇列。

  代理變為可用後，系統會嘗試將聯絡人路由至代理。

  這會中斷 主流 執行，並且進一步的事件可以觸發相應的 事件流（如果已配置）。

• 若代理不可用且未 選取 「 若代理不可用，即駐留聯絡人」選項，佇列將會失敗。

在這種情況下，活動會導致失敗，並且流執行將移動到 錯誤處理 路徑。

有關活動設置、使用方式和輸出變數的詳細資訊，請參閱 生成和管理流>佇列到代理。

升級呼叫分派組活動僅支援 具有團隊分配的佇列，並且能夠立即更新聯繫人的 呼叫分派組 ，而不是在配置的等待持續時間後等待自動展開更新發生在下一個組。 這樣聯絡人可快速路由至佇列中所有符合條件的代理。

通過使用升級呼叫分配組活動，可以將聯繫人升級為：

• 下一個群組—擴展小組集，以包括新增到下一個通話分派群組中的小組。
• 最後一個群組 - 擴展團隊集，以包括針對佇列設定的所有通話分派群組之間對應的所有團隊。

在這種情況下，活動會導致失敗，並且流執行將移動到 錯誤處理 路徑。

假設有一個例子，其中聯絡人排入具有三個通話分派群組的佇列中，每個組在 30 秒後更新。

CDG 1 與 CDG 2 的小組部分 無代理可用，而屬於最後一個通話分派群組的 TEAM 3中有代理可用 。

如果在流程中未使用升級呼叫分派組活動，則會導致等待時間較長，如下圖所示：

使用「遞增呼叫分派組」活動可以縮短等待時間，如下所示：

根據 選取的「下一個群組 」或 「最後一個群組 」選項，聯絡人的等候時間會大幅減少，如下圖所示：

有關活動設置、使用方式和輸出變數的詳細資訊，請參閱 >升級呼叫分派組構建和管理流。

「取得佇列資訊」活動可讓您擷取給定聯絡人的即時佇列資訊，例如：

• 聯絡人目前在佇列中的位置 (PIQ)，或潛在位置 (如果尚未排入佇列)。
• 估計等候時間 (EWT) 或估計工作在接聽之前在佇列中等待的持續時間。
• 已登入或在聯絡人目前的通話分派群組中可用的代理數。
• 所選佇列中已登入或跨所有通話分派群組可用的代理數。
• 佇列中等待最久之聯絡人等待的時間長度。

這些詳細資訊在流執行中作為活動輸出變數提供。

有關每個佇列詳細資訊的活動使用方式、詳細定義和計算方法的詳細資訊，請參閱 生成和管理流>獲取佇列資訊。

使用佇列資訊的某些方式可以是：

• 在客戶等待路由時，向客戶宣布聯繫人在佇列中的位置和估計的等待時間。
• 確定是否可以為客戶註冊回調 (如果估計的等待時間太長)。
• 如果對應至目前 CDG 的小組中無代理可用，則將聯絡人升級至下一個通話分派群組 (CDG)。

在這些情況下，這些輸出欄位中的值 -1 指示此資訊不適用。

考慮一個示例方案，在佇列中每花費 15 秒，就應通知客戶佇列中的長 EWT。

這可以使用流中的「獲取佇列資訊」活動來實現，如下所示：

「進階佇列資訊」活動可讓您擷取給定聯絡人的即時佇列資訊，同時亦會考慮聯絡人的技能標準，例如：

• 聯絡人目前在佇列中的位置 (PIQ)，或潛在位置 (如果尚未排入佇列)。
• 已登入或聯絡人目前通話分派群組中，符合指定技能條件的代理數。
• 已登入的代理數，或所選佇列的所有通話分派群組中可用的代理數，符合指定的技術條件。
• 聯絡人駐留在所提供的佇列中的目前通話分派群組。
• 所提供的佇列中的通話分派群組總數。

這些詳細資訊在流執行中作為活動輸出變數提供。

有關每個佇列詳細資訊的活動使用方式、詳細定義和計算方法的詳細資訊，請參閱 構建和管理流>高級佇列資訊。

使用進階佇列資訊的某些方法包括：

• 在客戶等待路由時，向客戶宣布聯繫人在佇列中的位置。
• 如果對應到目前通話分派群組的小組中無符合技術條件的代理可用，則將聯絡人升級至下一個通話分派群組。
• 確定是否可以為所有呼叫分配組中登錄與技能條件匹配的代理註冊回調。

在這種情況下，活動會導致失敗，並且流執行將移動到 錯誤處理 路徑。

考慮一個示例方案，在該方案中，如果不符合技能條件的代理不可用，則應通知客戶收到回電。

這可以通過在流中使用高級佇列資訊活動來實現，如下所示：

「設定來電者 ID」活動用於定義應在通話期間顯示的來電者 ID。 「設置來電者 ID」活動只能在 PreDial 事件流上用作標記事件流結束的終端活動。

設定來電者 ID 活動允許根據撥打號碼識別服務 (DNIS)、操作類型或參與者類型設定所需的自動號碼識別 (ANI)。

有關活動設置、使用方式和輸出變數的詳細資訊，請參閱 構建和管理流>設置來電者 ID。

“錄製控制”活動旨在與“功能表”活動一起使用，以捕獲呼叫者的錄製同意。 這可確保在錄製開始之前遵守需要明確同意的法規或政策，並將此步驟無縫集成到工作流程中。

Menu IVR 活動必須將使用者的同意捕獲到布爾變數中，該變數將作為輸入分配給錄製控件活動。 如果客戶需要在同意報告中報告使用者同意，則同意值應存儲在可報告的全域變數中。 或者，如果不需要報告，則可以使用局部變數。 這種方法為租戶和客戶提供了有效管理和利用變數的更大靈活性。

將此活動添加到流時，使用者的同意優先於租戶級別或佇列級別或記錄計劃級別配置設置。

優先順序如下：

• 如果使用者同意在流中為“是”，則會記錄呼叫，而不考慮在租戶或佇列或錄製計劃級別設置的錄製配置。
• 如果使用者不同意作為對活動的回應，則無論在租戶或佇列或錄製計劃級別設置的錄製配置如何，都不會記錄呼叫。
• 如果未在流中配置“錄製控制”活動，但在任何其他級別 (如租戶或佇列或錄製計劃) 將配置設置為“是”，則會記錄呼叫。
• 如果未在流中配置“錄製控制”活動，並且所有級別 (如租戶、佇列和錄製計劃) 的配置都設置為“否”，則不會錄製呼叫。

此錄製控件可以說明如下：

此外，根據現有層次結構 (包括租戶、佇列或錄製計劃級別)，記錄配置 (如“轉移時繼續”、“啟用暫停恢復”、“暫停持續時間”等) 仍然適用。

有關活動設置、使用方式和輸出變數的詳細資訊，請參閱 >記錄控件生成和管理流。

秘密轉接是透過 IVR 系統將聯絡人高效路由到外部撥號號碼 (DN) 的過程，無需代理參與。

當必須將通話轉接到外部或第三方 DN 時，會使用「不明轉接」活動。 這是一個終端活動，因此一旦執行傳輸，流就會結束。

執行流進行諮詢時，不支援「不明傳輸」活動。

有關活動設置、使用方式和輸出變數的詳細資訊，請參閱 >不明傳輸生成和管理流。

橋接轉接活動允許將聯絡人臨時轉移到外部目標，同時流程保留對通話的控制。 外部目標可以是外部網橋或 Interactive Voice Response (IVR) 服務。

當外部目標結束通話時，通話流程將根據需要繼續，例如將其排入代理佇列。

「過橋轉移」活動會取消聯絡人的佇列，同時將其轉移到第三方 IVR 或自動通話分配 (ACD) 系統。 如果聯絡未被第三方系統處理，則可以將其重新排入原始佇列，確保聯絡人保留在工作流程中以進行適當處理。

例如，假設某個聯絡中心有 Webex Contact Center 代理資源與外部呼叫中心或專用交換機 (PBX) 上的代理資源。 客戶希望將通話與 Webex Contact Center 代理佇列對應一小段時間 (例如 60 秒)。 如果在此期間無代理可用，則可以將通話橋接 (含式取消佇列) 到外部客服中心處理該聯絡。

有關活動設置、使用方式和輸出變數的詳細資訊，請參閱 >橋接傳輸生成和管理流。

“斷開聯繫人”活動提供了直接從流中斷開或結束活動聯繫人的功能。

這是附加在流中的終端活動，可用於在沒有代理干預的情況下結束聯繫人，適用於錯誤路徑流或為客戶註冊回調后。

根據配置，當通過此活動結束聯絡時，將觸發 POST 通話調查或反饋。

有關活動設置、使用方式和輸出變數的詳細資訊，請參閱 構建和管理流>斷開聯繫人。

回撥活動允許呼叫者請求回撥而不是等待保留，通過減少等待時間和最小化放棄率顯著提高客戶滿意度。 啟動后，回撥活動會在佇列中創建一個任務，確保可用的座席可以返回客戶的呼叫。

流程設計人員可以將活動配置為將聯絡人保留在發起通話的原始佇列中，或根據偏好將其分配到其他佇列。 若回叫保留在原始佇列中，聯絡人將會保留其職位、專長、優先順序及情境資料，以便無縫指派至下一個可用的代理。 但是，如果選擇了其他佇列，則會將該聯絡人推到所選佇列的末尾，不包含任何技能並具有預設優先順序。

該活動還允許客戶請求其首選座席的回電，從而為體驗增添個人風格並提高客戶滿意度。 當回調活動緊隨流程中的 QueueToAgent 活動之後時，可以實現此目的。 此外，回調活動提供了一個可選配置，用於自定義回調過程中使用的自動號碼識別 (ANI)。 此自訂有助於提高品牌一致性，並通過確保可識別的來電者 ID 來降低拒接來電的可能性。

流設計器可以選擇在事件流中包含 CallbackFailed 事件。 當回調嘗試失敗時會觸發此事件，使流設計器能夠按特定間隔實現重試。 可以使用 Wait 活動配置重試之間的延遲或間隔，最小重試間隔為 10 秒，最長為 72 小時。 系統最多支援在 14 天內使用 Wait 活動重試多達 10 次。

有關活動設置、使用方式和輸出變數的詳細資訊，請參閱 >回調生成和管理流。

「通話進度分析」活動 (CPA) 可以偵測自動接聽系統，以及回撥通話中的即時人聲。

當回撥嘗試遇到答錄機偵測 (AMD) 或語音信箱時，系統會將通話辨識為不成功。 應答機檢測 (AMD) 的結果在 CallbackFailed 事件處理程式的原因輸出變數中捕獲。 基於此輸出變數，流程設計人員可以配置回調重試。

有關活動設置、使用方式和輸出變數的詳細資訊，請參閱 >通話進度分析構建和管理流。