オムニチャネルルーティングに含まれるキャパシティルールは、自動的に割り当てられる作業にキャパシティを設定することで、チームの作業負荷のバランスをとるのに役立ちます。標準のオムニチャネルルーティング設定では、適格なステータスを持つチャネルで空いているキャパシティが最大のエージェントに仕事を割り当てます。たとえば、1人のエージェントに割り当てることができるオープンメールチケットは、一度に10件までと指定することができます。これは、経験の浅いエージェントが成長するまでの間、あまり多くの作業を割り当てられないようにするための優れた方法です。
ただし、オムニチャネルルーティングをラウンドロビン割り当てに設定することもできます。ラウンドロビン割り当てを使用する場合、オムニチャネルルーティングは、エージェントの空きキャパシティをある程度チェックしますが、仕事の割り当てはエージェントのキャパシティの空きではなく、チャネルの最後の割り当てからの経過時間に基づいて行われます。
オムニチャネルルーティングには、デフォルトのキャパシティルールが用意されており、そのまま使用することも、編集することもできます。また、管理者はニーズに合わせて独自のキャパシティルールを作成することもできます。エージェントは常に、最初にデフォルトとして設定したキャパシティルールに割り当てられますが、必要に応じて割り当てを変更することができます。エージェントは1つのキャパシティルールにしか割り当てられないため、エージェントを新しいルールに割り当てると、自動的に現在のルールから割り当てが解除されます。
キャパシティルールを追加する
オムニチャネルルーティングには、すぐに作業を開始できるよう、デフォルトのキャパシティルールが用意されていますが、必要に応じて後からルールを追加することもできます。キャパシティルールを作成および管理するには、管理者である必要があります。
キャパシティルールを追加するには
-
管理センターで、サイドバーの「
オブジェクトとルール」をクリックし、「オムニチャネルルーティング」>「キャパシティルール」を選択します。
- 「キャパシティルール」ページで、「キャパシティルールを追加」をクリックします。
- 「キャパシティルールを追加」ページで、次の情報を入力します。
- 名前:キャパシティルールのわかりやすい名前を入力します。
- 説明:必要に応じて、キャパシティルールを識別するのに役立つ説明を入力します。
-
デフォルトに設定:新しいチームメンバーは、自動的にデフォルトのキャパシティルールに割り当てられます。すでにキャパシティルールに割り当てられているチームメンバーは変更されません。メモ:新しいキャパシティルールを作成してチームメンバーを割り当てた場合、そのメンバーはデフォルトのキャパシティルールから削除されます。キャパシティルールを削除すると、そのルールに割り当てられたすべてのチームメンバーがデフォルトのキャパシティルールに戻って割り当てられます。
- 担当者:「担当者を追加」をクリックして、このルールを適用するエージェントを指定します。
- 「キャパシティ」>「メール」:一度にエージェントに割り当てることができるオープンメールチケット(Webフォーム、サイドカンバセーション、APIを含む)の数を指定します。これは、エージェントへの割り当て方法に関係なく、すべてのオープンなメールチケットが対象にされます。保留中や待機中のチケットは、キャパシティの消費にカウントされません。(最大500)
-
「キャパシティ」>「メッセージング」:一度にエージェントに割り当てることができるメッセージングチケットの数を入力します。非アクティブなメッセージングチケットは、「メッセージングアクティビティルーティング」が選択されている場合にカウントされます。選択されていない場合、アクティブなメッセージングチケットのみが考慮されます。このキャパシティは、状況によってはチャットにも適用されます。オンラインチャットに適用される場合、エージェントは同時に、この数のオンラインチャットとこの数のメッセージング会話を割り当てることができます。(最大500)
詳しくは「メッセージングの会話とオンラインチャットでのキャパシティルールのしくみについて」を参照してください。
- 「キャパシティ」>「Talk」:一度にエージェントに割り当てることのできるコールチケットの数を入力します。選択肢は0か1です。0を選択すると、エージェントはコールを受け取れません。後処理の時間(設定されている場合)が終了した後、またはエージェントが電話を切った後のコールは、エージェントのキャパシティにカウントされなくなります。
- 設定を完了したら、「キャパシティルールを追加」をクリックします。
新しいキャパシティルールが「キャパシティルール」ページに表示され、すぐに動作を開始します。
メッセージングの会話とオンラインチャットでのキャパシティルールのしくみについて
- メッセージングキャパシティに指定した値は、メッセージング会話とオンラインチャットの両方に個別に適用されます。メッセージングキャパシティに3を指定した場合、エージェントは同時に最大3つのメッセージング会話チケットと3つのオンラインチャットを割り当てられます。
- 会話では、アクティブなチケットと非アクティブなチケットという概念があります。Zendeskでは、エンドユーザーが直近10分間に返信を送信していない場合、メッセージング会話を非アクティブと定義しています。ただし、管理者は「キャパシティの解放」設定を使用してこの値を変更し、非アクティブなメッセージングチケットのステータスを変更することができます。
- オムニチャネルルーティング設定には「メッセージングアクティビティルーティング」の設定があります。
メッセージングアクティビティルーティングはデフォルトではオフになっています。オフになっている場合、オムニチャネルルーティングは、アクティブなメッセージングチケットのみをエージェントのキャパシティにカウントします。つまり、エージェントには、アクティブな会話用に指定されたキャパシティに加えて、非アクティブなメッセージング会話とオンラインチャットをいくつでも割り当てることができます。「キャパシティの解放」の設定をカスタマイズすることで、このシナリオにおけるエージェントのキャパシティを微調整することができます。非アクティブな会話が再度アクティブになったときに、エージェントは指定されたキャパシティを超える可能性があります。オムニチャネルルーティングは、エージェントのキャパシティに再び余裕ができるまで、そのチャネルの新しいチケットを割り当てることはしません。
メッセージングアクティビティルーティングがオンの場合、オムニチャネルルーティングは、すべてのオープンなアクティブおよび非アクティブのメッセージングチケットをエージェントのキャパシティにカウントします。オムニチャネルルーティングは、割り当てられたメッセージングおよびオンラインチャットチケットの合計数が、それぞれ指定されたキャパシティを下回った場合にのみ、新しい会話チケットをエージェントに割り当てます。
56件のコメント
Barry Neary
cc: 1263082297649
0
Jesus Gonzalez
Hi everyone!
I have a question regarding Messaging. Does anyone know if it's possible to enable the Accept button when a messaging chat transitions from an Inactive session state back to Active?
Currently, we have a trigger that unassigns the messaging ticket and reassigns it to a group. However, when the session becomes Active again, we'd like to notify messaging agents—preferably via the Accept button, Conversation button, or an alert—so that any available agent can accept and continue the chat.
Has anyone found a way to accomplish this? Appreciate any insights! TIA.
0
Jimmy Rufo
Hi 1263082080589 , thanks for the update today. If you or 1263082108669 could refer to me to the post discussing the feature to “stagger” OCR related ticket assignments over time, that would be great!
0
Gabriela Manarim
We need more roles to have permissions to edit settings. This is a feature for team leaders, and not everyone needs to be an administrator.
1
Jimmy Rufo
Hi 1263082080589 ,
My recent concern was specific to agent status toggling, of which there is no documentation regarding if they will default to “Online”, “Offline”, if a default can be set for agents in a particular capacity rule, etc. I know we are meeting on Monday, so may be best to clear this all up early next week. Thanks.
0
Barry Neary
Hi 1263169422950
Sorry for the confusion: the agents with zero capacity can still be assigned support tickets manually either self assiginging from views or being manually assigned tickets from supervisors. Its the routing engine that will not assign them tickets
0
Jimmy Rufo
Hi 1263082080589 ,
I think there is a misunderstanding here. The ~200 agents not using OCR will still NEED to be assigned tickets, just not in an OCR capacity, if that makes sense. The tickets would get assigned manually to them or via transfer of ticket to their ticket group. In that respect, I'd want them to not have to worry about agent status and receive tickets manually as they always had. I have only 8 agents or so that I want to test OCR with, and dealing with the other 200 agents is proving problematic. I'd love to speak with someone close to this feature to find a way to get this implemented, as I've had so many stops and starts.
0
Barry Neary
HI 1263169422950
Those agents with zero max capacity will not be assigned tickets, independent of what their agent status is set to. So those agents can just ignore their agent status
Barry
0
Jimmy Rufo
Hi 1263082080589 , for the rule with the 300+ agents with 0 capacity, would those agents have to adjust to having to set an agent status when navigating to the agent interface? Since they are not going to be active for OCR at this time, I would want to ensure they don't have to adhere to a workflow that is irrelevant to them, and could prevent them from receiving tickets.
0
Tina
Hi 1263082080589, regarding your comment reply to D. Fitz on Nov 5. Are there any plans in the future to implement some improvements to cater for this scenario? It would be nice to have some configuration on these tickets that were already replied to that were there before agent signed in (to automatically move to On-Hold so they can receive the more time pressing tickets) or another method.
Currently we are experiencing a similar problem and we've set up some automations to unassign tickets after being held for some time and changing priorities when the SLA is about to breached, though it is more of a workaround for now. Increasing the capacity isn't really the best solution since:
- If people sign on too early, they get all the nearly SLA breached tickets. Even though who sign on a few minutes afterwards may not get some of that workload and they would need to wait for a team leader to sign on to reassign tickets manually.
- Or people who sign on a little later may not receive any tickets since everyone has higher capacity. They need a team leader to reassign tickets to them manually.
Thanks.
1
サインインしてコメントを残してください。