統合ルーティングでの割り当て方法

割り当て方法を使用して、作業項目の割り当て方法を決定します。 標準の割り当て方法を使用したり、優先度ルールセットと割り当てルールセットを構成することにより、ユーザー定義の割り当てルールを作成したりすることができます。

自動割り当ての仕組み

統合ルーティングの自動割り当てプロセスは、構成された割り当てルールに基づいて、受信した作業項目を最適なエージェントと照合します。 この継続的なプロセスは、複数の割り当てサイクルと作業項目のデフォルトのブロック サイズで構成されます。

各サイクルは、適用できる既定ブロック サイズのうち上位の未割り当て作業項目を選択し、各作業項目を適切なエージェントと照合します。 エージェントが不在であるか、適切なスキルの一致が見つからなかったためにエージェントに割り当てられなかった作業項目は、キューに戻されます。

次の割り当てサイクルは、新しい作業項目を含む最優先項目の次のブロックを選択します。

作業項目に適格なエージェントが見つからない場合、割り当てサイクルはチャネルに適用可能なデフォルト サイズのブロック項目の上位番号を割り当てるために再試行を続けます。

デジタル メッセージングと音声の場合、既定ブロック サイズは最優先する 100 件の作業項目です。

レコード チャネルの場合、

  • キューごとに優先順位が付けられる作業項目の数は 10,000 です
  • 割り当てのために処理される作業項目の数はデフォルトで 2,000 です

注意

クロスキュー優先順位付けは統合ルーティングでは利用できません。

詳細については、キュー管理のベスト プラクティス を参照してください。

割り当て方法の種類

次の割り当て方法を、標準で使用することができます。

  • 最も高いキャパシティ: 利用可能な能力が最も高いエージェントに作業項目を割り当てます。 このエージェントは分類段階で特定されたスキルを持ち、ワークストリームで許可されたプレゼンスに一致します。 作業項目は、先入れ先出し方式で優先順位付けされます。つまり、最初に作成された作業項目が最初に割り当てられます。 同じ能力を持つエージェントが複数いる場合、最も高い能力が同じエージェントのラウンド ロビン順位に基づいて作業項目が割り当てられます。

    スキル ベースのルーティングを使用する場合は、

    • 作業ストリームの既定のスキル マッチング アルゴリズム完全な一致に設定してから、システムは、完全なスキルの一致、作業ストリームのプレゼンスおよびキャパシティ要件を使用してエージェントをフィルタリングし、利用可能なキャパシティによってフィルタリングされたエージェントを順序付けます。

    • 作業ストリームの既定のスキル マッチング アルゴリズム最も近い一致に設定してから、システムは、作業ストリームのプレゼンスとキャパシティ要件に基づいてエージェントをフィルタリングし、利用可能なキャパシティではなく、最も近い一致によってフィルタリングされたエージェントを順序付けます。 詳細情報: 最も近い一致

    エージェント間で公平に作業を配分する必要がある場合は、ラウンド ロビン割り当て戦略に切り替えることを検討する必要があります。

注意

