統一路由中的指派方法

適用於:Dynamics 365 Contact Center—嵌入、Dynamics 365 Contact Center—獨立,以及Dynamics 365 Customer Service

使用指派方法決定指派工作項目的方式。 您可以使用現成可用的指派方法,或透過設定優先規則和指派規則集來建立自訂指派規則。

自動化指派運作方式

整合路由中的自動指派流程會根據設定的指派規則,將傳入的工作項目指派給最適合的客戶服務代表 (服務代表或代表)。 這個連續的過程包含多個指派週期。

每個週期會挑選最主要未分配的工作項目,並嘗試將每個工作項目與適當的代表配對。 由於專員的無法出席或無法找到符合的技能,因此未指派給專員的工作項目將重新排入佇列。 下一個任務週期將挑選最高優先等級的項目,包括新的工作項目。

當工作項目找不到符合資格的代表時,指派週期會不斷嘗試分配該頻道適用的頂尖項目。

如需了解詳細資訊,請參閱 管理佇列的最佳做法

整合路由如何排定工作項目的優先順序

整合路由可在個別佇列中和在各個佇列間排定工作的優先順序。 佇列中的優先順序排定可以有下列類型:

  • 先進先出是預設的優先順序排定邏輯,適用於沒有優先順序規則的現成指派方法和自訂指派方法
  • 可使用自訂指派方法定義的自訂優先順序。

佇列中,最舊的交談或工作項目會被優先安排。 對於持續聊天和 WhatsApp、Facebook 等非同步傳訊管道,最舊的交談是根據上次互動時間來判定。 例如,週一有客戶透過 WhatsApp 聯絡你。 此問題在週二已解決,但對話仍然開放。 接著對話進入 等待狀態。 同一位顧客週四下午又帶著一個新問題回來。 其他顧客從星期四早上就一直在排隊等候。 回頭客僅在等待顧客之後才會被優先考慮。

對於記錄佇列,先進先出指派法是根據記錄被路由的時間來決定,也就是當相關實時工作項目被創建的時間。 在 了解統一路由如何影響路由紀錄的佇列項目與即時工作項目中了解更多。

如果你想根據對話建立時間來優先分配任務,可以使用自訂的優先順序規則。

當服務代表訂閱多個佇列時,你可以使用佇列的 「佇列優先權 」欄位來跨佇列優先處理工作。 較高優先順序佇列中的工作會優先於較低優先順序佇列進行指派。 也可以為多個佇列指定相同的優先順序。 在這種情況下:

  • 如果採用預設的先進先出順序,則會優先指派這些佇列中最舊的項目。
  • 如果這些佇列有自訂優先規則,則佇列會根據佇列名稱的字母順序進行排列,以確定優先順序最高的工作。

如果你同時根據現成指派方法和自訂優先順序規則來設定佇列,那麼採用現成指派方法的佇列會先被優先排序,接著是依照自訂優先順序規則排列的佇列。

例如,我們來看一下具有下列四個佇列的設定,所有佇列的優先順序都定義為 1:

  • VIP 支援和進階支援:預設先進先出優先順序
  • 訂單支援和發票查詢:自訂優先規則

對於訂閱所有四個佇列的代表,他們會從 VIP 支援和高級支援佇列中獲得最舊的項目。 如果這兩個佇列中沒有代表所需的合格項目,接下來就會先指派發票查詢佇列中的工作,然後再指派訂單支援佇列中的工作。

備註

建議您將不同的佇列優先順序指派給採用自訂優先規則的佇列。 即使這些佇列有相同的優先規則集,也會視為各不相同的佇列。

指派方法的類型

以下各節將說明現成可用的指派方法。

最高產能

系統會將工作項目指派給具有最高可用產能的服務代表。 所選代表具備在分類階段識別出的技能,其存在狀態符合工作流程中允許的某一存在狀態。 如果有多個代表具備相同的能力,則會依照輪詢方式分配工作項目。

如果要使用技能型路由,可以使用「完全匹配」和「最接近匹配」選項。

  • 如果將工作流中的預設技能比對演算法設定為完全相符,則系統會使用完全相符技能比對、工作流允許的目前狀態、產能需求來篩選代表,並依據可用產能來排序篩選出的代表。

  • 如果將工作流中的預設技能比對演算法設定為最近似匹配,則系統會根據工作流允許的代表出勤率和產能需求來篩選代表。 系統接著依據最接近的匹配以及不可用的產能對篩選出的代表進行排序。 如需了解更多資訊,請參閱最接近的符合項目

