在此文章中
dropdown icon
排隊
    dropdown icon
    概觀
      隊列類型
    dropdown icon
    非技能型排隊
      非技能型隊列,採用團隊分配
      非技能型隊列及代理分配
    dropdown icon
    基於技能的隊列
      分配給隊列的技能標準
      流程中分配的技能要求
    dropdown icon
    隊列配置
      設定基於技能的隊列
      建立非技能導向型隊列
dropdown icon
路由
    dropdown icon
    路由概念
      代理人過剩情景
      合約盈餘情景
      混合的多媒體設定檔
    dropdown icon
    路由模式
      基於技能
      非技能導向型路由
      基於代理的路由
dropdown icon
Flow中的排隊與路由功能
    Flow中的排隊與路由功能
    dropdown icon
    排隊活動
      排隊聯繫
      排隊等待代理
      升級呼叫分配組
    dropdown icon
    排隊資訊活動
      獲取隊列信息
      高級隊列資訊
    dropdown icon
    呼叫控制活動
      設定來電顯示
      錄影控制
      盲人轉接
      橋接轉移
      斷開連接
      設定聯絡人優先級
    dropdown icon
    回調活動
      回撥
      安排回撥
      通話進度分析
瞭解 Webex Contact Center 中的路由與佇列管理功能
list-menu在此文章中
list-menu意見回饋?

本文概述了 Webex 聯繫中心如何處理和引導呼叫。 代理接收到的交互資訊。它涵蓋了不同類型的排隊系統,例如基於技能的排隊系統和基於其他類型的排隊系統。 非技能型路由方法,例如最長可用路徑、環形路徑和最佳可用路徑。 它還解釋了幫助管理員管理互動、分配代理和控制的流程活動 呼叫流程,並取得即時佇列更新,以改善營運和客戶體驗。 體驗。

排隊

概觀

在 Webex 聯絡中心,佇列用作接收來電、聊天、電子郵件或社交管道等互動的暫存區。聯絡人會先進入佇列,直到系統自動將其指派給客服人員,或客服人員手動領取進行處理。此外,它們還支援基於技能的路由、優先級管理和公平的工作負載分配等功能。

主管可以利用隊列來觀察不同的工作流程,並改善呼叫中心處理任務的方式。

有效使用隊列的一些主要好處包括:

  • 更佳的客戶體驗: 管理等候時間,並讓顧客知道他們正在排隊等待幫助。
  • 效率提高: 確保通話處理有序,減少混亂和管理不善。
  • 公平分配聯絡方式: 將通話平均分配給各個客服人員,以防止單一客服人員工作負荷過重。
  • 優先處理: 允許優先處理某些來電,例如 VIP 客戶或緊急問題。

隊列類型

Webex Contact Center 支援多種類型的佇列,可為各種規模和複雜程度的聯絡中心提供廣泛的使用場景,並支援所有媒體類型,且功能統一。

有些隊列會考慮客服人員的技能來分配聯絡人,而有些隊列則不會。這些隊列在代理如何與它們關聯以處理聯絡人方面也存在差異。

隊列大致分為兩類:

  • 非技能型排隊
  • 基於技能的隊列

非技能型排隊

非技能型隊列不考慮代理的技能。您可以使用以下選項配置非技能佇列:

  • 團隊任務
  • 代理人分配

非技能型隊列,採用團隊分配

在非技能型佇列中,採用團隊分配,您可以將客服人員組織成團隊,並將這些團隊組合起來形成呼叫分配組 (CDG)。您可以設定每組呼叫之間的延遲時間來管理呼叫流程。

呼叫分配組有助於定義多個層級的座席,這些座席將在配置的時間間隔內有資格處理此佇列中的聯絡人。聯絡人會根據代理人所在團隊的等級分配給他們。如果沒有代理商可用,聯絡人將被保留一段預先配置的時間,然後再擴展到下一組團隊。此過程將持續進行,直到有代理人可用或所有群組都已檢查完畢為止。

您可以組建以下類型的團隊:

  • 各個團隊: 可以將客服人員組織成團隊,每個團隊可以代表特定的組織職能,然後這些團隊可以加入佇列,以便將聯絡人路由到這些團隊中的客服人員。您可以將客服人員指派到多個團隊,以便處理來自不同佇列的聯絡人,從而實現高效的路由。
  • 基於能力的團隊: 基於容量的團隊 (CBT) 是一項功能,它將語音通話定向到基於容量的直接號碼 (DN),其中容量決定了可以同時處理多少個通話。它可以將通話路由到電話號碼,而無需客服人員登入系統,因此適用於呼叫由語音信箱、答錄機或呼叫群組而不是傳統呼叫中心客服人員接聽的場景。在這種設定下,團隊沒有指派特定的代理,他們也不使用 Webex 聯絡中心代理桌面。

Webex聯絡中心中基於非技能的佇列和團隊分配的工作流程圖

在這個例子中,有三個呼叫分配組,允許目標擴展,這意味著在配置的時間間隔內擴展到團隊中的更多代理。

第一個呼叫分配組包含 TEAM 1,其中配置了 3 個代理程式 – A1、A2 和 A5。

第二個呼叫分配組包含 TEAM 2,其中配置了 3 個代理程式 – A2、A3 和 A4。

第三個(也是最後一個)呼叫分配組包含 TEAM 3,其中配置了 2 個代理程式 – A6 和 A7。

當有聯絡人排隊時,系統會先在第一個呼叫分配群組中搜尋符合的座席。如果沒有找到代理,則在將目標擴展到下一個群組之前,將聯絡人保留配置的持續時間。這相當於在現有團隊的基礎上增加了新的團隊。這個過程會重複進行,直到找到匹配項,或所有群組都擴展完畢。

「檢查代理程式可用性」功能會在目前呼叫分配群組中找不到符合的代理程式時,立即將聯絡人擴展到下一個呼叫分配群組。這可以在流程中的「隊列聯繫」活動 <LINK TO section 3.1.1> 中啟用。

這種設定會導致以下幾種情況:

  1. A2 屬於 TEAM 1 和 TEAM 2。如果 A2 選擇 TEAM 1 登入 Agent Desktop,則係統會將 A2 視為 TEAM 1 的一部分,因此也只將其視為第一個呼叫分配群組的一部分。
  2. A5 屬於 TEAM 1,但是,也可能屬於他們目前登入的組織中的其他團隊。因此,A5 不被視為 TEAM 1 的一部分,也不與此佇列關聯。

具有團隊分配功能的佇列為客服人員提供了強大的功能,只需在登入時選擇一個團隊,即可在不同佇列之間切換。

可用的路由模式:

非技能型隊列及代理分配

非技能型佇列是一種直接將一組代理程式指派到佇列中的佇列類型。與其他間接決定指派給它們的代理池的佇列類型不同,這些佇列允許管理員直接手動選擇代理程式。例如,基於團隊的分配佇列根據代理登入的團隊分配代理,而基於技能的分配佇列則根據所需的技能來配對代理。相較之下,管理員可以直接將代理程式新增到這些佇列中,使其成為佇列的一部分。這提供了一種直接的代理分配管理方法,無需依賴系統驅動的分配。

具有代理分配的佇列提供了簡單而有效的路由演算法,有助於將聯絡人指派到代理池中。他們不考慮客服人員在分配聯絡人方面的技能。但是,每個隊列中的代理可以按順序排列,在將聯絡人路由到他們時會考慮這一點。在這種情況下,團隊主要作為主管的組織結構,而不是代理佇列關聯和聯繫路由決策的因素,從而簡化了佇列管理。

這種類型的佇列最適合用於靜態分配代理程式和管理代理程式-佇列關聯,以便進行操作控制,並且選擇適合在代理程式之間分配工作的路由演算法。這些隊列對於多種類型的客戶諮詢需要專業知識,而這些專業知識可以由預先建立的專家代理團隊來滿足的場景也特別有用。

然而,對於複雜的呼叫中心組織而言,手動管理這些佇列中的座席分配可能很困難。他們可以從提供動態路由和代理程式佇列關聯的其他佇列類型中受益更多。

工作流程圖展示了 Webex 聯繫中心中基於非技能的佇列和座席分配範例的工作原理。

在這個例子中,佇列有一組代理程式以特定順序映射到它,例如 A4、A9、A7 等。此順序在將呼叫者配對給客服人員的特定路由演算法中發揮作用。系統根據代理商的可用性和所選的路由演算法,將聯絡人與這些代理商進行配對。

與團隊分配的佇列不同,沒有 目標擴展 隨時間間隔變化的概念。如果已設定的代理程式均無法路由此聯絡人,則該聯絡人將停留在佇列中,直到其中一個代理程式在停留逾時之前可以處理聯絡人為止。目標擴展 不適用於這些隊列。

可用的路由模式:

基於技能的隊列

基於技能的隊列可以將聯絡人路由到具備相應技能的客服人員,以滿足他們的需求。

您可以配置以下幾種基於技能的選項:

分配給隊列的技能標準

管理員可以為佇列分配技能標準。基於技能的佇列,結合技能標準,讓管理員直接在佇列中配置所需的技能。組織內所有具備隊列所需全部技能的代理人,透過直接技能檔案自動成為該隊列的一部分。

這種設定有助於管理員即時查看代理根據技能映射到佇列的情況。在業務量高或業務量低的情況下,管理員可以考慮根據需要調整佇列所需的技能和代理技能設定文件,以擴大或縮小代理池。

這種類型的佇列與基於團隊分配的佇列不同,因為它沒有呼叫分配組設置,這意味著團隊在座席與佇列的關聯中不起作用。此外,與基於團隊的技能隊列不同,此隊列中所需的技能是靜態配置的,而基於團隊的技能隊列則會注入(靜態或可變)所需的技能。因此,從技術上講,技能是隊列的一部分,而不是聯繫本身的一部分。

組織中任何完全滿足隊列技能標準(擁有直接技能概況中的技能)的代理人都會自動與該隊列關聯起來。團隊在代理與這些隊列的關聯中不扮演任何角色。這些代理人可以出於管理和營運目的加入任何團隊。

進入此佇列的每個聯絡人將自動採用佇列本身定義的技能標準。個人聯絡人無法定義或凌駕於自身技能之上。 requirements/criteria 與基於技能的隊列和團隊分配不同。

工作流程圖展示了 Webex 聯繫中心中基於技能的佇列及其技能標準的工作原理範例。

在這個例子中,

  • 只有 A1、A3 和 A7 三個代理程式完全符合佇列中配置的技能標準,因此只有這三個代理程式才能與該佇列關聯。
  • 部分符合資格的代理人 A2、A4 和 A6,或缺乏相關技能的代理人 A5,無法與此隊列關聯。