評価モデルを変更すると、その評価モデルのスキルを持つ進行中の会話または開いている作業項目には、引き続き既存の評価が適用されます。 これにより、割り当て基準に一致するエージェントが存在しない場合があります。

  • 詳細なラウンド ロビン: スキル、プレゼンス、キャパシティの条件に一致するエージェントに作業項目を割り当てます。 最初の順序は、ユーザーがいつキューに追加されるかに基づきます。 その後は割り当てに基づいて順序が更新されます。 最大容量方式での作業項目の割り当て方法と同様に、ラウンド ロビン割り当てでは、先入れ先出し方式で作業項目が優先順位付けされ、最初に作成された作業項目が最初に割り当てられます。

    ラウンド ロビン割り当ての順序はキュー単位で維持されます。 一部のエージェントは複数のキューに含まれる場合があります。 したがって、エージェントのキューにおける最後の割り当てタイムスタンプによっては、エージェントは異なるキューから、背中合わせに、あるいは同時に作業項目を割り当てられる可能性があります。

    複数のエージェントが作業項目の要件にマッチし、「order by」 で同順位になった場合、たとえば、同じ利用可能なキャパシティを持つ複数のエージェントがマッチした場合、システムは最後に割り当てられた最も早い時間に基づいて、ラウンドロビンを使用して割り当てを解決します。

    たとえば、Lesa、Alicia、Alan という 3 人のエージェントはコーヒー返金のスキルを備えており、一度に最大 3 つのチャットを処理できます。 最終割り当てのタイムスタンプは、それぞれ午前 10:30、午前 10:35、午前 10:37 です。 午前10時40分、コーヒーの払い戻しに関するワークアイテムがキューに入ります。 オーダーを 「プロファイルベースの利用可能なキャパシティ」 に設定すると、午前 10:40 すべてのエージェントの利用可能なキャパシティは、それぞれ同じ 2 になります。 エージェント間の関係を解消するために、システムはラウンドロビンを使用します。 Lesa の最後の割り当てが午前 10 時 30 分と最も早かったため、作業項目を割り当てます。 その後、午前 10 時 45 分に別のコーヒー返金作業項目が到着すると、システムはそれを Alicia に割り当てます。 これは、Alicia と Alan がラウンドロビンで割り当てられた順番にも基づいています。これは、2人の利用可能なキャパシティはそれぞれ 2 であり、Alicia は午前 10 時 35 分に Alan より早く割り当てられたためです。

  • 最もアクティブではない: 必要なスキル、プレゼンス、およびキャパシティに一致するすべてのエージェントの中で最もアクティブでないエージェントに作業項目を割り当てます。

    この割り当て方法では、"音声コールの容量が最後に解放されてからの時間" とワークストリームで構成したラップアップ設定を使用して、最もアクティブでないエージェントを決定し、次の着信コールをそのエージェントにルーティングします。 たとえば、キュ​​ー内に 2 人のエージェントがいるとします。 最初のエージェントは 5 分前に通話を完了し、2 番目のエージェントは通話を完了したところです。 新しい電話がかかってくると、システムはその通話を、最初にアクティビティを終了した 1 番目のエージェントに割り当てます。

    最もアクティブでないエージェント割り当て戦略へのルーティングにより、エージェント間で作業項目をバランスよく分散することができ、その結果、エージェントの効率と顧客満足度の向上につながります。

    カスタム レポートを構築して、エージェントの「最後のキャパシティ リリース時間」を追跡し、エージェント全体の割り当て分布を把握することもできます。

    重要

    最もアクティブでない割り当て方法は、音声チャネルでのみ利用可能で、音声キューを作成する際のデフォルト選択です。

    この機能は、顧客サービス マネージャまたは管理者がチームのパフォーマンスを向上させ、顧客満足度を向上させるのに役立ちます。 この機能は、補償、報酬、年功、その他の権利や資格など、従業員または従業員グループの雇用に影響を与える決定を行うために使用されることは意図されていません。また、決定を行うために使用されるべきではありません。 この機能は、Dynamics 365、および関連するすべての機能またはサービスの使用については、すべての適用法令 (個々の従業員の分析へのアクセス、エンドユーザーとの通信の監視、記録、および保存に関する法令を含む) に準拠したお客様の責任となります。 これには、エージェントとの通信が監視、記録、または保存される可能性があることをエンドユーザーに適切に通知すること、および適用される法律で要求されているように、機能を使用する前にエンドユーザーから同意を得ることも含まれています。 顧客はまた、エンドユーザーとの通信が監視、記録、または保存される可能性があることをエージェントに通知するためのメカニズムを用意することを推奨します。