如果您需要在代表間公平地分配工作,則應考慮改用循環指派策略。

備註

修改評等模型時,具有該評等模型之技能的持續交談或開啟工作項目仍將繼續擁有現有的評等。 有時,此舉可能導致沒有符合分配條件的代表。

進階輪詢

系統會將工作項目指派給符合技能、目前狀態及產能準則的代表。 初始順序是根據使用者加入至佇列的時間而定。 接著根據指派來更新順序。 與工作項目依最高產能方法進行指派的情形相似,在循環配置資源指派中,工作項目是依照整合路由如何排定工作項目的優先順序中所述的方式來排定優先順序。

循環配置指派的順序依據佇列維持。 某些代表可以是多個佇列的一部分。 因此,根據代表在某個佇列中的最後指派時間戳記,可能會將來自不同佇列的工作項目連續地或同時地指派給代表。

在某些情況下,多位代表符合工作項目的需求。 如果數值排序相同,例如可用容量相同,系統會用輪流方式分配工作項目。 系統根據最後一次指派的最早時間來決定順序。

例如,三位代表 Lesa、Alicia 和 Alan 拥有咖啡退款技能,每位代表一次最多可以處理三個聊天。 他們的上次指派時間戳記分別為上午 10:30、上午 10:35 和上午 10:37。 佇列於上午 10:40 排入一項關於咖啡退款的工作項目。 將排序依據設定為「依據設定檔的可用產能」後,所有的代表在上午 10:40 都有相同的可用產能,即每人 2 個。 為了打破代表之間的平局,系統採用輪流法。 因此,系統會將傳入聊天指派給 Lesa,因為她最近一次的指派時間是最早的,為上午 10:30。 稍後在上午 10:45,如果另一個咖啡退款工作項目到來,則系統會將其指派給 Alicia。 此操作同樣採用輪詢分配。 Alicia和Alan的可用容量均為2人。 Alicia被分配到第一個,因為她最後一個任務是在上午10:35。

最不活躍

系統會將工作項分配給語音和消息佇列中所有代表中最不活躍且與所需技能、狀態和能力相匹配的代表。

指派方法使用「自上次釋放語音或傳訊交談產能以來的時間」和工作流程中設定的封鎖產能以進入總結設定來判定最不活躍的代表,並將下一通來電路由傳送給他們。

讓我們看看它是如何工作的,並帶有以下示例。

案例 1

Oscar Ward 和 Victoria Burke 是兩位具有相同技能的服務代表。 Oscar 負責 Members Messaging 佇列,而 Victoria 負責 Members MessagingReturns Voice 佇列。

  • 與 Oscar 的對話次數: 1 次聊天
  • 與 Victoria 的對話次數:1 次通話和 1 次聊天

下午 1:00,新的聊天交談到來。

由於 Oscar 同時進行的交談比 Victoria 少,因此將新的聊天指派給 Oscar。

案例 2

Maya 和 Hailey 是兩位具有相同技能的服務代表。 Maya 處理 Orders Messaging 佇列,而 Hailey 處理 Orders MessagingDelivery Voice 佇列。

假設 Hailey 一邊打電話一邊聊天,而 Maya 則在同時進行兩場聊天對話。

Maya 在下午 1:55 完成其中一次聊天,Hailey 在下午 2:00 完成聊天。 新的聊天在下午 2:05 開始。

  • 與 Hailey 的對話次數:1 次
  • 與 Maya 的對話次數:1 次聊天

由於 Maya 和 Hailey 都有相同的同時指派,因此最不活躍的指派策略會考慮語音和訊息佇列的上次產能釋放時間。

與 Hailey 相比,Maya 被確定為最不活躍,因此,新聊天被分配給 Maya。

路由至最不活躍代表的指派策略有助於在代表之間均衡分配工作項目,從而提高代表的工作效率和客戶滿意度。

您還可以構建 自定義報告 來跟蹤代表的 「Last Capacity Release time」 並瞭解代表之間的分配分配。 有關代表的上次產能釋放時間的數據在「msdyn_agentchannelstate」Dataverse 實體中提供。

這很重要