更新代理的技能概況(稱為技能重塑),使其滿足隊列的技能標準,將自動動態地使該代理成為該隊列的一部分。或者,更新佇列技能標準本身,使更多(或更少)的代理程式滿足更新後的技能標準,也會自動動態地向該佇列新增(或刪除)代理程式。

與團隊分配的佇列不同,沒有 目標擴展 隨時間間隔變化的概念。如果聯絡人無法與任何關聯的代理程式匹配,則會將其保留在佇列中,直到在保留逾時之前有代理程式可以處理聯絡人為止。

在技能的靜態分配和佇列與代理關聯的管理對於操作控制是可行且必要的場景下,基於技能的佇列最為適用。當選擇合適的路由演算法來分配代理之間的工作時,它們也適用。這些隊列對於不同類型的客戶諮詢需要特定技能,而這些技能可以由預先劃分的專家代理群體來滿足的場景也特別有用。

與需要手動將每個座席添加到清單中的座席分配隊列相比,複雜的聯絡中心組織可能會發現,基於技能的隊列更容易管理隊列到座席的分配,這對於規模較大的組織來說尤其繁瑣。

流程中分配的技能要求

在 Webex 聯繫中心中,基於技能的佇列(在流程中指派技能需求)是一種基於團隊分配的佇列,其中一組團隊在多個層級上進行配置,稱為呼叫分配群組。已登入這些已配置團隊的客服人員,如果完全滿足聯絡人的技能要求,則會根據其團隊在佇列中配置的呼叫分配群組級別,從該佇列中指派聯絡人。

在這樣的佇列中,座席團隊被分組到呼叫分配組中,組與組之間可以配置時間延遲。如果沒有客服人員可以接聽電話,則請求將被擱置,延遲一段時間後,路由將擴展到下一個呼叫分配群組。該過程將持續進行,直到分配到代理人或所有小組都完成為止。同時,如果在此過程中,先前檢查過的群組中的某個代理程式可用,則選擇該代理程式。

代理人透過直接分配給代理人的技能檔案來獲得技能。特工技能根據登入時的隊伍選擇而定。

每個聯絡人都可以在流程中選擇性地指定技能要求,系統會將這些要求與可用代理的技能進行匹配,以選擇最合適的代理。

此外,聯絡人還可以指定在設定的時間間隔內放鬆技能限制。這是一組修改後的技能要求,會在設定的時間間隔內覆蓋聯絡人的原始技能要求。這樣,聯絡人在排隊等候時可以修改(通常用於「放寬」)其技能要求,以便更多代理人可以匹配這些放寬的技能要求。

透過呼叫分配組進行目標擴展可以與技能放鬆週期同時進行——兩者都旨在更快地將待處理的聯絡人與合格的代理商匹配,從而減少整體等待時間並提高隊列的服務水平。

工作流程圖,展示了 Webex 聯繫中心中基於技能的佇列和團隊分配的工作原理範例。

與非熟練隊列和團隊分配類似,它有三個呼叫分配組,允許“目標擴展”,即在配置的時間間隔內擴展到更多跨團隊的代理。

  • 第一個呼叫分配組包含 TEAM 1,其中配置了 3 個代理程式 – A1、A2 和 A5。
  • 第二個呼叫分配組包含 TEAM 2,其中配置了 3 個代理程式 – A2、A3 和 A4。
  • 第三個(也是最後一個)呼叫分配組包含 TEAM 3,其中配置了 2 個代理程式 – A6 和 A7。

但是,有兩點需要特別注意:

  • 進入此佇列的每個聯絡人都會透過流程定義其技能要求和技能放寬條件。
  • 代理可以配置技能(透過技能設定檔-直接配置或從已登入團隊繼承)。

雖然 A2 配置為同時屬於 TEAM 1 和 TEAM 2,但根據該代理在登入期間選擇的團隊,在他目前的會話中,他將被視為該團隊的一部分,因此也將繼承該團隊的技能設定檔(以及技能值)(除非透過為該代理直接配置技能設定檔來覆寫此設定)。

這是佇列分配團隊功能提供的強大功能,代理程式只需在登入時選擇一個團隊,即可在佇列之間移動。

結合從選定團隊繼承技能設定檔設定的能力,代理程式也可以使用不同的技能組合。

在這個例子中,

  • 聯絡人依初始技能要求排隊(sk_1 >= 6) 在從流暢狀態升級的過程中,技能放鬆(sk_1 >= 3)經過設定的時間間隔後。
  • 在所有呼叫分配組的所有代理中,只有 A1、A3、A6 和 A7 的技能滿足排隊聯絡人的初始技能要求。
  • 其餘的代理人要麼擁有該技能(sk_1),但不符合技能要求(例如 TEAM 1 中的 A2 和 TEAM 2 中的 A4),要麼根本不具備該技能(例如 TEAM 2 中的 A5、A2)。
  • 隨著時間的推移,技能要求放寬,A2 和 A4 現在也滿足了合約中「放寬」後的技能要求。

對於進入此佇列的每一個聯絡人,系統都會嘗試在第一個呼叫分配群組中找到一個完全滿足該聯絡人目前技能要求的符合代理程式。如果找不到符合的代理,則在將目標擴展到第二個呼叫分配群組之前,該聯絡人將停留配置的持續時間。第二個呼叫分配組中配置的所有團隊也會加入第一個呼叫分配組中的現有團隊。現在系統嘗試在擴大的群體中尋找匹配的代理人。請注意,在此過程中,技能放寬也會按配置的時間間隔更新聯絡人的技能要求,系統將使用更新後的技能要求與目前通話分配群組中的可用代理程式進行比對。

除非在此之前找到匹配的座席,否則此程序將持續到所有已配置的呼叫分配組都已展開且所有技能放寬都已應用為止。

可用的路由模式:

隊列配置

設定基於技能的隊列

將技能標準分配給隊列
  • 創建技能,如有需要,創建動態技能。
  • 建立 技能概況
  • 直接為代理人指派技能檔案。
  • 直接為代理人指派動態技能。動態技能不是透過技能檔案分配的。
  • 建立隊列,通道類型可以是電話、聊天、電子郵件或社交。
  • 在控制中心中為佇列分配技能和動態技能要求。
  • 查看可以處理佇列中聯絡人的客服人員清單。
  • 選擇路由演算法,LAA 或 BAA。對於 BAA,根據需要配置熟練技能和熟練動態技能的權重。
  • 在流程中新增隊列聯絡人活動並選擇此隊列。
將技能要求分配給隊列
  1. 創建技能,如有需要,創建動態技能。
  2. 建立 技能概況
  3. 直接為代理人或團隊分配技能檔案。
  4. 直接為代理人指派動態技能。動態技能不是透過技能檔案分配的。
  5. 創建一個 團隊
  6. 將經紀人新增至團隊。
  7. 建立隊列,頻道類型可以是電話、聊天、電子郵件或社交。
  8. 將團隊新增至單一 CDG 或多個 CDG 的佇列。
  9. 選擇路由模式,LAA 或 BAA。
  10. 在流程中新增佇列聯絡人活動,並選擇已配置基於技能的路由的佇列。有關更多信息,請參閱 隊列聯絡人
  11. 在隊列接觸活動中分配技能、動態技能和技能放鬆。對於 BAA,根據需要配置熟練技能和熟練動態技能的權重。
  12. 在流程排隊後使用「升級呼叫分配活動」可以快速移動到下一個呼叫分配組或最後一個呼叫分配組。

建立非技能導向型隊列

將團隊分配到隊列
  • 創建一個 團隊
  • 將經紀人新增至團隊。
  • 建立隊列,頻道類型可以是電話、聊天、電子郵件或社交。
  • 將團隊新增至單一 CDG 或多個 CDG 的佇列。
  • 選擇路由模式,可以是 LAA。
  • 在流程中新增隊列聯絡人活動並選擇此隊列。
  • 在流程排隊後使用「升級呼叫分配活動」可以快速移動到下一個呼叫分配組或最後一個呼叫分配組。