ビジネス ニーズに合わせてカスタム割り当て方法を作成することもできます。

  • 新規作成: 独自のルールセットやルールを作成して使用し、作業項目をルーティングする必要のあるキューを選択する際の優先度、重大度、容量を構成することができます。 次のルールセットを作成できます。

    • 優先度ルールセット: より多くの作業を行えるときに作業項目がエージェントに割り当てられる順序を定義できます。
    • 割り当てルールセット: エージェントを選択し、一致するエージェントをオプションの順序で並べ替えるために使用する一連の条件を表します。

    重要

    • カスタム アサインメント方式ではワークストリーム用に定義された既定設定は使用されないため、カスタム アサインメント方式で、存在、キャパシティ、スキルマッチング ルールを構成する必要があります。
    • 既成の割り当て戦略では、エージェントの稼働時間が考慮されていません。 ルール定義で 「is_working」 演算子を使用して、カスタム割り当てメソッドを作成する必要があります。

割り当てサイクル

割り当てサイクルとは、割り当てルールに基づいて、作業項目の優先順位付け、選択、最適なエージェントへの割り当てを行うことです。 統合ルーティングは、組織内の複数のキューにわたる割り当てサイクルを最適化して、最高のパフォーマンスを実現します。

割り当てサイクルは、次のいずれかのトリガーで始まります:

  • キュー内の新しい作業項目の受信。
  • エージェント プレゼンスの変更。
  • エージェントのキャパシティの更新。
  • キューへのエージェントの追加。
  • レコードの種類が作業項目に対して 5 分ごとに定期的にトリガーします。

優先度ルールセットの動作

優先度ルールセットは、優先度ルールの順序付きリストです。 すべての優先度ルールは、キュー内の優先度バケットを表します。 優先度ルールでは、一連の条件と属性の順序を指定できます。 評価中、優先度ルールは一覧表示されている順序で実行されます。 最初の優先度ルールでは、条件に一致するキュー内の作業項目が同じ優先度バケットに配置されます。 優先度バケット内で、アイテムは優先度ルールで指定された順序でさらに並べ替えられます。 2 番目のルールは、キュー内の残りの項目に対して実行され、次の優先度バケットを識別し、すべてのルールが評価されるまで並び替え属性によってバケットを並べ替えます。

キューごとに作成できる優先度ルールセットは 1 つだけです。

例として、次の 4 つのルールのスクリーンショットに示すような優先順位付けルールセットについて考えてみます。

優先度シナリオのスクリーンショット。

  • 割り当てサイクル中は、この優先順位付けルールセットが実行され、ルールセット内のルールはリストに記載された順に実行されます。

  • 「最初のルール高優先度とプレミアム」では、キュー内のすべての作業項目のうち、関連するケースの優先度が「高」で、ケース カテゴリが「プレミアム」である作業項目が検索されます。 システムがこれらの作業項目を含む最優先のバケットを作成し、並び替え属性で指定されている「先入れ先出し」の方法で並べ替えます。 キューから割り当てられる最初の作業項目は、このバケット内の最も古い項目になります。

  • 次の優先バケットは、ケース カテゴリが「プレミアム」の作業項目です。 プレミアムのケース カテゴリーと優先度「高」となっている作業項目は、前述のルールですでにトップ バケットに入れられているため、このルールでは、ケース優先度が「プレミアム」となっている他の作業項目のみを考慮します。 このケースでは、並び替え属性も「先入れ先出し」です。

  • 次の優先度のバケットは、ケースの優先度が高く、まだバケット化されていない作業項目で構成されます。 ここでは、作業項目は「最初の対応者」フィールドの昇順で並べられています。つまり、早急に対応が必要な作業項目から優先的に対応します。