最少活躍的指派方法僅適用於語音和訊息頻道,且是建立語音或訊息隊列時的預設選項。

此功能旨在協助客戶服務經理或監督員增強其團隊的效能,並改善客戶滿意度。 此功能不適用於做出 (也不應用於做出) 會影響員工或員工群組雇用的決策,包括薪酬、獎勵、資歷或其他權利或應享權利。 客戶需完全負責使用 Dynamics 365、此功能及任何相關功能或服務,遵守所有適用法律,包括存取個別員工分析資料及監控、錄音與儲存與終端用戶通訊的相關法律。 這也包括充分通知最終使用者,他們與代表的通訊可能會被監控、記錄或儲存,並根據適用法律的要求,在與最終使用者一起使用該功能之前獲得最終使用者的同意。 我們也鼓勵客戶制定一種機制來通知他們的代表,系統可能會監視、錄製或儲存他們與使用者的通訊。

新建

您也可以建立自訂指派方式來符合業務需求。 系統允許您建立和使用自己的規則集和規則來設定優先順序、嚴重性和產能,以便選擇需要將工作項目路由到的佇列。 您可以建立下列規則集:

  • 優先規則集:允許您定義工作項目在代表可承接更多工作時指派給他們的順序。
  • 指派規則集:表示一組用於選取代表的條件,並使用「排序選項」來依匹配的代表進行排序。

這很重要

  • 雖然你可以建立自訂指派方法,但我們建議你使用現成且經過驗證且符合大多數使用情境的指派方法或選擇標準。
  • 你必須在自訂指派方法中設定出席、容量和技能匹配規則,因為工作流預設的設定不會在自訂指派方法中使用。
  • 現成可用的指派策略不考慮代表營運時間。 您必須使用規則定義中的「is_working」運算子來撰寫自訂指派方法。

指派週期

工作項目的指派週期涉及根據指派規則編排工作的優先順序,以選擇並指派給最適任的人員。 整合路由可將組織中跨多個佇列的指派週期最佳化,以獲得最佳效能。

指派週期會因下列其中一個觸發器而開始:

  • 佇列中有新的工作項目到達。
  • 變更為代表狀態。
  • 表示產能的更新:如果在執行階段更新產能,則產能的變更會觸發分配。 如果手動更新產能,變更就不會觸發指派。
  • 新增一名代表至佇列。
  • 工作項目的記錄類型每隔五分鐘週期性觸發一次。

優先規則集的運作方式

優先規則集是優先規則的順序清單。 每個優先級規則表示佇列中的優先權桶。 在優先規則中,您可以指定一組條件和排序依據屬性。 進行評估時,優先規則是依照規則列出的順序來執行。 對於第一個優先規則,佇列中符合條件的工作項目會被放入相同的優先順序桶中。 在優先區域中,項目按照優先規則指定的順序進一步排序。 第二個規則會對佇列中其餘的項目執行,以找出下一個優先順序貯體,並根據排序依據屬性排序該貯體,直到所有規則都已評估為止。

每個佇列只能建立一個優先規則集。

舉例來說,考慮在以下含四個規則的螢幕擷取畫面中所見的優先規則集。

優先順序排定案例的螢幕擷取畫面。

  • 在任何指派週期中,此優先規則集都會執行,而規則集內的規則將依照其列出的順序來執行。

  • 第一個規則「高優先順序和進階」,在佇列中尋找所有其中關聯案例優先順序為「高」且案例類別為「進階」的工作項目。 系統會使用這些工作項目建立最高優先的組,並按照Order by屬性所指定的「先進先出」方式對其進行排序。 佇列中要指派的第一個工作項目是此類別中最舊的項目。

  • 下一個優先順序的類別是案例類別為「高級」的工作項目。 前一項規則將工作項目放在「特級案件」類別和「高優先權」的最上層。 此規則僅考慮其他具有高級案件優先權的工作項目。 這種情況下的排序依據屬性也是「先進先出」。

  • 下一個優先级桶包括案件優先度高但尚未歸入任一桶中的工作項目。 系統依照「First Response By」欄位,依序從低到高排序工作項目。 也就是說,最早需要第一手回應的工作項目會優先排序。