將代理程式分配到隊列流
  • 建立隊列,頻道類型可以是電話、聊天、電子郵件或社交。
  • 直接將代理程式新增至佇列(注意:在這種類型的隊列中,既不使用技能也不使用隊伍。
  • 選擇路由模式,例如循環路由、線性路由或最長可用代理路由。
路由

路由概念

代理人過剩情景

當可用客服人員數量多於佇列中的客戶數量時,就會出現客服人員過剩的情況。在這種情況下,當客戶互動(聯繫)進入隊列時,系統會立即嘗試為該特定聯繫找到匹配的代理,如果找到了匹配的代理,則該聯繫無需留在隊列中等待稍後有匹配的代理可用。

每次聯絡人透過呼叫分配群組或技能放鬆進行擴展時,系統都會立即再次嘗試為該特定聯絡人找到匹配的代理。

使用佇列中設定的路由模式為特定聯絡人尋找符合的代理程式。

Webex 聯繫中心提供多種不同類型佇列的路由模式,使組織能夠透過最大限度地減少等待時間、平衡代理工作量以及確保客戶與具備滿足其特定需求所需技能的代理建立聯繫來優化客戶服務。有關路由模式的詳細信息,請參閱“路由模式”部分。

合約盈餘情景

當收到的客戶互動(或聯絡)數量超過可用客服人員數量時,就會出現聯絡過剩路由。這種情況通常發生在高峰時段或接觸量意外激增期間。聯繫量溢出路由的主要目標是有效管理這種溢出,確保在需求過高的情況下也能維持客戶服務標準。對於剛在特定管道上可用的客服人員,聯絡人剩餘路由功能會從該客服人員關聯的所有佇列中的所有已停用聯絡人中尋找並指派適當的聯絡人。

在座席資源有限的情況下,高效率執行呼叫路由的關鍵策略包括:

  • 隊列排名

    隊列排名功能允許管理員指定隊列的相對重要性。管理員可以定義佇列排名,以設定呼叫從佇列路由到已登入團隊的座席的順序,並按團隊進行設定。

    例如,假設登入 A 團隊的代理與兩個隊列相關聯—「計費」和「銷售」。管理員可以使用佇列排名為「計費」佇列分配更高的排名,這樣當聯絡人進入佇列時,「計費」佇列中的聯絡人將優先於「銷售」佇列中的聯絡人被路由到 A 團隊的代理程式。即使「銷售」隊列中可能有一些較早且優先順序較高的聯絡人正在等待,也會發生這種情況——僅僅因為「帳單」隊列的隊列排名高於「銷售」隊列。只有當「計費」隊列中不再有等待聯絡人時,A 團隊的代理人才會收到來自他們所屬的「銷售」(以及任何其他)隊列的聯絡人。

    以下是隊列排序的一些重要特徵:

      • 如果只為部分佇列分配了排名,則這些佇列中的呼叫將優先於未指定排名的佇列中的呼叫。
      • 隊列排名最多可設定 50 個隊列,涵蓋所有媒體類型,數值範圍為 1 到 50,1 為最高排名。
      • 您可以將相同排名指定給多個佇列。
      • 如果啟用佇列排名,則未指派任何明確排名的佇列將被視為低於所有已排名佇列。
      • 隊列排名適用於同一種媒體類型。

        例如,如果「銷售隊列」是 A 團隊的語音媒體類型隊列,等級為 2,「計費支援隊列」是 A 團隊的聊天隊列,等級為 1,那麼 A 團隊中在語音通道上可用的客服人員會優先獲得語音呼叫,即使等級為 2。

        但是,考慮 B 隊的兩個聊天隊列——隊列等級為 2 的信用卡隊列和隊列等級為 1 的借記卡隊列。然後,B 團隊中的可用代理商將首先獲得隊列借記卡提供的聯絡人。

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

  • 聯繫優先級

    當聯絡人被加入佇列時,可以透過指派從 1(最高)到 10(最低,預設值)的層級重要性來定義其優先權。這種優先排序確保根據某些聯絡人對組織的重要性、緊迫性或策略價值,更快地處理這些聯絡人。當代理有空閒的代理可以處理其所屬所有佇列中所有已暫停聯絡人的下一個聯絡人時,所有佇列中優先順序最高的聯絡人將被路由給該代理程式(前提是滿足技能匹配等其他標準)。

    對於未指定優先順序的排隊聯絡人,預設優先順序為 10(最低)。如果多個聯絡人的優先順序相同,則排隊等待時間最長的聯絡人將首先被指派給有空且符合條件的客服人員。

  • 等待時間最長的聯絡人

    這是一個基本策略,確保將代理所關聯的所有佇列中等待時間最長的聯絡人路由到該代理程式。

    這是決定在多個具有相同佇列排名和相同聯絡人優先順序的聯絡人等待處理時,路由哪個聯絡人的最終標準。

本質上,對於剛剛空閒的代理,聯絡人冗餘路由是指選擇一個聯絡人,該聯絡人:

  • 與代理商可用的媒體類型相同
  • 停放在與此代理關聯的任何佇列中
  • 該代理人滿足其所有技能要求(如有)。
  • 被放置在一個佇列中,該佇列的優先權高於代理團隊中配置的其他佇列。
  • 在所有此類聯繫中,優先順序最高。
  • 是優先順序相同的聯絡人中最老的等待聯絡人。

在上述說明聯絡人過剩場景的範例中,代理程式 A1 已登入 TEAM 1,並可處理多種媒體類型的聯絡人。

A1 與 3 個隊列相關聯 – Q1Q2Q3TEAM 1 也定義了隊列排名,其中 Q1 排名最高,然後 Q2Q3

所有這些隊列中都已安排了聯絡人,每個聯絡人都有技能要求和優先順序。

現在,接觸過剩情況的運作方式如下:

  • 在這些隊列中所有已停放的聯絡人中,只有 4 個聯絡人可以路由到 A1C2, C7 (來自隊列 2)和 C3, C8 (來自隊列 1)。3).

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

  • 在這 4 個聯絡人中,優先考慮來自 QUEUE 2 的聯絡人(即 C2、C7),因為 QUEUE 2 的隊列排名較高。

    請注意,即使 QUEUE 1 是排名最高的隊列,但由於 A1 無法滿足其技能要求,因此其停放的聯絡人均無法路由到 A1。

  • C2C7之間,優先順序最高的聯絡人是 C7。因此,最終選擇是 C7,系統將其路由到 A1

    即使 C2 更早排隊,也會發生這種情況,因為聯繫優先順序優先於排隊時間。

混合的多媒體設定檔

透過多媒體設定檔配置,Webex 聯絡中心讓客服人員透過不同的媒體類型(語音、聊天、電子郵件和社群媒體)為聯絡人提供服務。根據此配置,代理商將根據媒體類型獲得相應的頻道。

每次呼叫都被路由到客服人員,只要客服人員正在處理該呼叫,就會消耗該媒體類型的一個管道。雖然代理商只能擁有一個語音頻道,但他們最多可以擁有五個其他媒體類型的頻道。

多媒體設定檔 中的混合路由設定允許管理員控制每個代理程式如何同時使用不同的通道。這使得企業能夠更專注於客戶,進而提升服務品質,改善客戶體驗,提高轉換率。此外,當某些管道負載不平衡時,組織可以平衡各媒體管道的負載,從而有效利用代理資源。

有三種選擇:

  • 專屬

  • 混合

  • 混合即時

在處理非語音聯繫時,只要有語音頻道可用,客服人員就可以從客服桌面發起手動外撥語音通話。這適用於所有多媒體設定檔類型。

有關配置多媒體設定檔的更多信息,請參閱 管理多媒體設定檔

路由模式

基於技能

Webex 聯繫中心的基於技能的路由模式會根據解決客戶諮詢所需的特定技能(例如語言能力或技術專長)將傳入的客戶互動定向到相應的客服人員。這些模式確保每位客戶都能聯繫到最合適的客服人員,進而提高服務效率和顧客滿意度。其優點包括縮短處理時間、提高問題解決率,以及透過將客服人員的專業知識與客戶需求結合來優化客服人員資源的利用。

基於技能的路由可以使用代理從技能檔案中獲得的技能,以及直接分配給代理的動態技能。動態技能代表代理的屬性,這些屬性可以獨立於代理的技能概況而變化。

當使用基於技能的路由模式時,首先會根據聯絡人的技能要求(在流程中分配)或指派給佇列的技能標準來篩選出技能和動態技能滿足這些要求的可用客服人員。 / 完全是標準。然後,從篩選出的代理人中,根據配置的路由模式選擇一名代理人來處理聯絡人。

對於最佳可用路由,熟練度技能和熟練度動態技能也可以使用權重來影響用於代理選擇的分數。權重不會影響最長可用路徑;此模式僅使用技能和動態技能來確定代理資格。

最長可用時間

最長可用時間技能路由模式會將聯絡人路由到技能滿足聯絡人技能要求的客服人員。 / 完全按照隊列技能標準,以及隊列中所有符合條件的代理自上次聯繫以來空閒時間最長的代理。

這種路由模式透過將互動分配給線上時間最長的代理,幫助將工作平均分配給各個代理,從而防止工作量不平衡。這有助於保持工作分配的公平性,確保沒有代理人負擔過重,而其他代理人則可以保持空閒。

在上面的例子中,有 4 個代理人,他們分別具有熟練和不熟練的技能,熟練技能值各不相同。

假設有一個聯絡人被放入一個基於技能的佇列中,該佇列採用「最長可用時間」路由模式:

  • 透過流程分配上述技能要求,或
  • 上述技能標準已在基於技能的佇列中配置。

在這種情況下:

  • 只有完全符合聯絡技能要求的代理人才能勝任。 / 隊列技能標準會根據路由進行考慮。只有代理人 A1A2和 A4滿足 聯繫技能 要求 / 完全符合排隊技能標準。

    代理人 A3 不符合資格。對於分配給隊列] 的 技能標準, A3 甚至與該隊列沒有關聯。

  • A1A2A4 中,聯絡人將被路由到可用時間最長的代理——A1,他已經可用 10 分鐘了,比 A2 或 A4 的時間更長。

    由於 A1 被分配了聯絡人, A1 將不再是所有媒體管道中可用時間最長的代理人。

  • 下一個技能要求完全相同的聯絡人將被轉接到下一個空閒時間最長的代理商— A2,依此類推。

以下類型的基於技能的佇列支援這種路由模式:

最佳可用

最佳可用技能路由模式可確保客戶互動被引導至最合格的客服人員。此模式不僅評估代理人是否具備所需技能,還評估這些技能的熟練程度,計算技能分數以確定每次聯繫中最合格(「最佳」)的代理人。

此模式篩選出技能符合聯絡技能要求的可用代理人。 / 完全符合排隊技能標準。然後,根據聯絡技能要求中提到的所有技能的熟練程度值,計算每位符合條件的代理人的得分。 / 排隊技能標準。對於每個聯絡人,技能得分最高的代理人被認為是「最佳」代理人。

實際上,就是滿足聯絡人技能要求的代理人技能值的總和。 / 排隊技巧標準決定得分。

需要理解的一些關鍵點:

  • 通常情況下,分數計算會使用實際技能值,因為技能分數越高,表示匹配度越高。除非技能要求使用小於等於( < =) 條件是,代理人的特定技能值在得分計算中被反轉,即effective_skill_value = (10)減去(actual_skill_value)。這樣做是為了確保較低的分數表示更強的匹配度。
  • 當多個符合資格的代理人得分相同時,選擇其中服務時間最長的代理人。
  • 評分計算僅考慮熟練技能。聯繫技能要求中的任何布林值、文字或枚舉技能 / 排隊技巧標準不計入得分計算。

在上面的例子中,有四個代理人,他們分別具有熟練和不熟練的技能,並且熟練技能值各不相同。

假設有一個聯絡人被放入一個基於技能的佇列中,該佇列採用「最佳可用」路由模式:

  • 透過流程分配上述技能要求,或
  • 上述技能標準已在基於技能的佇列中配置。

在這種情況下:

  • 只有完全符合聯絡技能要求的代理人才能勝任。 / 隊列技能標準會根據路由進行考慮。只有代理人 A1A2和 A4滿足 聯繫技能 要求 / 完全符合排隊技能標準。

    代理人 A3 不符合資格。對於分配給隊列] 的 技能標準, A3 甚至與該隊列沒有關聯。

  • 在A1 、 A2和 A4三個選項中 ,系統會根據接觸技能要求進行評分計算。 / 隊列技能標準,其中只考慮熟練技能。

    僅包括合約技能要求中提到的技能。 / 即使代理商可能擁有額外的技能,隊列技能標準也會被納入評分計算。 / 其他熟練技能。

    也要注意,當小於等於()時,得分計算中技能值的反轉 < =) 條件已使用。

  • 聯繫被路由至 A2 ,因為根據評分,這是最佳可用代理。如果 A2 不可用 / 如果客服繁忙,則該聯絡人將被轉接給評分第二高的下一位可用客服,依此類推。

    但是,我們還有 2 個代理人—— A1A4 的得分次高。聯繫被路由到 A1A4之間最長的可用代理。

以下類型的基於技能的佇列支援這種路由模式:

