適用対象: Dynamics 365 Contact Center—組み込み、Dynamics 365 Contact Center—スタンドアロン、Dynamics 365 Customer Service
割り当て方法を使用して、作業項目の割り当て方法を決定します。 標準の割り当て方法を使用したり、優先度ルールセットと割り当てルールセットを構成することにより、ユーザー定義の割り当てルールを作成したりすることができます。
自動割り当ての仕組み
統合ルーティングの自動割り当てプロセスでは、構成された割り当てルールに基づいて、受信作業項目が最適な顧客サービス担当者 (サービス担当者 または 担当者) と照合されます。 この継続的なプロセスは、複数の割り当てサイクルで構成されます。
各サイクルは、割り当てられていない上位の作業項目を選択し、各作業項目を適切な担当者と照合しようとします。 使用不可のため、または一致するスキルが見つからなかったために担当者に割り当てられていない作業項目は、キューに戻されます。 次の割り当てサイクルでは、新しい作業項目を含む次の優先度の高い項目が選択されます。
該当する担当者が作業項目に対して見つからない場合、割り当てサイクルでは、チャネルに該当する上位項目の割り当てが再試行され続けます。
詳しくは キュー管理のベスト プラクティスをご覧ください。
統合ルーティングで作業項目に優先順位を付ける方法
統合ルーティングは、個々のキュー内およびキュー間での作業に優先順位を付けます。 キュー内の優先順位付けには、次のタイプがあります。
- 先入れ先出し法は、優先順位付けルールがない既定の割り当て方法と カスタム割り当て方法 に適用される既定の優先順位付けロジックです。
- カスタム割り当て方法で定義できるカスタムの優先順位付け。
キュー内の最も古い会話または作業項目が最初に割り当てられます。 常設チャット、WhatsApp、Facebook などの非同期メッセージング チャネルの場合、最も古い会話は最後の対話時間に基づいて決定されます。 たとえば、月曜日に WhatsApp で顧客から連絡が来たとします。 問題は火曜日に解決されますが、会話は開いたままです。 その後、会話は 待機状態になります。 同じ顧客が木曜日の午後に新しい質問を返します。 他のお客様は木曜日の朝からキューで待っています。 再来店の顧客は、待機している顧客の後にのみ優先されます。
レコード キューの場合、先入れ先出しの割り当て方法は、レコードがルーティングされた時刻 (関連付けられたライブ作業項目が作成された時刻) に基づきます。 詳細については、「 統合ルーティングがルーティングされたレコードのキュー アイテムとライブ作業項目に与える影響を理解する」を参照してください。
会話の作成時間に基づいて割り当てに優先順位を付ける場合は、カスタムの優先順位付けルールを使用できます。
サービス担当員が複数のキューにサブスクライブされている場合は、キューの [キューの優先度 ] フィールドを使用して、キュー間で作業に優先順位を付けることができます。 プライオリティの高いキューからの作業は、プライオリティの低いキューよりも最初に割り当てられます。 キューにも同じ優先順位を付けることができます。 そのような場合:
- 既定の先入れ先出しの順序になっている場合は、これらすべてのキューの中で最も古い項目が最初に割り当てられます。
- カスタムの優先順位付けルールがある場合、キューはキュー名に基づいてアルファベット順に並べられ、最も優先度の高い作業が決定されます。
既定の割り当て方法とカスタムの優先順位規則の両方に基づいてキューを構成した場合、標準の割り当て方法を持つキューが最初に優先され、その後、カスタムの優先順位規則に基づくキューが続きます。
たとえば、次の 4 つのキューがあり、すべて優先度が 1 と定義されている設定を見てみましょう。
- VIP サポートとプレミアム サポート: 既定の先入れ先出しの優先度設定
- 注文サポートと請求書の照会: カスタム優先順位付けルール
4 つのキューすべてに登録している担当者は、VIP サポートとプレミアムサポートのキューから最も古いアイテムを受け取ります。 これら 2 つのキューに 担当者 の対象となる品目がない場合は、請求書照会キューの作業が次に割り当てられ、その後に注文サポート キューの作業が割り当てられます。
Note
カスタムの優先順位付けルールを使用して、キューに個別のキューの優先順位を割り当てることをお勧めします。 キューの優先順位付けルールセットが同じであっても、それらは別個のものと見なされます。
割り当て方法の種類
すぐに使用できる割り当て方法については、以降のセクションで説明します。
最大キャパシティ
作業項目は、使用可能な容量が最も高い サービス担当者 に割り当てられます。 選択した 担当者 には、分類段階で識別されたスキルと、作業ストリームで許可されているプレゼンスの 1 つと一致するプレゼンスがあります。 同じ能力の担当者が複数いる場合、作業項目はラウンドロビン方式で割り当てられます。
スキルベースのルーティングを使用する場合は、「完全一致」と「最も近い一致」のオプションを使用できます。
作業ストリームの既定のスキル マッチング アルゴリズムを完全一致に設定した場合、システムは完全一致のスキル、作業ストリームで許可されるプレゼンス、キャパシティ要件を使用して担当者をフィルターし、フィルターされた担当者を利用可能なキャパシティで並べ替えます。
作業ストリームの既定のスキル マッチング アルゴリズムを最も近い一致に設定すると、システムは作業ストリームで許可されているプレゼンスとキャパシティ要件に基づいて担当者をフィルターします。 次に、フィルターされた代表は、最も近い一致と利用可能なキャパシティではなくの順に並べられます。 詳細については、最も近い一致を参照してください。
担当者間で公平に作業を配分する必要がある場合は、ラウンド ロビン割り当て戦略に切り替えることを検討する必要があります。
Note
評価モデルを変更すると、その評価モデルのスキルを持つ進行中の会話または開いている作業項目には、引き続き既存の評価が適用されます。 このアクションにより、割り当て条件に一致する担当者がいない場合があります。
詳細なラウンド ロビン
システムが、スキル、プレゼンス、キャパシティの条件に一致する担当者に作業項目を割り当てます。 最初の順序は、ユーザーがキューに追加された順序に基づきます。 その後は割り当てに基づいて順序が更新されます。 最大容量の方法で作業項目が割り当てられる方法と同様に、ラウンド ロビン割り当てでは、統合ルーティングが作業項目に優先順位を付ける方法で説明したように、作業項目に優先順位が付けられます。
ラウンドロビン割り当ての順番は、各キューごとに維持されます。 一部の担当者は、複数のキューの一部になることができます。 したがって、キュー内の 担当者 の最後の割り当てタイムスタンプに応じて、担当者には、異なるキューから連続または同時実行の作業項目が割り当てられる場合があります。
ある場合には、複数の担当者が作業項目の要件を満たします。 同じ使用可能な容量など、値による順序に同じ順位がある場合、システムはラウンド ロビンを使用して作業項目を割り当てます。 システムは、最後の割当の最も早い時刻に基づいて注文を決定します。
たとえば、Lesa、Alicia、Alan の 3 人の担当者は、コーヒーの返金スキルを使用でき、一度に最大 3 つのチャットを処理できます。 最終割り当てのタイムスタンプは、それぞれ午前 10:30、午前 10:35、午前 10:37 です。 午前10時40分、コーヒーの払い戻しに関するワークアイテムがキューに入ります。 Order by を "プロファイル ベースの使用可能キャパシティ" に設定すると、午前 10 時 40 分の担当者全員に、それぞれ 2 という同じ利用可能キャパシティがあります。 代表者間の引き分けを解消するために、システムはラウンドロビンを使用します。 Lesaの直近の作業時間が午前10時30分と最も早かったため、彼女に新しいチャットを割り当てます。 その後、午前 10 時 45 分に別のコーヒー返金作業項目が到着すると、システムはそれを Alicia に割り当てます。 このアクションでは、ラウンド ロビン割り当ても使用されます。 アリシアとアランはどちらも2の利用可能な容量を持っています。 最後の割り当てが前の午前 10 時 35 分に行われたため、アリシアが最初に割り当てられます。
最もアクティブでない
システムは、音声およびメッセージング キューのすべての担当者の中で最もアクティブで、必要なスキル、プレゼンス、およびキャパシティに一致する担当者に作業項目を割り当てます。
割り当て方法では、「音声またはメッセージングの会話の最後の容量が解放されてからの時間」とワークストリームで構成された後処理の容量をブロックする設定を使用して、最も非アクティブな担当者を特定し、次の着信通話をその担当者にルーティングします。
次の例でどのように機能するか見てみましょう。
シナリオ 1
Oscar Ward と Victoria Burke は、同じスキルを持つ 2 人のサービス担当者です。 Oscar は Members Messaging キューで作業し、Victoria は Members Messaging キューと Returns Voice キューで作業します。
- オスカーとの会話数:1チャット
- ビクトリアとの会話の数:通話1回とチャット1回
午後 1:00 に、新しいチャット会話が到着します。
Oscar は Victoria よりも同時会話が少ないため、新しいチャットは Oscar に割り当てられます。
シナリオ 2
マヤとヘイリーは、同じスキルを持つ2人のサービス担当者です。 Maya は Orders Messaging キューで作業し、Hailey は Orders Messaging キューと Delivery Voice キューで作業します。
Hailey が通話とチャットを同時に行っている間、Maya が 2 つのチャット会話を行っているとします。
Maya は午後 1 時 55 分にチャットの 1 つを完了し、Hailey は午後 2 時 00 分にチャットを完了します。 新しいチャット会話が午後 2 時 5 分に到着します。
- ヘイリーとの会話数:1通話
- Mayaとの会話数:1チャット
Maya と Hailey の両方に同じ同時割り当てがあるため、最もアクティブでない割り当て戦略では、音声キューとメッセージング キューの両方で最後のキャパシティ解放時間が考慮されます。
Maya は Hailey と比較して最もアクティブでないと判断されたため、新しいチャットは Maya に割り当てられます。
最もアクティブ度の低い 担当者 割り当て戦略にルーティングすると、担当者間で作業項目をバランスよく分散させることができ、担当者 効率が向上し、顧客満足度が向上します。
また、 カスタム レポート を作成して、担当者の "最後のキャパシティ リリース時間" を追跡し、担当者間の割り当ての分布を把握することもできます。 担当者の最後の容量リリース時間に関するデータは、「msdyn_agentchannelstate」Dataverse エンティティで利用できます。
Important
最もアクティブでない割り当て方法は、音声およびメッセージング チャネルでのみ使用でき、音声キューまたはメッセージング キューを作成するときの既定の選択です。
この機能は、顧客サービス マネージャまたは管理者がチームのパフォーマンスを向上させ、顧客満足度を向上させるのに役立ちます。 この機能は、補償、報酬、年功、その他の権利や資格など、従業員または従業員グループの雇用に影響を与える決定を行うために使用されることは意図されていません。また、決定を行うために使用されるべきではありません。 お客様は、個々の従業員の分析と監視へのアクセス、記録、エンド ユーザーとの通信の保存に関連する法律を含む、適用されるすべての法律に従って、Dynamics 365、この機能、および関連するすべての機能またはサービスの使用について単独で責任を負います。 これには、担当者との通信が監視、記録、または保存される可能性があることをエンドユーザーに適切に通知し、適用される法律で要求されているように、機能を使用する前にエンドユーザーから同意を得ることも含まれています。 顧客はまた、エンドユーザーとの通信が監視、記録、または保存される可能性があることを担当者に通知するメカニズムを用意することが推奨されます。
新規作成
ビジネス ニーズに合わせてカスタム割り当て方法を作成することもできます。 このシステムでは、独自のルールセットとルールを作成して使用し、優先度、重大度、作業アイテムをルーティングする必要のあるキューを選択するキャパシティを構成することができます。 次のルールセットを作成できます。
- 優先度ルールセット: より多くの作業を行えるときに作業項目が担当者に割り当てられる順序を定義できます。
- 割り当てルールセット: 担当者を選択し、一致する担当者をオプションの順序で並べ替えるために使用する一連の条件を表します。
Important
- カスタムの割り当て方法を作成できますが、ほとんどのユース ケースで堅牢で検証済みの既定の割り当て方法または選択基準を使用することをお勧めします。
- ワークストリームに定義されている既定の設定はカスタム割り当て方法では使用されないため、カスタム割り当て方法でプレゼンス、容量、スキル照合ルールを構成する必要があります。
- デフォルトの割り当て戦略では、担当者の営業時間は考慮されません。 ルール定義で 「is_working」 演算子を使用して、カスタム割り当てメソッドを作成する必要があります。
割り当てサイクル
割り当てサイクルとは、割り当てルールに基づいて、作業項目の優先順位付け、選択、最適な担当者への割り当てを行うことです。 統合ルーティングは、組織内の複数のキューにわたる割り当てサイクルを最適化して、最高のパフォーマンスを実現します。
割り当てサイクルは、次のいずれかのトリガーで始まります:
- 新しい作業項目がキューに到着しました。
- 代表者のプレゼンスを変更。
- 担当者容量の更新: 容量が実行時に更新されると、容量の変更によって割り当てがトリガーされます。 キャパシティが手動で更新された場合、変更によって割り当てはトリガーされません。
- キューへの代表者の追加。
- 作業項目のレコードタイプに対して、5分ごとに定期的にトリガーを設定します。
優先度ルールセットの動作
優先度ルールセットは、優先度ルールの順序付きリストです。 すべての優先度ルールは、キュー内の優先度バケットを表します。 優先度ルールでは、一連の条件と属性の順序を指定できます。 評価中、優先度ルールは一覧表示されている順序で実行されます。 最初の優先度ルールでは、条件に一致するキュー内の作業項目が同じ優先度バケットに配置されます。 優先度バケット内で、アイテムは優先度ルールで指定された順序でさらに並べ替えられます。 2 番目のルールは、キュー内の残りの項目に対して実行され、次の優先度バケットを識別し、すべてのルールが評価されるまで並び替え属性によってバケットを並べ替えます。
キューごとに作成できる優先度ルールセットは 1 つだけです。
例として、次の 4 つのルールのスクリーンショットに示すような優先順位付けルールセットについて考えてみます。
割り当てサイクル中は、この優先順位付けルールセットが実行され、ルールセット内のルールはリストに記載された順に実行されます。
「最初のルール『高優先度とプレミアム』では、キュー内の作業項目のうち、関連するケースの優先度が「高」であり、ケースカテゴリが「プレミアム」であるものがすべて見つかります。」 システムがこれらの作業項目を含む最優先のバケットを作成し、並び替え属性で指定されている「先入れ先出し」の方法で並べ替えます。 キューから割り当てられる最初の作業項目は、このバケット内の最も古い項目になります。
次の優先度の高い項目は、ケースカテゴリが「プレミアム」の作業項目です。 前のルールでは、上位バケットに Premium ケース カテゴリと優先度が高い作業項目が配置されました。 このルールでは、Premium ケースの優先度を持つ他の作業項目のみが考慮されます。 このケースでは、順序属性も「先入れ先出し」です。
次の優先度バケットには、まだバケットに含まれていない、高い優先度の作業項目が含まれます。 システムは、作業項目を [最初の応答別 ] フィールドで昇順に並べ替えます。 つまり、最初の応答が最も早く必要な作業項目が最初に優先されます。
優先順位付けルールに関するいくつかの重要なポイントは次のとおりです:
- キューごとに作成できる優先度ルールセットは 1 つだけです。
- 優先順位付けルールは、すべての割り当てサイクルで実行されます。 ケースの優先度など、作業項目の属性を変更した場合、その変更は次の割り当てサイクルで考慮されます。
- 既定では、キューは「先入れ先出し」ベースで並び替えされます。 優先順位付けのルールを作成しない場合は、最も古い作業項目が最初に割り当てられます。
- 通常のシナリオでは、作業項目を引き受けるのに十分な数の担当者が利用できる場合、処理期間はわずか数秒です。 担当者には、優先順位に従って作業項目が割り当てられます。 資格のある担当者が少なくなるため、作業項目が積み重なることがあります。 処理中に担当者が利用可能になると、優先順位に基づいて次の作業項目が提供されます。 この戦略により、最も優先度の高い項目が割り当てられなかったという認識が生まれる可能性があります。 この状況は、システムが優先順位の高い項目を割り当てようとしたが、キューに残っている場合に発生します。
- 優先順位付けルールセットと一致しない作業項目は、最後の優先度バケットに配置され、先入れ先出しで並べ替えられます。
- アフィニティ作業項目の優先順位付けルールがスキップされ、そのような作業項目はキュー内の他の作業項目よりも先に割り当てられます。 アフィニティの詳細については、「 代表アフィニティ」を参照してください。
動的な優先順位付けのしくみ (プレビュー)
[このセクションはプレリリースのドキュメントであり、変更される可能性があります。
動的な優先順位付けは、次に基づいて会話の優先順位を高める AI 主導のアプローチです (音声とライブ チャットのみ)。
- 待機時間の増加: 顧客が長く待つと優先度がエスカレートされます。
- 会話の転送: 会話がキュー間で移動するときの優先度の向上。
詳細については、「 AI を利用したプレイブックを使用して会話オーケストレーションを構成する」を参照してください。
優先度スコア システム
優先度スコア属性は次のように機能します。
- 会話の動的に増加する優先度の値を保持します。
- 実行中の優先度スコアを維持するために、増分値を累積的に追加します。
- 初期優先度スコアまたは基本優先度スコアは、分類ルールを使用して設定できます。
- 優先順位の増分ロジックは、会話オーケストレーション プレイブックのプロンプト テンプレートを使用して作成されます。
- 優先度のエスカレーションが有効になっているキューには、カスタムの優先順位付け規則を構成しないでください。
- 優先度スコアの範囲は 0 ~ 100,000 です。
- 最小待機時間は 30 秒です。
- タイブレーク: 優先度スコアが等しい場合は、"先入れ先出し" (FIFO) が使用されます。
シナリオ: 待機時間のエスカレーション
このシナリオでは、顧客がキューで待機する時間に基づいて、会話の優先順位が自動的に上がります。
トリガー イベント: 会話がキューで待機しています。
どのように機能するのか
- 会話がキューに入ると、プレイブックによって構成された条件が評価されます。
- 一致するコンテキスト変数値に基づいて、システムは指定された時間間隔で優先度スコアを増やします。
- システムは、優先順位の低い会話よりも優先順位の高い会話を最初に担当者に提供します。
Example:
| 顧客セグメント | 優先度の引き上げ | 時間間隔 |
|---|---|---|
| VIP のお客様 | 20 | 30 秒ごと |
| Gold レベルのお客様 | 15 | 30 秒ごと |
| その他すべての顧客 | 5 | 30 秒ごと |
シナリオ: キュー転送エスカレーション
このシナリオでは、会話が特定のキューに転送されるときに、会話の優先順位が高くなります。
トリガー イベント: 会話がキューに転送されます。
どのように機能するのか
- このプレイブックがアクティブなキューに会話を転送すると、優先度がすぐに増加します。
- 優先順位の引き上げは、構成された条件に基づく 1 回限りの調整です。
- 転送された会話は、ビジネス ルールに基づいて適切な注意を受けます。
例: 優先順位のエスカレーション
| 顧客セグメント | 優先度の引き上げ |
|---|---|
| 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 (Gold レベル) が到着する |
| 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" は、上位レベルに属していても上位にプッシュされませんでした。 彼らは彼らのレベルに比例してより高いブーストを受け取ったが、それでもかなり競争した。
既存の機能との統合
| 特徴 | 統合の動作 |
|---|---|
| カスタムの優先順位付け規則 | 動的な優先順位付けプレイブックは、カスタムの優先順位付け規則で構成されたキューには適用されません。 優先順位をエスカレートまたは更新プレイブックを有効にする前に、キュー内のカスタム優先順位付け規則を削除します。 |
| キュー間の優先順位付け | 優先度スコアを主要な並べ替え条件としてサポート |
| FIFO キュー | 更新優先度スコア アクションを使用して、厳密な FIFO 動作のためにキュー内の既定値に優先順位を設定できます |
| 分類ルール | 初期または基本の優先度スコアを設定できます |
割り当てルールセットの動作
割り当てルールのセットは、割り当てルールの順序付けされたリストです。 各割当ルールは、選択する代表者を決定するために使用される一連の条件と、一致する代表者を並べ替えるための order-by フィールドを表します。 実行時に、最上位の割り当てルールが最初に評価されます。 ルールで指定された条件に従って、担当者が照合されます。 一致する担当者が複数存在する場合は、並べ替え順フィールドで並べ替え、上位の担当者に作業が割り当てられます。 一致する担当者が見つからない場合、ルール セット内の次の割り当てルールが評価されます。 このメソッドは、割り当て制約を徐々に緩和します。 システムは、最初に最も厳密な基準を適用し、条件を減らして最適な代表を見つけます。 一致する担当者が見つからない場合、作業項目はキューに残ります。
割り当てルールでは、システム ユーザーの属性を作業項目の要件と照合します。 静的一致を選択した場合、条件はシステム ユーザー エンティティ属性と静的値で形成されます。 動的一致を選択すると、左側の条件はシステムユーザーのルート エンティティに基づいており、右側の条件は会話のルート エンティティに基づいています。 会話のルートエンティティを 2 階層までドリルダウンして、ルール条件を形成することができます。 動的一致と静的一致の割り当てルールは次のとおりです。
割り当てルールのコンポーネント
割り当てルールは、次の項目で構成されます。
順序: ルールセットで割り当てルールが評価される順序を指定します。 下位のルールが最初に実行されます。 いずれかのルールでユーザーが一致する場合、次のルールセットは評価されません。
名前: 一意のルール名です。
条件: 受信する作業の属性とユーザーを一致させるために評価される式です。 条件は 3 つの部分で構成されています:
-
ユーザー属性: 受信した作業とユーザーの比較に使用できるユーザーのプロパティです。 ユーザー属性には、次のいずれかを指定できます。
- システム ユーザー テーブルで属性を選択します。
- プレゼンス ステータス: ユーザーの作業量と手動選択に基づく統一ルーティング サービスによって維持されます。
- キャパシティ : ユーザーの作業量と手動選択に基づいて統一ルーティングサービスによって維持されます。
- ユーザー スキル: スキル ベースの割り当てを行うために使用できる、ユーザーに関連するスキルを表します。
- カレンダー スケジュール: ユーザー サービスのスケジュール カレンダーに表示されるユーザーのスケジュールです。
- ボット属性: エージェントをユーザーとして構成し、それらを比較する場合にのみ使用できます。
- 演算子: ユーザー属性と受信作業項目属性の間の比較関係を定義します。
Note
フィールド レベルのセキュリティが定義されている属性は、カスタム割り当てではサポートされていません。
統一ルーティングでは、属性別の演算子をフィルターして選択できます。 属性タイプで使用できるいくつかの特別な演算子は次のとおりです。
属性タイプ Operator 定義 プレゼンス状態 等しい、等しくない、データを含む、データを含まない 演算子を使って、作業項目で指定されたプレゼンス ステータスに一致する担当者を探します。 容量 等しい、等しくない、データを含む、データを含まない 演算子を使用して、担当者が指定された品目に取り組むのに十分な能力があるかどうかを比較します。
注意: カスタム割当ではキャパシティ プロファイル チェックが暗黙的に実行されますが、ユニット ベースの容量の場合は、条件を指定する必要があります。ユーザースキル 完全一致 オペレーターを使用して、受信作業項目に必要なすべてのスキルを持つ担当者を見つけます。 ユーザースキル カスタム照合 演算子を使用して、作業項目で選択したルックアップ属性に基づいて、実行時にスキルが一致する担当者を検索します。 カレンダー スケジュール 処理中 この演算子を使用して、サービス スケジュール カレンダーに従って作業している担当者を検索します。 自動割り当てでは、代表的なカレンダースケジュールのみが考慮され、キューに定義された営業時間は考慮されません。 価値: ユーザー属性がこの値と比較され、適切な担当者が検索されます。 値は静的にすることができます (例: 住所 1 の国が 「USA」 に等しい)。 値は動的にすることもできるため、ユーザー属性を作業項目の値と動的に比較できます。 動的な値では、作業項目または関連レコードの任意の属性を選択できます。 たとえば、次の条件は、ケースに関連付けられている顧客の国/地域と一致する国/地域を持つユーザーを検索します。
一部の演算子では、値は必要ありません。 「データが含まむ」、「データが含まない」、「カレンダーのスケジュール: 稼働中」などの条件が考えられます。
ユーザー スキルの場合、値はオペレーター用に事前定義されています。 詳細については、スキル ベースのルーティングを設定するを参照してください。
-
ユーザー属性: 受信した作業とユーザーの比較に使用できるユーザーのプロパティです。 ユーザー属性には、次のいずれかを指定できます。
並び替え: 複数の担当者がルールの条件に一致する場合、「Order by」句を使って最も適した担当者を選ぶことができます。 次の ORDER BY句を指定できます:
順序の属性:
- 最小アクティブ: 音声キューとメッセージング キューでのみ使用できます。 作業項目は、必要なスキル、プレゼンス、容量に一致する最もアクティブでない担当者にルーティングされます。 詳細については、割当方法の種類セクションをご覧ください。
- ラウンド ロビン
- 単位ベースの使用可能なキャパシティ
- プロファイル ベースの使用可能なキャパシティ
- 習熟度
- スキル数
ユーザー属性: これらの属性は、システム ユーザー エンティティで定義されます。
サンプルの割り当てルールは、スクリーンショットとともに次のシナリオで説明されます。
最初の条件は、演算子が「ユーザースキル」に完全一致していることを指定します。 次に、ユーザー属性が評価されます。 プレゼンス状態属性のような異なるユーザー属性は、各属性ごとに演算子と値を指定し、「応答可能」や「取り込み中」といった値になります。 演算子の右側で、属性を照合する値を指定できます。 値は「プレゼンスの状態がオンラインまたは取り込み中と等しい」といった静的なものにすることができます。 "dynamic" を指定した場合、指定した式に基づいて実行時に条件が一致します。 たとえば、「優先顧客タイプが会話.連絡先.会員レベルと等しい」と指定できます。 その後、各担当者の "優先顧客の種類" と、チャットの顧客の計算されたメンバーシップ レベルが照合されます。
動的一致では、可能な値の順列や組み合わせごとに複数の静的なルールを記述して管理する手間が省けます。
担当者に作業項目を繰り返し提供する際の制限
担当者は、自動割り当てによって提供される作業項目を承認または拒否できます。 拒否 と 通知のタイムアウトの許可の両方 は、作業項目の辞退と見なされます。 担当者 がいずれかの方法で作業項目を拒否した場合、その会話の優先度は、次の割り当ての試行中に低下します。 担当者 は、次のシナリオで、同じ作業項目に対して最大 3 回、または指定された制限まで再検討される可能性があります。
- 担当者は、拒否された会話に対して一意の資格を持ち、容量とプレゼンスの要件を満たしています。
- その他の資格のある代表者はすべて辞退します。
担当者 が同じ作業項目を 3 回拒否するか、構成された制限に達した場合、担当者 はその特定の作業項目の自動割り当ての対象とは見なされなくなります。 次に、システムは、辞退された作業項目をキュー内の他の適格な担当者に割り当てようとします。 担当者は、引き続き手動で作業項目を選択できます。
たとえば、担当者 Serena Davis が顧客の Ana Bowman からのチャットを 2 回拒否し、3 回目の試行で割り当て通知がタイムアウトしたとします。 システムでは、3 回の拒否と見なされ、自動割り当ては再びセレナ・デイビスに同じチャットを割り振りません。 ただし、システムは Ana Bowman からのチャットを他の適格な担当者に提供します。 また、Serena Davis は、Ana Bowman からの拒否されたチャットを除く、他の着信会話の候補として考慮されます。
Note
担当者の空き時間が少ない、または作業に特定のスキルと能力が必要なため、一致するすべての担当者が作業項目を辞退した場合、作業はキューに残ります。 同様に、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 } );
関連情報
割り当て方法とルールを構成する
統一ルーティングに関するよくあるご質問
会話診断
作業ストリームの作成
キューの作成
レコードのために統合ルーティングを設定する
統合ルーティング用スキル ベース ルーティングの設定