優先順位付けルールに関するいくつかの重要なポイントは次のとおりです:

  • キューごとに作成できる優先度ルールセットは 1 つだけです。
  • 優先順位付けルールは、すべての割り当てサイクルで実行されます。 ケースの優先度など、作業項目の属性を変更した場合、その変更は次の割り当てサイクルで考慮されます。
  • 既定では、キューは「先入れ先出し」ベースで並び替えされます。 優先順位付けのルールを作成しない場合は、最も古い作業項目が最初に割り当てられます。
  • 通常のシナリオでは、十分な数のエージェントが作業項目を処理できる場合、処理時間はわずか数秒です。 エージェントには優先順位に従って作業項目が割り当てられます。 ただし、対象となるエージェントが少ないために作業項目が山積みになり、処理期間中にエージェントが利用可能になった場合、エージェントは優先順位に従って次の作業項目を提供されます。 この戦略により、特に、いくつかの最優先のアイテムが割り当てが試みられたが、まだキューに残っている場合に、最も優先度の高いアイテムが割り当てられていないという認識が生じる可能性があります。
  • 優先順位付けルールセットのいずれの基準にも一致しない作業項目は、最後の優先順位バケットに保持され、「先入れ先出し」の順序で並べられます。
  • アフィニティ作業項目の優先順位付けルールがスキップされ、そのような作業項目はキュー内の他の作業項目よりも先に割り当てられます。 アフィニティについては、エージェントのアフィニティにアクセスしてください。

割り当てルールセットの動作

割り当てルールのセットは、割り当てルールの順序付けされたリストです。 各割り当てルールセットは、一致するエージェントを選択し、フィールドの順序で並べ替えるエージェントを決定するために使用される一連の条件を表します。 実行時に、最上位の割り当てルールが最初に評価されます。 ルールで指定された条件に従って、エージェントが照合されます。 一致するエージェントが複数存在する場合は、フィールド順で並べ替えられ、最上位のエージェントに作業が割り当てられます。 一致するエージェントがない場合は、ルールセット内の次の割り当てルールが評価されます。 このメソッドは、最初に最も厳しい基準を適用し、次に条件を徐々に減らして最適なエージェントを探していくように、割り当ての制約を徐々に緩和していくと考えることができます。 一致するエージェントが見つからない場合、作業項目はキューに残ります。

割り当てルールでは、システム ユーザーの属性を作業項目の要件と照合します。 静的一致を選択した場合、条件はシステム ユーザー エンティティ属性と静的値で形成されます。 動的一致を選択すると、左側の条件はシステムユーザーのルート エンティティに基づいており、右側の条件は会話のルート エンティティに基づいています。 会話のルートエンティティを 2 階層までドリルダウンして、ルール条件を形成することができます。 動的一致と静的一致の割り当てルールは次のとおりです。

動的一致と静的一致条件の割り当てルールのスクリーンショット。

割り当てルールのコンポーネント