非技能導向型路由

Webex 聯繫中心也支援各種非基於技能的路由模式,這些模式著重於分配傳入的客戶互動,而不考慮代理商的特定技能或專業知識。與基於技能的路由模式不同,這些模式不考慮客服人員的技能,也不需要透過聯絡人或佇列來定義技能需求。 / 路由標準。相反,他們優先考慮可用性、工作量分配和預定義順序等因素,從而能夠根據操作邏輯而不是單一代理的能力來高效處理聯繫。這些模式在互動相對統一或不需要特殊處理的環境中特別有用。

最長可用時間

最長可用時間路由模式會將聯絡人路由到佇列中自處理完上次聯絡人以來空閒時間最長的代理,該代理是與該佇列關聯的所有可用代理程式中空閒時間最長的代理程式。

這種路由模式透過將互動分配給空閒時間最長的代理來確保公平平衡的工作負載分配。透過防止工作量不平衡,可以確保沒有代理工作量過大,而其他代理則可以保持空閒。這種方法在客戶聯繫量穩定的時期尤其有效,能夠維持代理商群體的持續參與。

當經紀人獲得任何媒體類型的聯繫機會時,他們在所有管道中的「最長可用」位置將會被取消。這意味著,當一名客服人員處理完一個聯絡人後,隊列中任何媒體類型的下一個聯絡人將被指派給該隊列中下一個空閒時間最長的客服人員。

在上面的例子中,代理 A1 是可用時間最長的代理(位置 1)-要麼是第一個登入的代理,要麼是分配聯絡人的時間比任何其他代理都長。

代理 A2 (位置 2)和 A3 (位置 3)也可用,但他們要么已經登錄,要么在 A1之後處理了聯絡人。所有代理程式都與這兩個具有這種路由模式的佇列相關聯。

考慮以下情景:

  • 在時間 T0語音呼叫 C1被排隊並路由到最長可用代理。A1.

    由於 A1 被分配了 C1A1 不再是所有媒體管道中最長可用的代理。

  • 在時間 T1,聊天聯絡人 C2 被排隊並路由到最長可用代理,即 A2
  • 最後,在時間 T2,另一個語音聯絡人 C3 被排隊並路由到 A3

    A1A2 最近獲得了聯繫-目前,等待時間最長的是 A3

由於 Webex 聯絡中心的分散式架構,當多個聯絡人同時排隊到同一個佇列時,單一可用時間最長的座席有可能被路由到多個聯絡人。

以下類型的非技能型佇列支援這種路由模式:

循環

循環路由模式將傳入的聯絡人按輪詢順序分配給一組可用的代理程式。當一個聯絡人進入佇列時,系統會根據預定的順序將其指派給佇列中下一個可用的客服人員。

過程從按預設順序放置的代理開始。第一個來電將分配給該順序中第一個可用的客服人員。對於後續聯繫,系統會選擇下一個可用的客服人員,並按照定義的佇列順序從上次中斷的地方繼續進行。這種模式會重複出現,循環遍歷所有代理,但總是從最後一個被選中的代理的位置之後開始。

這種方法能夠有效地將聯絡人公平、均勻地分配給各個代理人。這有助於確保沒有哪個代理人會被過多的聯絡資訊壓垮,並且所有代理人都有平等的機會以一致的方式處理互動。然而,循環路由模式並未考慮目前的工作負載,也沒有考慮其他可能影響代理人處理特定聯絡人能力的因素。

在上述範例中,代理程式按以下順序配置在循環佇列中:A3 → A4 → A5 → A6 → A1 → A2.

首先,起始位置是組態順序中的第一個代理(A3)。當聯絡人被路由到此佇列中的代理程式時,其位置會沿著圓圈移動,到達按配置順序排在最後一個聯絡人被路由到的代理程式之後的下一個代理程式。

考慮以下情景:

  • 第一個聯繫(C1)被排隊,並被路由到代理 A3

    指標會依配置順序更新到下一個代理,即A4.

  • 當第二個聯絡人(C2)進入佇列時,系統開始從 A4 開始尋找可用代理。A4 → A5 → A6 → A1 → A2 → A3.

    然而, A4A5 不可用(它們要么根本沒有登錄,要么處於空閒狀態,要么正忙於處理其他此類媒體類型的聯繫人),因此 C2 被路由到下一個可用的代理 – A6。指標會依配置順序更新到下一個代理,即A1.

  • 類似地,第三個觸點(C3)路由到 A1,第四個接點(C4)路由到 A2。指針再次指向 A3

    這種邏輯一直延續下去,聯絡人資訊會被指派給「循環」中的可用代理人。 / “循環賽”模式。

如果佇列中有待處理的聯絡人,代理過剩場景會將下一個在該媒體類型上可用的代理程式與其中優先順序最高、時間最長的聯絡人進行比對。

這不會考慮或影響此佇列中現有的位置值,該值僅在聯絡人剩餘路由成功與代理程式配對時才會更新。

以下類型的非技能型佇列支援這種路由模式:

自頂向下

自上而下的路由模式將傳入的聯絡人依序分配給一組可用且有序的代理程式。當一個聯絡人進入隊列時,系統總是從頭開始遍歷代理的有序列表,並將該聯絡人與該序列中第一個可用的代理(該代理有與聯絡人媒體類型匹配的空閒通道)進行匹配。

這種情況會發生在每個排隊的聯絡人身上。系統會嘗試從頂部(第一個已配置的代理)開始匹配聯絡人,並向下遍歷列表,直到找到匹配的代理為止。

與循環路由模式不同,沒有「指標」可以根據最後選擇的代理程式的位置動態改變起點。

這種方法對於根據某種偏見排序的代理人之間分配聯繫是有效的。 / 管理員決定的偏好。這有助於確保排名靠前的代理人始終優先處理客戶聯繫,而不是排名靠後的代理人。然而,自上而下的路由模式並未考慮目前的工作量,也沒有考慮其他可能影響客服人員處理特定聯絡人能力的因素。

在上述範例中,代理程式按以下順序以自上而下的佇列進行配置:A3 → A4 → A5 → A6 → A1 → A2.

這意味著管理員希望每個聯繫都按配置順序路由到第一個代理(A3)(如果可用),否則路由到下一個代理(A4)(如果可用),依此類推。

考慮以下情景:

  • 第一個聯繫(C1)被放入隊列,並被路由到代理 A3,因為 A3 位於訂單的頂部。
  • 當第二個聯絡人(C2)排隊時,將再次嘗試從訂單頂部開始路由(始終從 A3開始)。

    如果 A3 有更多通道容量用於此媒體類型,則 C2 也路由到 A3。但是,如果 A3 完全忙於處理這種媒體類型,則路由將向下進行到列表的 A4

  • 然而, A4A5 不可用(它們要么未登錄,要么處於空閒狀態,要么正忙於處理其他此類媒體類型的聯繫人),因此 C2 被路由到自上而下順序的下一個可用代理—— A6。
  • 類似地,第三個觸點(C3)嘗試從 A3 向下路由到底部。第一個匹配代理將是 A1

    這種邏輯會持續下去,直到訂單底部沒有可用的代理為止,在這種情況下,該聯絡人將保留在佇列中。

以下類型的非技能型佇列支援這種路由模式:

基於代理的路由

基於代理的路由功能可以將聯絡人直接路由或排隊給指定的(「首選」)代理。透過代理人的電子郵件地址或代理人 ID 進行代理人查找,可以將聯絡人路由至首選代理人。流程中的「佇列到代理」活動有助於實現基於代理程式的路由。有關更多信息,請參閱 隊列到代理 活動。

聯絡人可以對應到一個或多個首選代理,這通常可以在 Webex 聯絡中心以外的外部應用程式中進行管理。首選的聯絡人代理程式查找是透過 HTTP 請求 活動完成的,該活動從外部應用程式檢索映射。若要將聯絡人路由或暫存給首選代理,請使用代理程式的 Webex 聯絡中心 ID 或電子郵件地址設定「佇列到代理程式」活動。如果首選代理人暫時無法提供服務,也可以將該聯絡人保留給首選代理人。

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

  • 首選代理路由: 客戶可以將聯絡人指派給專屬客服人員或客戶經理。在這種情況下,基於代理的路由會將聯絡人直接路由到首選代理。
  • 最後代理路由: 當客戶多次撥打客服中心電話與客服人員互動時,基於客服人員的路由可以將客戶路由到上次處理該客戶的客服人員。

在這兩種使用場景中,聯絡人和代理程式對應的詳細資訊都儲存在 Webex 聯絡中心之外。

Flow中的排隊與路由功能

Flow中的排隊與路由功能

在 Webex 聯繫中心,可以透過流程來協調各種路由、排隊和呼叫控制功能。

流程設計器中提供了各種流程活動和事件處理程序,可以將其放置在流程中,以有效管理入站和出站聯絡人的生命週期。

有關設定和使用流程的更多信息,請參閱 使用流程設計器建置和管理流程

排隊活動

排隊聯繫

「排隊聯絡人」活動允許將聯絡人從組織排隊到活動的入站佇列中,以便將其配對並路由到該佇列中的正確代理程式。

透過此活動可以管理排隊的以下幾個方面:

  • 優先權 - 為排隊中的聯絡人指派從 1(最高)到 10(最低,預設值)的層級重要性。
  • 技能要求 - 設定基於技能的佇列中的代理必須滿足的技能標準,才能被視為有資格路由聯絡人。
  • 技能放寬 - 經過一段時間後,調整、修改或移除先前設定的技能要求,以提高找到代理人的機會。
  • 檢查座席可用性 - 允許系統立即擴展到所有呼叫分配群組,以避免等待時間,前提是找不到可用座席。

有關優先順序、技能配置和代理可用性如何影響聯絡人路由的更多信息,請參閱 路由

一旦「排隊聯絡人」活動成功將聯絡人加入隊列,

  • 如果已有配對的客服人員在線,系統會嘗試將聯絡人轉接給客服人員。

    這將中斷 主流程 的執行,如果已配置,後續事件可以觸發相應的 事件流程

  • 如果沒有找到符合的代理,則聯絡人將保留在佇列中,等待符合的代理程式可用。

    流程執行隨後繼續執行佇列聯繫活動之後附加的活動,這些活動提供了以下功能:

    • 透過附加 PlayMusic 活動,向排隊等候的顧客播放預先配置的音樂。
    • 根據客戶的請求註冊回調 - 透過附加 Callback 活動。
    • 重新排隊,即從目前佇列中移除聯絡人並將其新增至新佇列 - 透過附加另一個 Queue ContactQueue to Agent 活動。

