AWA ラウンドロビン割り当ての問題をトラブルシューティングする方法Summary この記事では、Advanced Work Assignment（AWA）の割り当ての問題、特にラウンドロビン割り当てシナリオにおける問題のトラブルシューティング方法について説明します。 Release N/A Instructions AWA のラウンドロビン割り当ての問題をどのようにトラブルシューティングするかの詳細に入る前に、まず AWA におけるラウンドロビンとは何かを理解しましょう。 ラウンドロビン割り当て: AWA には、Round-robin という名前の OOB の「Assignment rule」は存在しません。デフォルトでは、以下のスクリーンショットに示すように、OOB の Chat - Most Capacity Assignment Rule が提供されています。 ここで、「Assign by」を「Last assigned」に変更すると、システムはラウンドロビン方式で割り当てを実行しようとします。 つまり、利用可能なエージェントが 3 人（A1、A2、A3）存在し、割り当て対象のワークアイテムが 3 件（W1、W2、W3）ある場合、システムは次のように割り当てる必要があります。 W1 を Agent A1 に割り当てる W2 を Agent A2 に割り当てる W3 を Agent A3 に割り当てる しかし、実際には 3 人のエージェントが利用可能であるにもかかわらず、以下のように 3 件すべてのワークアイテムが同じエージェントに割り当てられるケースが確認されています。 W1 を Agent A1 に割り当てる W2 を Agent A1 に割り当てる W3 を Agent A1 に割り当てる これは、Assignment Rule に設定されているラウンドロビン割り当て戦略に反しています。 お客様がこの状況に遭遇した場合、以下の手順を実行して、AWA 割り当てで何が起きているかを確認できます。 理論： 利用可能なエージェントが 1 人しか存在しない場合、ラウンドロビン戦略は適用されません利用可能であり、かつキャパシティを持つエージェントが 1 人しか存在しない場合、ラウンドロビン戦略は適用されません以下のように Assignment Rule で必須スキルが強制されており、必要な必須スキルを持ち、かつキャパシティを持つ利用可能なエージェントが 1 人しか存在しない場合、ラウンドロビン戦略は適用されませんエージェントがドキュメントへのアクセス権を持っていないレコードへのアクセス権を持っている 上記の理論に基づくと、このような状況では 1 人のエージェントに対して最大キャパシティに達するまで同時にアイテムが割り当てられるため、ラウンドロビンは適用されません。 例えば、以下のスクリーンショットのように、Agent A1 に最大キャパシティ（3）までワークアイテムがオファーされたとします。 それでは、ラウンドロビン割り当ての問題の原因を特定するために、これらの理論を 1 つずつ除外していく方法を確認しましょう。 A.エージェントの利用可能状態 特定の時点でのエージェントの利用可能状態は、awa_agent_presence_history テーブルを確認することで把握できます。例えば、上記のサンプルシナリオでは Agent A1 が 1 月 25 日午前 3:46 に 3 件のワークアイテムを受け取っています。そのため、その時間帯の awa_agent_presence_history テーブルを確認する必要があります。 例えば、以下のスクリーンショットでは、1 月 24 日 21:00 から 1 月 25 日 05:00 までのデータが表示されています。 エージェントがオンラインになると、システムはこのテーブルにエントリを作成します。また、エージェントがオフラインになると、このテーブルにエントリを作成します。この履歴を確認することで、特定の時点でどのエージェントが利用可能だったかを確認できます。 Agent A1 のみが利用可能だった場合、そのエージェントには最大キャパシティに達するまで全てのワークアイテムが割り当てられます。 利用可能なエージェントが複数存在していたにもかかわらずラウンドロビンが適用されていなかった場合は、次の 2 つの理論を確認する必要があります。 B.エージェントのキャパシティ: エージェントの現在のキャパシティは awa_agent_capacity テーブルで確認できます。 ここで、「capacity in use」は現在の作業負荷を表します。「Capacity」は最大キャパシティを表します。 最大キャパシティは Service Channel のデフォルトキャパシティから取得されます。ただし、チャネルレベルでエージェントのキャパシティが上書きされている場合はその値が使用されます。 例えば、Agent A1 だけに空きがある場合、つまり max capacity = 3、capacity in use = 0 であり、他のエージェントが max capacity = 3 かつ capacity in use = 3 の場合、システムは Agent A1 のみを割り当て対象として考慮し、ラウンドロビンを実施する代わりに 3 件のワークアイテムを一度に割り当てます。 問題が過去に発生したものである場合は、awa_agent_capacity テーブルからその時点のエージェントのキャパシティを確認することはできません。その場合はノードログを確認する必要があります。 以下のスクリーンショットに示すキーワードを使用してノードログを確認できます。 これにより、その時点におけるエージェントのキャパシティを遡って把握する手がかりが得られます。エージェントのキャパシティがいっぱいの場合、workload は 0 と表示されます。 1 人のエージェントしかキャパシティを持っていない場合は、上記の情報を確認することで問題を説明できます。 それ以外の場合、キャパシティを持つエージェントが複数存在するのであれば、次の理論を確認する必要があります。 C.必須スキル ワークアイテムのドキュメントレコードについて、どのスキルが必要かを確認します。ドキュメントレコードは Incident、Case、または Interaction（チャットの場合）です。 影響を受けたワークアイテムについて、ドキュメントレコード番号（例: CS36559811）をコピーし、以下のように task_m2m_skill テーブルでフィルタリングします。 これにより、そのタスクをエージェントが取得するために必要なスキルを確認できます。 ドキュメントに必要なスキルがわかったら、利用可能なエージェントがそれらのスキルを持っているか確認します。 これは sys_user_has_skill テーブルで該当エージェントをフィルタリングすることで確認できます。 エージェントが必要なスキルを持っている場合、システムはそのエージェントを割り当て対象として考慮する必要があります。 D.ドキュメントへのアクセス権 エージェントが利用可能であり、キャパシティもあり、必須スキルも持っているにもかかわらず、システムがそのエージェントを割り当て対象として考慮しない可能性があります。 これは、ACL が原因でエージェントがドキュメントレコードへのアクセス権を持っていない場合に発生します。 Related Links<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } この記事はドラフト状態であり、他のエンジニアが内部で公開することの重要性を考慮して、いくつかのクリーンアップの後、公開することができます。