一些關於優先規則的要點如下:

  • 每個佇列只能建立一個優先規則集。
  • 在每個指派週期中都會執行優先規則。 如果您變更工作項目的任何屬性 (例如案例的優先順序),則會在下一個指派週期中考慮該項變更。
  • 佇列預設會按照「先進先出」方式進行排序。 如果您沒有建立優先規則,則會先指派最早的工作項目。
  • 在一般情況下,當有足夠的處理者可以承接工作項目時,處理時間僅需幾秒鐘。 工作項目會依照優先順序指派給代表。 有時候,工作項目會堆積起來,因為合格的代表較少。 若代表在處理期間有空,系統會依優先順序提供下一個工作項目。 這種策略可能會讓人覺得最高優先級的項目沒有被分配。 當系統嘗試分配最高優先權項目,但它們仍留在佇列中時,會發生這種情況。
  • 系統會將不符合任何優先順序規則集的工作項目放入最後優先順序,並依先入先出排序。
  • 親和工作項目會跳過優先規則,而且此類的工作項目會先於佇列中其他工作項目獲得指派。 在 代表親和力中瞭解有關親和力的更多資訊。

動態優先順序的運作方式(預覽)

[本章節是預先發佈文件,可能會有變更。]

動態優先排序是一種由 AI 主導的方法,旨在根據以下條件提升對話(僅限語音與即時聊天)的優先權:

  • 增加等待時間:隨著顧客等待時間增加,優先順序也會提升。
  • 對話轉移:當對話在不同佇列間移動時,優先權提升。

「使用 AI 驅動的操作手冊配置對話編排」中了解更多。

優先分數系統

優先分數屬性的運作方式如下:

  • 保存對話中動態增加的優先值。
  • 累積增加增量值以維持即時優先評分。
  • 初始或基礎優先分數可透過分類規則設定。
  • 優先權遞增邏輯透過會話編排指南中的提示模板創建。
  • 任何啟用優先權升級的佇列,都不應該設定任何自訂優先順序規則。
  • 優先分數範圍為0到100,000。
  • 最短等待時間為30秒。
  • 平手決勝:當優先分數相等時,採用「先入先出」(FIFO)原則。

情境:等待時間增加

此情境會根據顧客在排隊中等待的時間,自動提升對話的優先順序。

觸發事件:對話正在排隊等待。

運作方式

  1. 當對話進入佇列時,遊戲手冊會評估已設定的條件。
  2. 根據匹配的上下文變數值,系統會在指定時間區間提升優先權分數。
  3. 系統會先將優先權較高的通話提供給代表,然後再處理優先權較低的通話。

Example:

客戶群 優先權提升 時間間隔
VIP客戶 20 每 30 秒
金階客戶 15 每 30 秒
所有其他客戶 5 每 30 秒

情境:佇列傳輸升級

當對話被轉移到特定佇列時,此情境會提升對話優先權。

觸發事件:對話被轉移到佇列。

運作方式

  1. 當你將對話轉移到該操作手冊啟用的佇列時,優先權會立即提高。
  2. 優先權提升是根據設定條件一次性調整。
  3. 轉接的對話會根據你的商業規則獲得適當的關注。

範例:優先權提升

客戶群 優先權提升
VIP客戶 50
升級轉移 30
其他轉會 10

範例:優先權更新

客戶群 優先權提升
VIP客戶 5
升級轉移 3
其他轉會 1

情境:基於等待時間的優先排序

操作手冊

每增加30秒的通話等待時間,遵循以下優先順序邏輯。

客戶群 優先權提升
鑽石 10
9
黃色 8
所有其他項目 1

播放時間軸

下表顯示動態優先權如何將屬於不同服務層級的客戶 A、B、C 和 D 分配優先權,當他們置於同一佇列時。

時間 佇列狀態 優先分數 註釋
T=0 A 進來 A=0 顧客A(黃色等級)抵達
T=10 B 進入 A=0, B=0 顧客B(黃色等級)抵達
T=20 C 進入 A=0, B=0, C=0 客戶C(金級)抵達
T=30 D 進入 A=8, B=0, C=0, D=0 A獲得+8加成,D(鑽石)抵達
T=31 有代表可用 A=8 已提供 分配A(最高分)
T=61 有代表可用 B=8, C=9, D=10 D接著發球(最高分)

主要結果:

  • 儘管有較高階的對話在排隊中,對話「A」並未被忽略。 長時間等待被納入優先考量。
  • 「C」和「D」這兩個對話雖然屬於較高層級,但也沒有被推到最前面。 他們會根據等級獲得更高的加成,但仍公平競爭。