當有合適的客服人員可用時,系統會嘗試將聯絡人轉接給該客服人員。

成功時,這將中斷 主流程 的執行,如果已配置,後續事件可以觸發相應的 事件流程

「隊列聯繫」活動在以下情況下有效:

  • 該聯絡人尚未分配,可轉交給客服人員。
  • 佇列、技能和其他流程配置均已正確設定。
  • 接觸次數仍維持在允許的 25 次入口點和排隊轉換次數的限制之內。
  • 聯絡人仍在允許的 20 次成功路由嘗試次數限制內。

配置錯誤處理路徑,以便優雅地管理需要備用路由或額外處理的聯絡人。

在這種情況下,活動會導致失敗,流程執行將會移至 錯誤處理 路徑。

只有在選擇具有團隊分配的佇列時,在佇列聯繫活動中才提供技能要求、技能放寬和檢查代理可用性等功能。

有關活動設定、用法和輸出變數的更多信息,請參閱 建置和管理流程 > 隊列聯絡人

排隊等待代理

「排隊到客服」活動允許透過在 Webex 聯絡中心尋找客服人員的唯一客服人員 ID 或電子郵件地址,將聯絡人直接排隊到首選客服人員。

透過此活動可以管理排隊的以下幾個方面:

  • 優先權 - 分配 higher/lower 對於排隊等待同一代理的聯絡人而言,其重要性不容忽視。
  • 報告隊列 - 標識用於配置(例如錄音和預設隊列音樂)的隊列,並報告聯絡人的目的。
  • 復原佇列 - 當聯絡人無法路由到指定的首選代理程式時,要使用的備用佇列。

一旦「排隊等待客服」活動成功將聯絡人加入隊列,

  • 如果客服人員已有空,則該聯絡要求將轉接給該客服人員。

    這將中斷 主流程 的執行,如果已配置,後續事件可以觸發相應的 事件流程

  • 如果客服人員在線,但選擇拒絕、不接聽或未能收到聯繫,則會將聯絡資訊移至提供的恢復佇列中。

    在恢復隊列中,聯絡人將被路由到空閒時間最長的客服人員,不考慮技能等級。

  • 如果代理不可用且選擇了「Park Contact If Agent Unavailable」選項,則 聯絡人將被保留並等待代理可用。

    流程執行隨後繼續執行「排隊到代理」活動之後附加的活動,從而實現以下功能:

    • 透過附加 PlayMusic 活動,向排隊等候的顧客播放預先配置的音樂。
    • Callback 活動。
    • 重新排隊,即從目前佇列中移除聯絡人並將其新增至新佇列 - 透過附加另一個 Queue to AgentQueue Contact 活動。

    一旦有客服人員上線,系統會嘗試將通話轉接給該客服人員。

    這將中斷 主流程 的執行,如果已配置,後續事件可以觸發相應的 事件流程

  • 如果代理不可用 且未選擇“Park Contact If Agent Unavailable”選項,則排隊失敗。

「排隊等待代理」活動在以下情況下有效:

  • 該聯絡人尚未分配,可轉交給客服人員。
  • 首選代理人 ID 或電子郵件地址有效。
  • 報告隊列和恢復隊列配置正確。
  • 首選客服人員已登錄,在線,隨時準備處理您的來電。

配置恢復佇列,以確保在首選客服人員無法使用時,聯絡人能夠順利路由。

在這種情況下,活動會導致失敗,流程執行將會移至 錯誤處理 路徑。

有關活動設定、用法和輸出變數的更多信息,請參閱 建置和管理流程 > 將隊列傳遞給代理

升級呼叫分配組

「升級呼叫分配組」活動僅支援具有團隊分配的 佇列,並且能夠立即更新聯絡人的 呼叫分配組 ,而不是等待配置的等待時間後自動擴充更新到下一個群組。這樣一來,就可以快速將聯絡人指派給佇列中所有符合條件的客服人員。

透過使用「升級呼叫分配組」活動,可以將通話升級至:

  • 下一個群組— 擴展團隊集合,將新增至下一個呼叫分配群組中的團隊也包含在內。
  • 最後組— 將團隊集擴展到包含為佇列配置的所有呼叫分配組中所對應的所有團隊。

「升級呼叫分配組」活動在下列情況下有效:

  • 該聯絡人已進入佇列,準備升級處理。
  • 該聯絡人已加入使用呼叫分配群組的佇列中。

對於使用標準路由的佇列,繼續透過佇列配置的路由行為分發聯絡人。

在這種情況下,活動會導致失敗,流程執行將會移至 錯誤處理 路徑。

考慮這樣一個場景:一個聯絡人被放入一個包含三個呼叫分配組的佇列中,每個群組每 30 秒更新一次。

CDG 1CDG 2中的團隊中沒有可用的代理,而 TEAM 3 中有一位代理,它屬於最後一個呼叫分配組。

當流程中未使用「升級呼叫分配組」活動時,會導致長時間的等待,如下所示:

透過使用「升級呼叫分配組」活動可以縮短等待時間,具體使用方法如下:

根據所選的 下一組最後一組 選項,聯絡人的等待時間將大大減少,如下所示:

有關活動設定、用法和輸出變數的更多信息,請參閱 建置和管理流程 > 升級呼叫分配組

排隊資訊活動

獲取隊列信息

「獲取隊列資訊」活動可以獲取指定聯絡人的即時隊列信息,例如:

  • 聯絡人在佇列中的目前位置(PIQ),或如果尚未排隊,則可能的位置。
  • 估計等待時間(EWT)或任務在佇列中等待被回答的持續時間。
  • 聯絡人目前呼叫分配群組中已登入或可用的客服人員數量。
  • 所選佇列中所有呼叫分配組中已登入或可用的座席數量。
  • 隊列中最老聯絡人的等待時間。

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

有關活動使用情況、詳細定義以及每個隊列詳細資訊的計算方法的更多信息,請參閱 建置和管理流程 > 取得隊列資訊.

使用隊列資訊的一些方法包括:

  • 在客戶等待路由時,向客戶宣布聯絡人在佇列中的位置和預計等待時間。
  • 如果預計等待時間過長,則決定是否可以為客戶註冊回撥服務。
  • 如果目前呼叫分配組 (CDG) 中沒有可用的客服人員,則將聯絡升級到下一個呼叫分配組 (CDG)。

當所選變數解析為有效佇列時,「取得佇列資訊」活動才能正常運作。

配置錯誤處理路徑,以便優雅地處理所選變數需要驗證或無法解析到可用佇列的情況。

在下列情況下,目前呼叫分配組的即時佇列資訊不適用:
  • 執行「獲取隊列資訊」活動時,聯絡人尚未進入隊列。
  • 聯繫請求被放入一個不支援呼叫分配組概念的佇列中。

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

考慮這樣一個場景:客戶在隊列中每等待 15 秒,就應該被告知隊列中存在較長的 EWT(預計等待時間)。

這可以透過在流程中使用「獲取隊列資訊」活動來實現,如下所示:

高級隊列資訊

高階隊列資訊活動能夠獲取給定聯絡人的即時隊列信息,同時也會考慮聯絡人的技能標準,例如:

  • 聯絡人在佇列中的目前位置(PIQ),或如果尚未排隊,則可能的位置。
  • 聯絡人目前呼叫分配群組中已登入或可用的客服人員數量,符合給定的技能標準。
  • 所選佇列中所有呼叫分配組中已登入或可用的客服人員數量,符合給定的技能標準。
  • 目前呼叫分配組,聯絡人在該組中停留在提供的隊列中。
  • 給定佇列中的呼叫分配組總數。

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

有關活動使用情況、詳細定義以及每個隊列詳細資訊的計算方法的更多信息,請參閱 建置和管理流程 > 高階隊列資訊.

使用高級隊列資訊的一些方法包括:

  • 在客戶等待路由時,向其宣布聯絡人在佇列中的位置。
  • 如果目前呼叫分配組中沒有符合技能標準的客服人員,則將聯絡人升級到下一個呼叫分配組。
  • 如果所有呼叫分配組中都沒有符合技能標準的代理登錄,則要決定是否可以為客戶註冊回撥。

「高級隊列資訊」活動在以下情況下有效:

  • 對於在流程中配置了技能要求的佇列,而不是作為佇列等級的技能標準,需要請求佇列資訊。
  • 如果聯絡人已在佇列中,則要求的資訊將指向聯絡人目前所在的相同佇列。
  • 該聯絡人會被放入佇列,而不是直接指派給首選客服人員。

配置錯誤處理路徑,以管理不符合這些要求的請求。

在這種情況下,活動會導致失敗,流程執行將會移至 錯誤處理 路徑。

設想這樣一個場景:由於沒有符合技能標準的客服人員可以提供服務,因此應該通知客戶將會收到回電。

這可以透過在流程中使用「高階隊列資訊」活動來實現,具體步驟如下:

呼叫控制活動

設定來電顯示

「設定來電顯示」活動用於定義通話期間應顯示的來電顯示號碼。設定來電顯示活動只能在預先撥號事件流程中使用,作為標示事件流程結束的終端活動。

設定來電顯示活動可根據撥號號碼識別服務 (DNIS)、操作類型或參與者類型配置所需的自動號碼識別 (ANI)。

有關活動設定、用法和輸出變數的更多信息,請參閱 建置和管理流程 > 設定來電顯示

錄影控制

錄音控制活動旨在與選單活動一起使用,以取得呼叫者的錄音同意。這樣可以確保遵守相關法規或政策,在開始錄製之前獲得明確同意,並將此步驟無縫整合到工作流程中。

選單 IVR 活動必須將使用者的同意捕獲到一個布林變數中,該變數將作為輸入分配給錄音控制活動。如果客戶需要在同意報告中報告使用者同意情況,則應將同意值儲存在可報告的全域變數中。或者,如果不需要產生報告,則可以使用局部變數。這種方法為租戶和客戶提供了更大的靈活性,可以有效地管理和利用各種變數。

當此活動新增至流程時,使用者的同意優先於租用戶層級、佇列層級或錄製計畫層級的組態設定。

優先順序如下:

  • 如果使用者在流程中同意為“是”,則無論租戶、佇列或錄音計畫等級設定的錄音配置為何,通話都會被錄音。
  • 如果使用者未對此活動表示同意,則無論租戶、佇列或錄音計畫等級設定的錄音配置為何,通話都不會被錄音。
  • 如果流程中未配置錄音控制活動,但在租用戶、佇列或錄音計畫等其他任何層級中將配置設為“是”,則會錄製通話。
  • 如果在流程中未配置錄音控制活動,並且在租戶、佇列和錄音計畫等所有層級上都將組態設為“否”,則不會錄製通話。