割り当てルールは、次の項目で構成されています:

  • 順序: ルールセットで割り当てルールが評価される順序を指定します。 下位のルールが最初に実行されます。 いずれかのルールでユーザーが一致する場合、次のルールセットは評価されません。

  • 名前: 一意のルール名です。

  • 状態: 受信する作業の属性とユーザーを一致させる際に評価する式です。 条件は 3 つの部分で構成されています:

    • ユーザー属性: 受信した作業とユーザーの比較に使用できるユーザーのプロパティです。 ユーザーの属性には、次のいずれかを指定できます:

      • システム ユーザー テーブルで属性を選択します。
      • プレゼンス ステータス: ユーザーの作業量と手動選択に基づく統一ルーティング サービスによって維持されます。
      • キャパシティ : ユーザーの作業量と手動選択に基づいて統一ルーティングサービスによって維持されます。
      • ユーザー スキル: スキル ベースの割り当てを行うために使用できる、ユーザーに関連するスキルを表します。
      • カレンダー スケジュール: ユーザー サービスのスケジュール カレンダーに表示されるユーザーのスケジュールです。
      • ボットの属性: ボットをユーザーとして構成し、そのボットに対して何らかの比較を実行する場合にのみ使用できます。
    • 演算子: ユーザー属性と受信作業項目属性の間の比較関係を定義します。

      統一ルーティングでは、属性別の演算子をフィルターして選択できます。 属性タイプで使用できるいくつかの特別な演算子は次のとおりです。

      属性の種類 オペレーター 定義
      プレゼンスの状態 等しい、等しくない、データを含む、データを含まない 演算子を使って、作業項目で指定されたプレゼンス ステータスに一致するエージェントを探します。
      容量 等しい、等しくない、データを含む、データを含まない 演算子を使って、指定された項目に取り組むのに十分な容量があるかどうかを比較します。
      スキルの使用 完全一致 演算子を使用して、次の作業項目に必要なすべてのスキルを持つエージェントを見つけます。
      スキルの使用 カスタム照合 演算子を使用して、作業項目で選択したルックアップ属性に基づいて、実行時にスキルが一致するエージェントを検索します。
      カレンダー スケジュール 処理中 この演算子を使用して、サービス スケジュール カレンダーに従って作業しているエージェントを検索します。
    • 価値: ユーザー属性がこの値と比較され、適切なエージェントが検索されます。 値は静的にすることができます (例: 住所 1 の国が 「USA」 に等しい)。 値は動的にすることもできるため、ユーザー属性を作業項目の値と動的に比較できます。 動的な値では、作業項目または関連レコードの任意の属性を選択できます。 たとえば、次の条件は、ケースに関連する顧客の国と同じ国のユーザーを検索します。

      動的一致のサンプルのスクリーンショット。

      一部の演算子では、値は必要ありません。 「データが含まむ」、「データが含まない」、「カレンダーのスケジュール: 稼働中」などの条件が考えられます。

      ユーザー スキルの場合、値はオペレーター用に事前定義されています。 詳細情報: スキル ベースのルーティングを設定する

  • 並び替え: 複数のエージェントがルールの条件に一致する場合、「Order by」句を使って最適なエージェントを見つけることができます。 次の Order by 句を指定できます:

    • 順序の属性:

      • 最もアクティブではない: 音声キューでのみ使用できます。 作業項目は、スキル、プレゼンス、および能力に一致するすべてのエージェントの中で最もアクティブでないエージェントにルーティングされます。 詳細については、割り当て方法のタイプ セクションをご覧ください。
      • ラウンド ロビン
      • 単位ベースの使用可能なキャパシティ
      • プロファイル ベースの使用可能なキャパシティ
      • 能力
      • スキル数
    • ユーザー属性: これらの属性は、システム ユーザー エンティティで定義されます。

サンプルの割り当てルールは、スクリーンショットとともに次のシナリオで説明されます。

割り当て方法のサンプル。

最初の条件は、演算子が完全一致で、「スキルの使用」を指定しています。 次に、ユーザー属性が評価されます。 在籍の状態 が「応答可能」または「取り込み中」と等しい、などさまざまなユーザー属性を各属性の演算子と値で指定できます。 演算子の右側で、属性を照合する値を指定できます。 「プレゼンスの状態がが応答可能または取り込み中と等しい」など、値は静的なものです。 「動的」を指定すると、指定した式に基づいて実行時に条件が照合されます。 たとえば、「優先する顧客の種類が Conversation.Contact.Membership レベルに等しい」を指定すると、チャットに関連付けられている顧客のメンバーシップ レベルが動的に計算され、すべてのエージェントの「優先する顧客の種類」と照合されます。

動的一致では、可能な値の順列や組み合わせごとに複数の静的なルールを記述して管理する手間が省けます。

エージェントに作業項目を繰り返し提供する際の制限

エージェントは、自動割り当てによって作業項目を提供された場合、通常、承諾または拒否することができます。 通知の 拒否タイムアウト の両方が拒否と見なされます。 同じ作業項目を 3 回辞退したエージェントは、特定の作業項目の以降の自動割り当ての対象と見なされません。 システムは、キュー内の他のエージェントに資格がある場合、拒否された作業項目を提供しようとします。

たとえば、エージェントの Serena Davis が顧客の Ana Bowman からのチャットを 2 回拒否し、3 回目で割り当て通知がタイムアウトしたとします。 システムはこれを 3 度の辞退とみなし、自動割り当てで 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 } );

参照

割り当て方法とルールを構成する
Customer Service の統合ルーティングに関する FAQ、Customer Service 用オムニチャネル
統合ルーティングの診断
作業ストリームの作成
キューの作成
レコードのために統合ルーティングを設定する
統合ルーティング用スキル ベース ルーティングの設定