與現有功能的整合

特徵 / 功能 整合行為
自訂優先順序規則 動態優先排序指南不適用於已設定自訂排序規則的佇列。 在啟用優先升級或更新 Playbook 之前,先移除佇列中的任何自訂的優先排序規則。
跨隊列優先排序 以優先分數作為排序的主要依據
FIFO 佇列 更新優先權分數動作可用於將優先權設定為隊列中的預設值,以符合嚴格的 FIFO 行為
分類規則 可以設定初始或基礎優先分數

指派規則集的運作方式

指派規則集是一個有序的指派規則清單。 每個指派規則代表一組條件,用於決定要選擇的代表和排序的依據字段。 在執行階段,具有最高順序的指派規則會先進行評估。 代表是根據規則中指定的條件進行配對。 若存在多個匹配代表,則依排序欄位排序,並指派最頂端代表完成工作。 如果沒有匹配到任何相符的代表,則會評估規則集中的下一個指派規則。 此方法逐步放寬指派限制。 系統首先套用最嚴格的標準,然後再降低條件以尋找最佳代表者。 如果找不到相符的代表,則工作專案會留在佇列中。

在指派規則中,系統使用者屬性會與工作項目的需求進行比對。 選取靜態比對時,條件會在系統使用者實體屬性與靜態值上形成。 選取動態比對時,左側條件會根據系統使用者的根實體而定,而右側條件則根據交談根實體而建立。 您可以從對話根實體向下鑽取兩個層級來形成規則條件。 使用動態比對和靜態比對的指派規則如下。

使用動態比對及靜態比對條件的指派規則螢幕擷取畫面。

指派規則的元件

分配規則包含以下項目:

  • 順序:指定在規則集中評估分配規則的順序。 順序值較小的規則會先執行。 如果有任何規則找到相符的使用者,則不會評估下一組規則。

  • 名稱:是唯一規則名稱。

  • 條件:是用來評估並將使用者與傳入工作屬性匹配的運算式。 條件有三個部分:

    • 使用者屬性:可用於將使用者屬性與傳入工作進行比較的屬性。 使用者屬性可以是以下之一:
      • 選取 [系統使用者] 表格中的屬性
      • 目前狀態:由整合路由服務根據使用者工作負載及手動選取進行維護。
      • 產能:由整合路由服務根據使用者工作負載及手動選取進行維護。
      • 使用者技能:表示與使用者相關聯、可用於執行技能型指派的技能。
      • 行事曆排程:使用者服務排程行事曆中所表示之使用者的排程。
      • 機器人屬性:僅在將代理設定為使用者並想做比較時使用。
    • 運算子:定義使用者屬性與傳入工作項目屬性之間的比較關聯。

    備註

    自訂指派不支援定義現場層級安全性的屬性。

    整合路由會篩選屬性特定運算子,供您從中選擇。 一些適用於屬性類型的特殊運算子如下所示。

    屬性類型 運算子 Definition
    出勤狀態 等於、不等於、包含資料、不包含資料 使用運算子來尋找存在狀態與工作項目所指定之存在狀態相符的代理人。
    容量 等於、不等於、包含資料、不包含資料 使用運算子來比較代表是否有足夠產能可處理指定的項目。
    注意:系統會在自訂指派中隱式進行產能配置檢查,但對於以單位為基礎的產能,您需要指定條件。
    使用者技能 完全相符 請使用接線員尋找具備該新工作項目所需所有技能的代表。
    使用者技能 自定義對戰 使用運算子在執行階段根據工作項目上所選查找屬性,比對並尋找技能符合的代表。
    行事曆排程 正常運作中 使用此操作員來尋找依據服務日程表工作的代表。 自動化指派僅考慮代表性行事曆排程,而不會考慮佇列所定義的營運時間。
    • :將使用者屬性與此值進行比較,以尋找適當的代表。 此值可以是靜態值,例如「地址 1: 國家/地區等於 "美國"」。 此值也可以是動態值,讓您可以動態地將使用者屬性與工作項目上的值進行比較。 在動態值中,您可以選取工作項目或相關記錄上的任何屬性。 例如,以下條件會找到與案件相關客戶國家/地區相符的使用者國家/地區。

      範例動態比對的螢幕擷取畫面。

      有些運算子並不需要值。 這些條件可以是描述狀態,例如「包含資料」、「不包含資料」及「行事曆排程:正在運作中」。

      至於使用者技能,運算子已預先定義其值。 如需了解詳細資訊,請參閱設定技能型路由

  • 排序依據:如果有多個代表符合規則中的條件,您可以使用「排序依據」子句尋找最合適的代表。 您可以指定以下的排序條件:

    • 排序屬性

      • 最少活躍:僅限於語音和訊息佇列。 工作項目會被分配給最不活躍且符合所需技能、出席度與能力的代表。 如需了解詳細資訊,請參閱指派方法的類型區段。
      • 循環輪替
      • 以單位計算的可用產能
      • 以設定檔計算的可用產能
      • 熟練度
      • 技能數量
    • 使用者屬性:這些屬性是在系統使用者實體中定義。