此錄影控制功能可表示如下:

此外,諸如「傳輸時繼續」、「暫停恢復啟用」、「暫停持續時間」等錄製配置仍根據現有層次結構適用,包括租戶、佇列或錄製計畫層級。

有關活動設定、用法和輸出變數的更多信息,請參閱 建置和管理流程 > 錄製控制

盲人轉接

盲轉是指透過 IVR 系統將聯絡人有效率地路由到外部撥號號碼 (DN) 的過程,因此無需人工幹預。

當必須將通話轉接到外部或第三方分機號碼時,可以使用盲轉活動。這是一個終端活動,因此一旦轉帳執行完畢,流程就會結束。

當流程以諮詢方式執行時,不支援盲轉活動。

有關活動設定、用法和輸出變數的更多信息,請參閱 建置和管理流程 > 盲轉移

橋接轉移

橋接轉接活動允許將聯絡人暫時轉移到外部目的地,同時流程保持對呼叫的控制。外部目的地可以是外部橋接器或互動式語音應答 (IVR) 服務。

當外部目標結束通話時,通話流程會根據需要繼續進行,例如將其排入客服人員的佇列。

橋接轉接活動會將聯絡人從佇列中移除,同時將其轉接到第三方 IVR 或自動呼叫分配 (ACD) 系統。如果第三方系統無法處理該聯絡人,則可以將其重新排回原始佇列,以確保該聯絡人保留在工作流程中以便進行適當處理。

例如,假設一個聯絡中心擁有 Webex 聯繫中心座席資源和外部呼叫中心或專用交換器 (PBX) 上的座席資源。客戶希望將呼叫請求短暫(例如 60 秒)排入 Webex 聯絡中心客服人員的佇列中。如果在此期間沒有客服人員可用,則可以將呼叫橋接(隱式出隊)到外部呼叫中心處理該呼叫。

  1. 橋接轉接活動在呼出流程和事件流程中不受支援。
  2. 已指派給代理商的聯絡人不支援透過流程進行橋接轉接。

有關活動設定、用法和輸出變數的更多信息,請參閱 建置和管理流程 > 橋接轉帳

斷開連接

「斷開連線」活動允許直接從流程中斷開或結束活動連線。

這是流程中附加的終端活動,可用於在無需代理幹預的情況下結束聯繫,適用於錯誤路徑流程或在為客戶註冊回撥後。

根據配置,當透過此活動結束聯繫時,將觸發通話後調查或回饋。

有關活動設定、用法和輸出變數的更多信息,請參閱 建置和管理流程 > 斷開連接

設定聯絡人優先級

設定聯絡人優先活動允許為聯絡人分配特定的優先級,從而在流程中實現有效的聯絡人優先級管理。這樣一來,某些聯絡人的優先順序就可以更高或更低,從而確保在有客服人員可用時,這些聯絡人能夠與其他等待的聯絡人進行適當的路由。這種靈活性使得在整個流程中能夠精確控制聯絡人的優先順序。

優先順序是透過分配從 1(最高)到 9(最低)的層級重要性等級來決定的。優先順序最高的聯絡人會優先於優先順序較低的聯絡人進行路由。當多個聯絡人的優先順序相同時,等待時間最長的聯絡人將首先被轉接到下一個可用且符合條件的客服人員。該系統確保優先順序較高的聯絡人能夠及時處理,同時根據等待時間,對優先順序相同的聯絡人保持公平。

  1. 「設定聯絡人優先」活動可以放置在主流程或活動流程中的任何位置。
  2. 如果在排隊活動(例如排隊聯絡人或排隊給代理商)之前配置了「設定聯絡人優先順序」活動,則其優先順序設定可能會被後續排隊活動中明確配置的任何優先順序所覆蓋。但是,如果後續的排隊活動沒有指定優先級,則會套用先前「設定聯絡人優先級」活動設定的聯絡人優先順序。
  3. 相反,如果在排隊活動(例如排隊聯絡人或排隊給代理商)之後配置「設定聯絡人優先」活動,則會覆蓋先前排隊活動配置的優先順序設定。
  4. 目前,外撥聯絡人和行銷活動聯絡人不支援「設定聯絡人優先順序」功能。

有關活動設定、用法和輸出變數的更多信息,請參閱 建置和管理流程 > 設定聯絡人優先權

回調活動

回撥

回撥功能允許呼叫者請求回撥,而不是等待接聽,從而顯著提高客戶滿意度,減少等待時間並最大限度地降低放棄率。啟動後,回調活動會在佇列中建立任務,確保有空閒的客服人員可以回撥客戶的電話。

流程設計者可以設定活動,使其將聯絡人保留在呼叫發起的原始佇列中,或根據偏好將其指派到不同的佇列。如果回撥請求保留在原始佇列中,則聯絡人將保持其位置、技能、優先順序和上下文數據,從而可以無縫分配給下一個可用的客服人員。但是,如果選擇不同的佇列,則聯絡人將被推到所選隊列的末尾,沒有任何技能,並且優先順序為預設。

該活動還允許客戶請求他們喜歡的客服人員回電,為體驗增添個人化元素,提高客戶滿意度。當回呼活動在流程中位於 QueueToAgent 活動之後時,即可實現這一點。此外,「回呼」活動還提供了一個可選配置,用於自訂回調過程中使用的自動號碼識別 (ANI)。這種客製化有助於保持品牌一致性,並透過確保來電顯示清晰可辨來降低來電被拒接的可能性。

流程設計器可以選擇在事件流程中包含 CallbackFailed 事件。當回呼嘗試失敗時,將觸發此事件,使流程設計者能夠以特定時間間隔進行重試。可使用「等待」活動配置重試之間的延遲或間隔,最小重試間隔為 10 秒,最大重試間隔為 72 小時。該系統支援使用「等待」活動在最長 14 天的時間內進行最多 10 次重試。

有關活動設定、用法和輸出變數的更多信息,請參閱 建置和管理流程 > 打回來

安排回撥

預定回撥活動使流程能夠為客戶提供在未來特定日期和時間請求回撥的便利,從而無需立即與客服人員聯繫。此功能透過讓客戶選擇方便的回撥時間,改善客戶體驗,從而最大限度地減少感知等待時間,降低呼叫放棄率。

此流程必須透過 DTMF 提示擷取呼叫者的輸入(例如首選日期和時間),並在執行必要的輸入驗證後將其傳遞給活動。

在開始之前,請確保已在控制中心的 通道設定 下配置 [] 回調預設入口點 。有關更多信息,請參閱 設定回調入口點

可以使用任何電話隊列(無論是呼入隊列或呼出隊列)來安排回撥。為了獲得最佳效果,建議在計劃回調活動之後立即添加斷開連接活動,以確保在安排回調後當前通話能夠正確結束。有關安排 IVR 回撥的更多信息,請參閱 安排 IVR 回撥

當在請求的未來日期和時間觸發回調時,將建立一個新的呼叫或互動。這種新的互動將遵循與回呼預設入口點關聯的標準流程。如果回呼嘗試失敗,則流程可以使用 CallbackFailed 事件處理程序自動重試呼叫(如果在該流程中配置)。

在將輸入傳遞給活動之前,應考慮以下輸入驗證:

  1. 日期選擇—您可以選擇從今天到未來 31 天內的任何日期。日期必須採用以下格式:YYYY-MM-DD(例如,2025-07-18)。
  2. 時間窗口開始和結束時間—您選擇的時間必須從現在起至少 30 分鐘開始,持續時間可以在 30 分鐘到 8 小時之間。請使用 24 小時制時間格式(例如 14:30:00)。
  3. 時區—您必須輸入 IANA 格式的有效時區(例如 America/New_York),以便我們能在正確的時間打電話給您。

提供了一個子流程範本形式的參考實現,用於演示與該活動一起使用的 DTMF 提示和基本驗證。有關更多信息,請參閱 計劃回調子流程模板

通話進度分析

呼叫進度分析活動 (CPA) 能夠偵測回撥電話中的自動應答系統和真人語音。

當回撥嘗試遇到答錄機偵測 (AMD) 或語音信箱時,系統會將通話識別為失敗。應答機偵測 (AMD) 的結果被擷取到 CallbackFailed 事件處理程序的 reason 輸出變數中。基於此輸出變量,流程設計者可以配置回調重試。

  1. 為了方便回訪,可以將 CallProgressAnalysis 放置在主流程的 Callback 活動之後。對於預定回電或個人預定回電,可以將其放在主流程中的 NewPhoneContact 之後。
  2. 在事件流中,它僅在 CallbackFailed 事件處理程序中支援。
  3. 如果在流程中配置了通話後客戶調查(回饋活動),則當通話由 AMD 或語音信箱接聽時,不會啟動該調查。這樣可以避免觸發不必要的調查。

有關活動設定、用法和輸出變數的更多信息,請參閱 建置和管理流程 > 通話進度分析

正在排隊

概覽

在 Webex Contact Center 中,佇列用作傳入交互 (如電話、聊天、電子郵件或社交管道) 的保留區域。 聯絡人會駐留在佇列中,直到自動分發給代理或代理手動接聽處理。 此外,它們還支援基於技能的路由、優先順序管理和公平工作負載分配等功能。

監督員可以使用佇列觀察不同的工作線並改進聯絡中心處理任務的方式。

有效使用佇列的一些主要好處是:

  • 更好的客戶體驗: 管理等待時間,讓客戶知道他們正在排隊等待説明。
  • 提高效率: 確保有序處理呼叫,減少混亂和管理不善。
  • 公平分配聯絡人: 在代理之間平均分配通話,防止使任何單個代理負擔過重。
  • 優先順序處理: 允許對某些呼叫進行優先順序排序,例如 VIP 客戶或緊急問題。

佇列類型

Webex Contact Center 支援多種類型的佇列,為各種規模和複雜性的聯絡中心提供各種用例,跨越所有媒體類型,具有統一的功能。

有些佇列會考慮代理在路由聯絡方面的技能,有些佇列則會考慮此技能。 這些佇列在處理聯絡活動時,與代理的關聯方式也有所不同。

佇列分為兩大類:

  • 非基於技能的佇列
  • 基於技能的佇列

非基於技能的佇列

非技能佇列不考量與客服相關的技能。 您可以使用以下選項配置非基於技能的佇列:

  • 團隊配置
  • 代理指派

包含小組指派的非技能佇列

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

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

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

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

有關包含團隊分配的非技能佇列如何在 Webex Contact Center 中工作的工作流圖

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

第一個通話分派群組包含小組 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 的一部分,並且不與此佇列關聯。

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

可用的路由型式:

具有代理指派的非技能佇列

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

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

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

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

工作流圖,描述在 Webex Contact Center 中具有代理分配的非技能佇列示例的工作原理

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

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

可用的路由型式:

基於技能的佇列

基於技能的佇列可將聯絡人路由至具有適當技能的代理,以滿足其需求。

您可以設定以下類型的基於技能的選項:

指派到佇列的技術條件

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

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

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

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

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

工作流圖,描述具有技能條件的基於技能的佇列在 Webex Contact Center 中的工作方式示例

在此範例中,

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

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

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

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

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

在流程中分配的技能要求

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

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

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

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

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

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

工作流圖,其中描述了 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 現在也滿足聯繫人的“放鬆”技能要求。

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

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

可用的路由型式:

佇列組態設定

設定基於技能的佇列

將技能條件指派到佇列
  • 創造技能。
  • 創建 技能檔案
  • 直接將技能配置檔分配給代理。
  • 建立通道類型為「電話」或「聊天」、「電子郵件」或「社交」的佇列。
  • 在 Control Hub 中將技能需求指派給佇列。
  • 檢視可以處理佇列中聯絡的代理清單。
  • 選取路由演算法 LAA 或 BAA。
  • 在流程中新增佇列聯絡人活動並選擇此佇列。
將技能要求分配到佇列
  1. 創造技能。
  2. 創建 技能檔案
  3. 直接或將技能配置檔指派給代理或團隊。
  4. 建立 團隊
  5. 新增代理至小組。
  6. 建立通道類型為「電話」或「聊天」或「電子郵件」或「社交」的佇列。
  7. 將團隊添加到單個 CDG 或多個 CDG 中的佇列。
  8. 選擇路由型式 LAA 或 BAA。
  9. 在流程中新增佇列聯絡人活動,並選擇為其配置了基於技能的路由的佇列。 有關詳細資訊,請參閱 將聯繫人排隊。
  10. 在佇列聯絡活動中指派技能和技能放鬆。
  11. 在流程 POST 佇列中使用“升級通話分配活動”可快速移動到下一個通話分派群組或最後一個通話分派群組。

設定非技能佇列

將團隊指派到佇列
  • 建立 團隊
  • 新增代理至小組。
  • 建立通道類型為「電話」或「聊天」或「電子郵件」或「社交」的佇列。
  • 將團隊添加到單個 CDG 或多個 CDG 中的佇列。
  • 選擇路由型式 LAA。
  • 在流程中新增佇列聯絡人活動並選擇此佇列。
  • 在流程 POST 佇列中使用“升級通話分配活動”可快速移動到下一個通話分派群組或最後一個通話分派群組。
將客服指派至佇列流
  • 建立通道類型為「電話」或「聊天」或「電子郵件」或「社交」的佇列。
  • 將客服直接新增到佇列 (注意:此類佇列中不會使用技術或團隊)。
  • 選擇路由型式,如「循環」、「線性」或「最長可用代理」。

路由

路由概念

代理過剩情景

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

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

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

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 排名最高,然後是 Q2Q3

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

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

  • 在這些佇列中所有駐留的聯絡人中,只有 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 允許代理跨不同媒體類型 (語音、聊天、電子郵件和社交) 為聯絡人提供服務。 基於此配置,代理將獲取每種媒體類型配置的通道。

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

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

共有三種選擇:

  • 不包括

  • 混合

  • 混合 - 即時

在處理非語音聯絡活動時,代理有可用的語音通道,即可從 Agent Desktop 開始手動撥出語音通話。 這適用於所有多媒體設定檔類型。

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

路由型式

基於技能

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

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

最長可用

「最長可用」基於技能的路由型式會將聯絡人路由至其技術完全滿足聯絡人技能要求/佇列技術條件,且自處理最後一次聯絡活動以來,該代理在該佇列中所有符合條件的代理中,其可用時間最長。

此路由型式可將互動指派給可用時間最長的代理,從而在代理之間平均分配工作,從而防止工作量不平衡。 它有助於保持工作分配的公平性,確保沒有代理人負擔過重,而其他人則保持自由。

在上面的範例中,有 4 個代理具有熟練程度及非熟練程度,但熟練程度的技術值各不相同。

假設聯絡人排入具有「最長可用」路由型式的技術佇列:

  • 通過流程分配上述技能要求,或
  • 在基於技能的佇列中設定上述技能標準

在此方案中:

  • 只有完全符合聯絡人技能要求/佇列技能標準的代理才會被考量進行路由。 僅代理 A1A2A4 完全滿足聯絡人技能要求/佇列技能條件。

    代理 A3 不符合資格。 對於指派給佇列的技能條件, A3 甚至不與佇列關聯。

  • 在 A1 A2 A4 ,聯絡人將被路由至可用時間最長的代理–自 10 分鐘後一直有空的 A1,比 A2 或 A4 長。

    由於 A1 被指派聯絡人, A1 將不再是所有媒體管道中可用時間最長的代理。

  • 具有完全相同技能要求的下一個聯絡活動將被路由至下一個最長的可用代理– A2,依此類推。

以下類型的技能佇列支援此路由型式:

最佳可用

最佳可用技能型式可確保將客戶互動定向到最合格的座席。 此型式不僅會評估代理中是否存在必要技術,還會評估這些技術的熟練程度,並計算技術分數以確定每個聯絡人中最合格 (「最佳」) 的代理。

此型式會過濾其技能完全滿足聯絡人技能需求/佇列技能條件的可用客服。 然後,使用聯絡人技能要求/佇列技能標準中提到的所有技能的熟練程度值計算每個合格代理的分數。 技術得分最高的代理被視為每個聯絡活動的「最佳」代理。

實際上,與聯繫人技能要求/佇列技能條件匹配的代理技能值的總和決定了分數。

需要瞭解的一些關鍵點:

  • 通常,分數計算中使用實際技能值,因為技能分數越高表示匹配越強。 但當技術需求使用小於等於 (<=) 條件時,代理的特定技術值在分數計算中會反轉,即 effective_skill_value =(10)減去 (actual_skill_value)。 這樣做是為了確保分數越低表示匹配越強。
  • 當多個符合條件的代理具有相同的分數時,將選擇其中可用時間最長的代理
  • 計算分數時僅考慮熟練程度技能。 計算分數時不考慮聯繫人技能要求/佇列技能標準中的任何布爾、文本或枚舉技能。

在上面的範例中,有四個代理具有熟練程度及非熟練程度,但熟練程度的技術值各不相同。

假設聯絡人排入具有「最佳可用」路由型式的技術佇列:

  • 通過流程分配上述技能要求,或
  • 在基於技能的佇列中設定上述技能條件。

在此方案中:

  • 只有完全符合聯絡人技能要求/佇列技能標準的代理才會被考量進行路由。 僅代理 A1A2A4 完全滿足聯絡人技能要求/佇列技能條件。

    代理 A3 不符合資格。 對於指派給佇列的技能條件, A3 甚至不與佇列關聯。

  • 在 A1 A2 A4 ,分數計算由系統根據接觸技能要求/佇列技能標準完成,其中僅考慮熟練程度技能。

    計算分數時僅考量聯絡人技能要求/佇列技能標準中提及的技能,即使代理可能具有其他/其他熟練程度技能。

    另請注意,當使用小於等於 (<=) 條件時,分數計算中技能值的反轉。

  • 聯絡人被路由至 A2,因為根據分數,A2 是最佳可用代理。 如果 A2 不可用/忙碌,則會將聯絡人路由至得分第二高的下一個最佳可用代理,依此類推。

    但是,我們有 2 個代理– A1A4 ,得分次高。 聯絡活動被路由到 A1 A4 之間最長的可用代理。

以下類型的技能佇列支援此路由型式:

非技能型路由

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

最長可用

「最長可用」路由型式將聯絡人路由到佇列中自處理其最後一個聯絡活動以來,與該佇列關聯之所有代理中,該代理有空時間最長。

此路由模式通過將交互分配給空閒時間最長的代理來確保公平和平衡的工作負載分配。 通過防止工作負載不平衡,它可以確保沒有代理負擔過重,而其他代理則保持空閒。 此方法在聯絡流穩定的期間特別有效,可在整個代理池中保持一致的參與度。

當代理獲得任何媒體類型的聯絡活動時,所有管道中的「最長可用」位置都會丟失。 這表示代理處理聯絡之後,將會將任何媒體類型排入佇列的下一個聯絡指派給該佇列中第二長的代理。

在上述範例中,代理 A1 是可用時間最長的代理 (位置 1)- 此代理先登入或未獲派聯絡活動的時間長於任何其他代理。

代理 A2 (位置 2)與 A3 (位置 3)亦可用,但他們已登入或處理 A1 之後的聯絡活動。 所有代理皆與具有此路由型式的兩個佇列相關聯。

假設有下列場景:

  • 在時間 T0,語音聯絡 人 C1 排入佇列並路由至可用時間最長的代理,即 A1

    由於 A1 已指派 C1,A1 不再是所有媒體通道中可用時間最長的代理。

  • 聊天 聯絡人 C1 將排入佇列,並路由至可用時間最長的代理 (現在 為 A2 )。
  • 最後,在時間 T2,另一個語音聯繫人 C3 排隊並路由到 A3

    A1 和 A2 最近有聯繫——在這個時間點, 等待時間最長的是 A3

由於 Webex Contact Center 的高度分散式體系結構,當單個最長可用代理同時排入多個連絡人佇列到同一佇列時,這些聯接的可能性很小。

以下類型的非技能佇列支援此路由模式:

通函

迴圈路由型式會依輪循順序在一組可用的代理之間分配傳入的聯絡人。 聯絡排入佇列後,系統會根據預先指定的順序將其指派給佇列中的下一個可用代理。

此程序會從代理依設定的順序開始。 第一個來電的聯絡人將指定給該序列中第一個可用的代理。 對於後續的聯絡,系統會選取下一個可用的代理,並按照定義的佇列順序從中斷的位置繼續。 此型式重複,在代理之間循環,但始終在最後一個所選代理的位置之後開始。

此方法對於在代理之間公平、均勻地分配聯絡非常有效。 它有助於確保沒有一個代理被聯絡淹沒,並且所有代理都有平等的機會一致地處理交互。 但是,迴圈路由型式不會考慮當前工作負載或其他可能影響代理處理特定聯絡能力的因素。

在上面的示例中,代理按以下順序在迴圈佇列中配置: A3 → A4 → A5 → A6 → A1 → A2

首先,起始位置是配置順序 (A3) 中的第一個代理。 當聯絡人路由到此佇列中的代理時,該位置會繞圓圈移動,並依設定的順序定位到最後一個聯絡人所路由到的代理之後的代理。