下列案例透過螢幕擷取畫面說明範例指派規則。

範例指派方法。

第一個條件指定「使用者技能」,其中特定運算子需與之精確匹配。 然後評估使用者屬性。 指定不同的使用者屬性時,利用運算子設定每個屬性的值,例如存在狀態屬性的值應等於「可用」或「忙碌」。 在運算子的右側,您可以指定要與屬性進行比對的值。 這些值可以是「靜態」,例如「狀態等於 [可用] 或 [忙碌]」。 如果你指定「動態」,該條件會在執行時根據你指定的表達式來匹配。 例如,你可以設定「偏好客戶類型等於對話。聯絡人。會員等級」。 系統接著將每位代表的「偏好客戶類型」與該客戶計算的聊天會員等級進行比對。

動態比對會降低針對可能值的每個排列組合撰寫和維護多個靜態規則所需投入的精力。

對重複提供工作項目給代表的限制

代表可以接受或拒絕透過自動指派獲得的工作項目。 拒絕允許通知逾時都會視為拒絕工作項目。 如果代表以任一方法拒絕工作項目,則在下次嘗試指派時,他們對該交談的優先順序會降低。 在下列案例中,對於同一個工作項目,可能會重新考慮該代表最多三次或指定的限制次數:

  • 該代表具備處理拒接通話的獨特資格,且符合容量與出席要求。
  • 其他所有合格代表都拒絕。

如果代表拒絕同一個工作項目三次或達到設定的限制次數,則不再考慮自動指派該特定工作項目給此代表。 系統會接著嘗試將拒絕的工作項目指派給佇列中其他合格的代表。 代表仍然可以手動挑選工作項目。

例如,代表 Serena Davis 兩次拒絕客戶 Ana Bowman 的聊天,而在第三次嘗試中,指派通知逾時。 系統將此視為三次拒絕,自動分配功能不會再次將同樣的聊天提供給 Serena Davis。 但系統會將 Ana Bowman 的聊天轉給其他符合條件的代表。 此外,Serena Davis 會被考慮用於處理其他傳入的對話,但 Ana Bowman 拒絕的聊天不在此列。

備註

如果所有配對代表因代表可用性不足或工作需要特定技能與熟練度而拒絕該工作項目,該工作仍留在排隊中。 同樣地,如果有100位代表拒絕某項工作項目,自動指派不會在後續的指派週期中考慮該工作項目。 主管可以手動指派,或其他代表,包括曾拒絕的代表,也可以接手。

您可以根據組織的需求,將預設的 3 次拒絕限制更新為 1 到 5 之間的值。 該限制適用於組織中的所有管道。

您可以按照以下方式進行 OData 呼叫,以檢查您組織的限制。

<org-url>/api/data/v9.0/msdyn_omnichannelconfigurations?$select=msdyn_number_of_declines_allowed

如果 OData 呼叫回傳 null 值,表示下降上限設為預設值 3。

您可以按以下方式更新 OData 呼叫以修改限制。

var data = { "msdyn_number_of_declines_allowed": 3 } // update the record Xrm.WebApi.updateRecord("msdyn_omnichannelconfiguration", "d4d91600-6f21-467b-81fe-6757a2791fa1", data).then( function success(result) { console.log("Omnichannel Configuration updated"); // perform operations on record update }, function (error) { console.log(error.message); // handle error conditions } );

設定指派方法及規則
關於整合路由的常見問題
對話診斷
建立工作流
建立佇列
設定記錄的整合路由
設定整合路由的技能型路由