假設有下列場景:

  • 第一個聯絡人 (C1) 已排入佇列,並路由至代理 A3

    指標將按配置的順序 (即 A4) 更新到下一個代理。

  • 當第二個聯絡活動 (C2) 排入佇列時,系統會開始尋找從 A4 開始的可用代理,即 A4 → A5 → A6 → A1 → A2 → A3

    但是, A4A5 不可用 (要麼它們甚至沒有登錄,要麼處於空閒狀態,要麼完全忙於此媒體類型的其他聯繫人),因此 C2 被路由到下一個可用的代理– A6。 指標將按配置的順序 (即 A1) 更新到下一個代理。

  • 同樣,第三個聯繫人 (C3) 路由到 A1,第四個聯繫人 (C4) 路由到 A2。 指標再次位於 A3

    此邏輯繼續,聯絡人以「循環」/「輪詢」模式在可用代理之間分配。

若佇列中存在駐留的聯絡人,代理剩餘情景會將在此媒體類型上可用的下一個代理,與其中最高優先順序、時間最久的聯絡人進行比對。

這不會考慮或影響此佇列中的現有位置值,僅當聯絡人剩餘路由與代理成功匹配時,該值才會更新。

以下類型的非技能佇列支援此路由模式:

由上而下

自上而下的路由型式會依序將來電聯絡人分配給一組可用與已排序的代理。 聯絡排入佇列時,系統總是從頭開始遍曆有序的代理清單,並按照該順序將聯絡人與第一個可用的代理 (該代理擁有聯絡人媒體類型的可用可用通道) 進行配對。

排入佇列的每個聯絡都會發生這種情況。 系統會嘗試配對聯絡人,一律從上面 (第一個設定的代理) 開始,然後沿著清單向下移動,直到找到相符的代理為止。

與迴圈路由型式不同,不存在根據最後所選代理的位置動態變更起點的“指標”。

此方法對於在根據管理員確定的某些偏差/偏好排序的代理之間分配聯絡人很有效。 它有助於確保始終優先於頂層的代理處理聯絡,而不是其下方的代理。 但是,自上而下的路由型式不會考慮目前的工作負荷或其他可能影響代理處理特定聯絡活動的因素。

在上面的範例中,代理按以下順序在自上而下的佇列中設定: A3 → A4 → A5 → A6 → A1 → A2

這表示系統管理員希望將每個聯絡人按設定的順序路由至第一個代理 (若可用)、後續代理 (A4)(如有空) ,依此類推。

假設有下列場景:

  • 第一個聯絡 (C1) 已排入佇列,並路由至代理 A3,因為 A3 位在訂單的頂部。
  • 當第二個聯絡人 (C2) 排入佇列時,會再次嘗試從順序頂部開始路由傳遞 (始終從 A3 開始)。

    如果 A3 具有此媒體類型的更多通道容量, 則 C2 也會路由到 A3。 但是,如果 A3 在此媒體類型上完全忙碌,則路由會沿著清單向下移動到 A4

  • 但是,A4 A5 不可用 (它們甚至沒有登錄,或者處於空閒狀態,或者完全忙於此介質類型的其他聯繫人),因此 C2 被路由到自上而下順序的下一個可用代理– A6
  • 同樣,嘗試從A3向下向底部路由第三個聯繫人 ( C3 )。 第一個匹配代理將是 A1

    此邏輯會繼續,直到聯繫人直到訂單底部才找到任何可用的代理,在這種情況下,它將駐留在佇列中。

以下類型的非技能佇列支援此路由模式:

基於代理的路由

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

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

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

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

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

Flow 中的佇列和路由功能

Flow 中的佇列和路由功能

在 Webex Contact Center 中,可以通過流程編排各種路由、佇列和通話控制功能。

可以將 Flow Designer 中提供的各種流活動和事件處理程式放置在流中,以有效地管理傳入和傳出聯繫人的生命週期。

有關設置和使用流的詳細資訊,請參閱 使用 Flow Designer 構建和管理流。

排隊活動

佇列聯絡人

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

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

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

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

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

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

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

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

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

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

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

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

在以下情況下,不支援使用佇列聯絡人活動:

  • 代理已指派給聯絡人。
  • 流程中提供了無效的佇列、技能或其他配置。
  • 聯絡人允許的進入點及佇列轉換最大數 (25) 已用盡。
  • 成功路由聯絡人 (20) 所允許的最大嘗試次數已用盡。

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

只有在選擇了具有團隊指派的佇列時,技能要求、技能放鬆和檢查代理可用性等功能才可在佇列聯絡人活動中使用。

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

佇列至代理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在以下情況下,不支援使用「佇列至代理」活動:
  • 代理已指派給聯絡人。
  • 提供無效的首選代理 ID 或電子郵件地址。
  • 提供的報告或恢復佇列無效。
  • 偏好的代理存在,但尚未登入、不可用或正於處理其他聯絡。

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

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

升級通話分派群組

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

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

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

在以下情況下,不支援使用升級通話分派群組活動:
  • 聯絡人尚未排入佇列。
  • 聯絡人在不支援通話分派群組概念的佇列中排入佇列。

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

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

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

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

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

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

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

佇列資訊活動

抓取佇列資訊

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

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

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

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

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

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

當通過變數選擇提供無效佇列時,不支援使用“獲取佇列資訊”活動。

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

在下列情形中,目前通話分派群組的即時佇列資訊不適用:
  • 執行「取得佇列資訊」活動時,聯絡人尚未排入佇列。
  • 聯絡人排入不支援通話分派群組概念的佇列中。

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

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

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

進階佇列資訊

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

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

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

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

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

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

在以下情況下,不支援使用「高級佇列資訊」活動:

  • 對於已指派技能條件至佇列的佇列,將會請求此資訊。
  • 聯絡人已排入佇列,但其佇列與請求提供資訊的佇列不同。
  • 聯絡人直接針對偏好的代理排入佇列。

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

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

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

通話控制活動

設定來電者 ID

設置呼叫者 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 秒)。 如果在此期間無代理可用,則可以將通話橋接 (含式取消佇列) 到外部客服中心處理該聯絡。

  1. 外傳通話流程和事件流程不支援橋接轉移活動。
  2. 不支援已指定給代理的聯絡人透過流程橋接。

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

斷開聯絡人

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

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

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

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

設定聯絡人優先順序

「設定聯絡人優先順序」活動允許為聯絡人指定特定的優先順序層級,從而促進流程中有效的聯絡人優先順序管理。 這樣可以提高或降低某些聯絡的重要性,確保當代理可用時,與其他等候聯絡相比,這些聯絡可以適當地路由。 這種靈活性允許在整個流程中精確控制聯繫人優先順序。

通過分配從 1 (最高) 到 9 (最低) 的層次結構重要性級別來確定優先順序。 最高優先順序的聯絡人會先於優先順序較低的聯絡人路由。 當多個聯絡共用相同的優先順序時,等待時間最長的聯絡將首先路由到下一個可用且符合條件的代理。 此系統可確保高優先順序的聯絡人得到及時的注意,同時根據同等優先順序的聯絡人等候時間保持公平。

  1. “設置聯繫人優先順序”活動可以放置在主流或事件流中的任何點。
  2. 如果在佇列活動 (如“將聯絡人排入佇列”或“將代理排入佇列”) 之前設定“設置聯絡人優先順序”活動,則其優先順序設定可能會被後續佇列活動中明確設定的任何優先順序覆蓋。 但是,若下列佇列活動未指定優先順序,則將套用之前的「設定聯絡人優先順序」活動所設定的聯絡人優先順序。
  3. 相反,如果在佇列活動 (如“將聯絡人排入佇列”或“將代理排入佇列”) 之後設定“設置聯絡人優先順序”活動,它將覆蓋前面佇列活動所設定的優先順序設定。
  4. 目前不支援撥出聯絡人和活動聯絡人使用「設定聯絡人優先順序」活動。

有關活動設置、使用方式和輸出變數的詳細資訊,請參閱 構建和管理流>設置聯繫人優先順序

回調活動

回撥

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

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

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

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

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

排定回撥

計劃回撥活動使流程能夠為客戶提供在特定的未來日期和時間請求回撥的便利,而無需立即連接到座席。 此功能使顧客能夠選擇方便的回撥視窗,從而最大程度地減少感知等待時間並降低通話放棄率,從而改善客戶體驗。

流必須通過 DTMF 提示捕獲調用方的輸入,例如首選日期和時間,並在執行必要的輸入驗證後將它們傳遞給活動。

在開始之前,請確保已在 Control Hub 的「通道設定」下 設定回 撥預設進入點 有關詳細資訊,請參閱 設置回調入口點

可以使用任何電話佇列 (無論是入站還是出站) 來排定回撥。 為了獲得最佳效果,建議在計劃回調活動之後立即添加“斷開連接”活動,以確保當前呼叫在計劃回調後正確結束。 有關計劃 IVR 回調的詳細資訊,請參閱 計劃 IVR 回調

當在請求的未來日期和時間觸發回調時,將創建新的通話或交互。 此新交互將遵循連結到回調預設入口點的標準流程。 如果回調嘗試失敗,流可以使用 CallbackFailed 事件處理程式 (如果在該流中配置) 自動重試呼叫

在將輸入傳遞到活動之前,應考慮以下輸入驗證:

  1. 日期選擇 - 您可以選擇從今天到未來 31 天的任何日期。 日期必須採用以下格式:YYYY-MM-DD (例如 2025-07-18)。
  2. 時間窗口開始和結束時間 - 您選擇的時間必須從現在起至少 30 分鐘開始,並且可以持續 Anywhere 30 分鐘到 8 小時之間。 請使用 24 小時制時間格式 (如 14:30:00)。
  3. 時區 - 您必須輸入 IANA 格式的有效時區 (如 美國/New_York),以便我們在適當的時間給您打電話。

以子流範本的形式提供參考實現,以演示與活動一起使用的 DTMF 提示和基本驗證。 有關更多資訊,請參閱 計劃回調子流範本

通話進度分析

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

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

  1. 出於禮貌回撥,CallProgressAnalysis 可以放置在主流中回調活動之後的某個點。 對於排定回撥或個人定時回撥,可以放在主流中的 NewPhoneContact 之後。
  2. 在事件流中,它僅在 CallbackFailed 事件處理程式中受支援。
  3. 如果在流程中配置了 POST 通話客戶調查 (反饋活動),則如果 AMD 或語音郵件接聽通話,則不會啟動該調查。 這可以防止觸發不必要的調查。

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

本文是否有幫助?
本文是否有幫助?