この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
レポートのデータについて理解するには、レポーティング操作についてよく理解する必要があります。レポーティング操作では、タスク データの格納方法と格納時期、レポートでのマルチチャネル情報の表示方法、エージェント状態のレポート方法、およびフェイルオーバーがレポートに与える影響について説明します。
エージェントには、所属する Media Routing Domain(MRD; メディア ルーティング ドメイン)ごとに、 ルーティング可能 と ルーティング不可能 のいずれかのモードを設定できます。
|
|
---|---|
次の条件をすべて満たすエージェントは応答可能なエージェントであり、このメディア ルーティング ドメインでタスクを割り当てることができます。
• エージェントは、メディア ルーティング ドメインに対して Not Ready 状態ではない。
• エージェントは、別のメディア ルーティング ドメインの割り込み不可能タスクを処理していない。
• エージェントは、このメディア ルーティング ドメインに対してタスク数が上限に達していない。
• 応答可能かつルーティング可能なエージェントは、 ICM 応答可能 。
• 応答可能だがルーティング不可能なエージェントは、 アプリケーション応答可能 。
次のコールおよびタスクのシナリオで、エージェント モードおよび応答可能状況について確認します。
シナリオ 1:ルーティング不可能(マルチセッション チャット、音声)
|
|
---|---|
• 2 つの MRD(マルチセッション チャットおよび音声)にログインしている。 |
エージェントはマルチセッション チャット MRD で割り込み不可能タスクを処理しているため、ICM では、このエージェントに音声 MRD のタスクが割り当てられません。 |
シナリオ 3:ルーティング不可能(音声、シングルセッション チャット)
|
|
---|---|
• 2 つの MRD(シングルセッション チャットおよび音声)にログインしている。 |
|
|
---|---|
• マルチセッション チャット MRD にログインしている(マルチセッション チャット MRD におけるエージェントの上限タスク数は 6)。 |
シナリオ 5:ルーティング可能(割り込み不可能タスク処理中)
|
|
---|---|
エージェントは電子メール MRD で割り込み可能タスクを処理しているため、ICM では、このエージェントに音声コールが割り当られます。 |
ICM データベースには、エージェント アクティビティに関する情報、および ICM ソフトウェアでルーティングされたタスク(コラボレーション サーバまたは E-Mail Manager から ICM ソフトウェアに送信されたタスクなど)に関する情報が格納されています。レポートにはメディア フィールドが含まれています。このメディア フィールドを使用して、レポートに含まれる各タスクのメディア ルーティング ドメインを識別します。
ICM ソフトウェア WebView レポートには、Web コラボレーションまたは E-Mail Manager のオプション固有のイベント(Web コラボレーションまたは E-Mail Manager のタスクの実行時に発生)に関する詳細は表示されません。たとえば、このレポートには、チャット メッセージの送信テキストやエージェントが受信した電子メール数は表示されません。セッションに関するアプリケーション固有の詳細を表示する場合は、マルチメディア アプリケーションの独自のレポーティング機能を使用します。
|
|
---|---|
この項では、レポートにおける音声以外のタスクと音声タスクの主な相違点について説明します。
• タスクの方向
• ショート コール
• 複数のタスク
• サービス レベル
音声以外のタスクの方向は常に受信ですが、音声タスクの方向には受信と送信の両方があります。音声以外のタスクの送信に関連するレポート フィールドの値は、NULL に設定されます。
音声以外のタスクは、あるエージェントから別のエージェントに転送することはできません。また、音声以外のタスクには、スーパーバイザ アシスタンス、割り込み、または会議を割り当てることができません。音声以外のタスクの転送、スーパーバイザ アシスタンス、割り込み、または会議に関連するレポート フィールドの値は、NULL に設定されます。
ショート タスクに対して定義された時間枠内に切断されたコールは、レポートではショート コールと見なされます。ただし、音声以外のタスクは、ショート タスクの時間枠内に切断された場合でも、ショート タスクとしてレポートされません。音声以外のショート タスクに関するレポート フィールドの値は、ゼロに設定されます。
エージェントは 1 度に 1 つの音声タスクだけを処理できますが、チャットなどの音声以外の複数のタスクを同時に処理するよう設定できます。エージェントが音声以外の複数のタスクを処理する場合、レポートには各タスクのデータが表示されます。これらのタスクのスキル グループが異なる場合があります。たとえば、Cisco E-Mail は割り込み可能 MRD であるため、エージェントは、電子メール タスクを処理すると同時に他のメディアのタスクまたはコールを処理できます。レポートでは、タスクの期間フィールドが影響を受けます。たとえば、音声以外のタスクの 30 分の期間フィールドの値が 30 分を超える場合があります。
音声タスクの場合は、使用するサービス レベル タイプを選択できます。音声以外のタスクのサービス レベル タイプは、常に「放棄コールを無視」になります。このサービス レベル設定は、音声以外のタスクのレポートのサービス レベル データに影響を与えます。
この項では、コールおよびタスクがレポーティング エンティティを通過する方法について説明します。内容は、次のとおりです。
• E-Mail Manager のタスク フローの基本シナリオ
各タスク フローでは、1 つのタスクが複数の レポーティング エンティティ を通過します。レポーティング エンティティは ICM ソフトウェアで設定します。また、レポーティング エンティティは、タスクに関する特定の情報を表しています。次の表では、IPCC レポーティング エンティティについて説明します。
(注) ブレンディッド エージェント コール(アウトバウンド キャンペーン音声コール)はコール タイプ レポーティング エンティティを通過しないため、ブレンディッド エージェント コールのコール タイプ データは収集されません。
次の表に、さまざまなコールが通過するレポーティング エンティティを示します。
|
|
||||
---|---|---|---|---|---|
タイプ |
|
|
グループ |
|
|
システムは、ICM ソフトウェアを使用して音声以外のタスクをルーティングするコラボレーション サーバか E-Mail Manager、またはその両方を使用して設定されている場合があります。音声以外のタスクの場合、タスクは IVR ではなく ICM ルータにキューイングされます。
簡単なシナリオでは、音声コールは、CallManager の CTI ルート ポイントに進入した後、初期コール タイプに送信されるか、または Queue to Agent スクリプト ノードを経由してエージェントにキューイングされます。応答可能なエージェントが見つからない場合、音声コールは、
TranslationRtetoVRUNode を経由して IVR サービスに送信されます。この時点では、コール タイプおよび IVR サービスだけが影響を受けます。IVR に送信されたコールは、Queue to Skill Group ノードを経由してスキル グループにキューイングされます。この時点では、スキル グループもこのコールの影響を受けます。エージェントが応答可能になると、ペリフェラル エージェント サービスに関連付けられたルート、ペリフェラル エージェント サービス、およびエージェントがこのコールの影響を受けます。
エージェントが応答可能なときに受信したコールは、IVR に送信する必要はありません。IVR サービスは、ルーティング スクリプトで LAA セレクト ノードを経由してエージェントに直接ルーティングされるため、コールの影響を受けません。このタスクでは、サービス、スキル グループ、およびエージェントがこのコールの影響を受けます。
コールに応対したエージェントは、このコールを別のエージェントまたはスキル グループに転送したり、会議コールを実行します。コールが転送されると、このコールは別の転送コール タイプまたは会議コール タイプに送信されるため、別のコール タイプ エンティティを通過することになります。使用されるレポーティング エンティティは、コール タイプ、サービス、スキル グループ、およびエージェントです。
エージェントが特定のエージェントにコールを転送する場合は、転送スクリプトまたは会議スクリプトでは Agent to Agent ノードが使用されます。これらのスクリプトはスキル グループおよびエージェントだけを通過し、サービスは通過しません。Agent to Agent ノードおよび Queue to Agent ノードの場合は、このスキル グループがデフォルトのスキル グループとなります。使用されるレポーティング エンティティは、 スキル グループ および エージェント です。
エージェントが個別の転送スクリプトまたは会議スクリプトを使用せず、エージェントの内線番号を直接ダイヤルした場合、転送コールまたは会議コールは、宛先エージェントのデフォルトのスキル グループに属します。このシナリオは推奨シナリオではありません。
ICM スクリプト外からエージェントへの直接コールは、デフォルトのスキル グループに属します。使用されるレポーティング エンティティは、デフォルトのスキル グループおよびエージェント(Queue to Agent ノードを経由してルーティングされるコール)です。
エージェントの電話またはデスクトップで応答がないため再ルーティングされたコールは、別のコール タイプに進入します。このコール タイプでは、タスクが高優先順位で同じスキル グループにキューイングされます。使用されるレポーティング エンティティは、コール タイプ、サービス、スキル グループ、およびエージェントです。
情報収集データとキューイング データを区別するには、コール タイプ ノードまたは Requalify ノード を使用します。これにより、あるコール タイプから別のコール タイプにコールが移動します。移動元のコール タイプの Overflowout、および移動先のコール タイプの CallsOffered がそれぞれ増加します。
リクエスト タスクを受信したコラボレーション サーバでは、MR PG を経由して、ルーティング リクエストが ICM ソフトウェアに送信されます。ICM ソフトウェアでは、タスクのコール タイプが決定されます。また、ルーティング スクリプトを実行して、タスクを処理するスキル グループおよびエージェントが決定されます。エージェントが応答可能な場合、ICM ソフトウェアでは、スキル グループ割り当てがコラボレーション サーバに返されます。コラボレーション サーバでは、このスキル グループおよびエージェントがこのコラボレーション サーバに存在するのか、または別のコラボレーション サーバに存在するのかが判別されます。このスキル グループおよびエージェントが別のコラボレーション サーバに存在する場合は、該当するコラボレーション サーバにタスクが転送されます。このコラボレーション サーバでは、エージェントのデスクトップにタスクがプッシュされます。コラボレーション セッションだけでなく音声コールも伴うタスクの場合、メディア ブレンダでは、選択したエージェントと顧客の間で音声コールが自動的に開始されます。
エージェントが応答可能ではない場合、タスクは、エージェントが応答可能になるまで ICM ルータにキューイングされます。その後、ICM ソフトウェアでは、スキル グループおよびエージェントの割り当てがコラボレーション サーバに送信されます。
使用されるレポーティング エンティティは、コール タイプ、スキル グループ サービス、スキル グループおよびエージェント(IVR サービスではない)です。
Web コラボレーション タスクのルーティングの詳細は、『Cisco Collaboration Server アドミニストレーション・ガイド』を参照してください。
E-Mail Manager で電子メール タスクが受信されると、ルール エンジンでは、ICM ソフトウェアでこのタスクがルーティングされる必要があるかどうかが決定されます。ICM ソフトウェアでタスクをルーティングする必要があると決定された場合、E-Mail Manager では、MR PG を経由してルーティング リクエストが ICM に送信されます。ICM ソフトウェアでは、タスクのコール タイプが決定されます。また、ルーティング スクリプトを実行して、タスクを処理するスキル グループおよびエージェントが決定されます。エージェントが応答可能な場合、ICM ソフトウェアでは、スキル グループおよびエージェント割り当てが E-Mail Manager に返されます。E-Mail Manager では、電子メールがエージェントのデスクトップにプッシュされます。
エージェントが応答可能ではない場合、タスクは、エージェントが応答可能になるまで ICM ルータにキューイングされます。その後、ICM ソフトウェアでは、スキル グループおよびエージェントの割り当てが E-Mail Manager に送信されます。
コラボレーション サーバおよび E-Mail Manager に関する追加情報は、次の参照先を参照してください。
|
|
---|---|
(注) マルチチャネル ソフトウェアのマニュアルは、各製品のインストール CD に含まれています。また、マルチチャネルのマニュアルは、インストール済みのマルチチャネル製品からも参照できます。
エージェントは、さまざまな種類のタスクを受け入れたり実行できます。ICM ソフトウェアでは、これらのタスクが個別にレポートされます。この項では、次の項目について説明します。
内部コールとは、同じ CallManager クラスタ内のエージェントに対して行われるコール、話中またはオーバーフローの影響を受けるコールのことです。音声ゲートウェイを通過するコール、または別の CallManager クラスタ上のエージェントに送信され、この宛先デバイスを呼び出すコールは、外部コールと見なされます。
音声ゲートウェイでリモート サイトと接続されている中央コール処理サイトでは、リモート サイトのエージェントに対して行ったコールは外部タスクと見なされます。
ICM システムは、ブレンディッド エージェント アプリケーションを使用して設定できます。ブレンディッド エージェント コールは外部コールです。
次の表で説明されているように、エージェントは 4 つのタイプのタスクを受け入れたり実行できます。
• エージェントの状態時間およびコールまたはタスクの状態時間
エージェントの状態は、スキル グループ内でのエージェントのアクティビティに基づいて決定されます。次の表に、エージェントの状態が Agent_Real_Time データベース テーブルおよび
Skill_Group_Real_Time データベース テーブルに記録される方法、および WebView レポートにおけるエージェントの状態の表示形式を示します。
Interrupted 状態は現在使用されていないため、InterruptedTime は収集されません。
(注) 特定のレポートでは、特定の状態のエージェント(Ready 状態など)の数を示す場合にカラムが使用されます。これらのレポートでは、[Hold]カラムには Hold 状態および Paused 状態のエージェントが表示され、[Active]カラムには Active 状態および Talking 状態のエージェントが表示されます。
次の表では、レポートに表示されるエージェントの状態について説明します。マルチセッション チャット MRD では、一部の状態の情報が異なります。この表では、この相違点についても説明します。
エージェントは、同じメディア ルーティング ドメインの複数のスキル グループに所属できます。スキル グループにルーティングされたタスクを処理するエージェントは、このスキル グループ内で Active になります。
• ICM でルーティングされるコール、または ICM でルーティングされて転送されるコール(ダイヤル番号計画を使用)の場合は、タスクがキューイングされたスキル グループがアクティブなスキル グループになる。
• 直接受信コール、または ICM でルーティングされて転送されるコールの場合は、デフォルトのスキル グループかエージェントに対して最初に定義されたスキル グループがアクティブなスキル グループになる。
• 新規のアウトバウンド コール(AgentOutCall か InternalCall)、または転送されたアウトバウンド コールの場合は、デフォルトのスキル グループかエージェントに対して最初に定義されたスキル グループがアクティブなスキル グループになる。
アクティブなスキル グループのエージェントの状態に応じて、このエージェントが属するメディア ルーティング ドメイン内の別のスキル グループ内のエージェントの状態が決定されます。
タスクでのエージェントの状態に応じて、スキル グループのエージェントの状態が決定されます。スキル グループのエージェントの状態に応じて、メディア ルーティング ドメインのエージェントの状態が決定されます。ただし、マルチセッション チャット タスクを処理しているエージェントは、1 つのスキル グループ内の複数のタスクを処理できます。複数のスキル グループは、1 つのメディア ルーティング ドメインに所属できます。このため、状態階層を使用して、スキル グループおよびメディア ルーティング ドメインにおけるエージェントの状態のレポート方法を決定します。
5. Busy Other(同じメディア ルーティング ドメイン内の複数のスキル グループ)
次の図を参照してください(マルチセッション チャット MRD にだけ適用)。
この図では、エージェントは 2 つのスキル グループに属しており、各 MRD で最大 6 つのマルチセッション チャットを同時に処理できます。1 つのスキル グループでは、エージェントは 3 つのタスクを処理しており、各タスクに対するエージェントの状態は、それぞれ Work Ready、Reserved、Paused です。Work Ready は他の 2 つの状態よりも高い階層にあるため、スキル グループ レベルでレポートされるエージェントの状態は Work Ready になります。もう一方のスキル グループでは、エージェントは 2 つのタスクを処理しており、各タスクに対するエージェントの状態は、それぞれ Active、Reserved です。Active は他の 2 つの状態よりも高い階層にあるため、スキル グループ レベルでレポートされるエージェントの状態は Active になります。マルチセッション チャット MRD の場合、Active は Work Ready よりも高い階層にあるため、エージェントの状態は Active になります。
エージェントの状態時間は、コールまたはタスクが終了したかどうかに関係なく、30 分区切りでレポートされます。コールおよびタスクの状態時間は、タスクが終了した場合にだけレポートされます。コールおよびタスクは、まとめが完了した後に終了します。次の図に、音声コールに対するエージェントの状態とコールの状態の相関関係を示します。エージェントの保留時間とは、コールがエージェントの電話またはデスクトップに到達するまでの時間(ネットワーク時間)、およびコールがエージェントの電話を呼び出している時間またはコールがエージェントのデスクトップで待機している時間(提供時間か呼び出し時間)の合算値です。
(注) コールがエージェントの電話の呼び出しを継続しているときに 30 分の区切りが終了した場合、エージェントの保留時間は、ネットワーク時間と呼び出し時間の一部の合計となります。次の 30 分の区切りでは、残りの呼び出し時間がエージェントの保留時間としてレポートされます。ただし、コールのまとめが完了するまで、コールの時間はレポートに表示されません。
ICM システムにブレンディッド エージェント アプリケーションが含まれている場合は、エージェントがブレンディッド エージェントのタスクを処理できるよう設定できます。ブレンディッド エージェントのタスクとは、エージェントと顧客の間で自動的に設定されるアウトバウンド電話コールのことです。このため、ブレンディッド エージェントのタスクの方向は、常に「外」になります。
すべてのタイプのコールおよびタスク(TransferOut を除く)には、Agent Skill Group Half Hour Table 内のコールおよびタスクに関連付けられた時間が含まれています(Transfer Out では、
[InternalCallsTimetoHalf]フィールドが使用されます)。
(注) 次の表で、音声タスクとマルチチャネル タスクの両方に適用されるタスクは CallsHandled だけです。他のすべてのタスクは、音声コールにだけ適用されます。レポートでは、音声だけのデータベース フィールドの値は NULL になります。
|
|
|
|
---|---|---|---|
ターゲット エージェントが応答して保留タスクが復元された後(コンサルタティブ コールの切断)か、または |
|||
受信タスク(CallsHandled および InternalCallsRcvd)は Transferred In コールまたは ConferencedIn コールになることがあるため、時間が重複する場合があります。すべての受信タスクおよび送信タスク(AgentOutCall および InternalCall)は、TransferredOut または Conferenced Out になります。
デフォルトのスキル グループは、ICM ルーティング スクリプトによってルーティングされなかった音声コールに関する情報を収集するための受け皿となります。
音声以外のタスクの場合は、Queue to Agent ノードを使用してエージェントにタスクをキューイングするときに、デフォルトのスキル グループが使用されます。ルーティング スクリプトにスキル グループを指定しない場合は、デフォルトのスキル グループが使用されます。デフォルトのスキル グループを使用すると、次のような利点があります。
• エージェント/スキル グループ レポートが、サービス レポートやコール タイプ レポートとのバランスを保つ場合に役立つ(サービス レポートやコール タイプ レポートには、ICM でルーティングされたコールだけが含まれるため)。
• エージェント レポートおよびスキル グループ レポート内で、ICM でルーティングされなかったコールを特定および識別する場合に役立つ。
デフォルトのスキル グループを作成する必要はありません。MRD とペリフェラル ゲートウェイのペアを確立すると、自動的に作成されます。
新規のすべてのアウトバウンド直接コールおよび受信直接コールのコール統計は、次のデフォルトのスキル グループに対して増加します。
• AgentOutCalls(外部アウトバウンド コール)
• InternalCalls(内部アウトバウンド コール)
(注) デフォルトのスキル グループはいずれのスクリプトからも参照されないため、CallsHandled はデフォルトのスキル グループに対して増加しません。
スクリプトでエージェント ノードを使用するエージェント間のダイヤルは、デフォルトのスキル グループに影響を与えます。エージェント間のコールを開始したエージェントのデフォルトのスキル グループに対して、OutgoingExternal または OutgoingInternal が増加します。エージェント間のコールを受信するエージェントのデフォルトのスキル グループに対して、InternalCallsReceived が増加します。
デフォルトのスキル グループは、転送コールおよび会議コールの影響も受けます。エージェント A が、スクリプトを使用せずに、ICM でルーティングされるコールを別のエージェントに直接転送するか、またはこのコールの会議を実行すると、エージェント A の OutgoingExternal または OutgoingInternal は、ICM でルーティングされるコールのスキル グループに対して増加します。エージェント B の IncomingDirect コールは、デフォルトのスキル グループに対して増加します。
ただし、エージェント A が、ICM でルーティングされるコールをダイヤル番号計画(Agent to Agent ノードを持つ転送スクリプトまたは会議スクリプトにアクセスする)に転送するか、またはこのコールの会議を実行すると、エージェント A の OutgoingExternal または OutgoingInternal は、ICM でルーティングされるコールのスキル グループに対して増加します。エージェント B の IncomingDirect コールは、デフォルトのスキル グループに対して増加します。
また、既存のコールが存在しない場合、デフォルトのスキル グループは、緊急アシスタンス コールやスーパーバイザ アシスタンス コールに対しても増加します。
ICM ルーティング スクリプトによってデフォルトのスキル グループが参照されないようにしてください。これにより、デフォルトのスキル グループでは、ICM でルーティングされるコールの統計が捕捉されなくなります。
コール タイプ レポートでは、エージェントが応答したコール、IVR で放棄されたコール、エージェントへのルーティング中に放棄されたコール、エージェントの電話への提供中に放棄されたコール、Busy 状態のコール、Ring 状態のコール、デフォルトでルーティングされるコール、ネットワークでルーティング処理されたコール、コール タイプ ノードまたは Requalify ノードを経由して別のコール タイプに送信されるコール、およびショート コールの数を均衡させる必要があります。
提供コール=放棄コール+処理コール+Busy 状態のコール+オーバーフローして出ていったコール+デフォルトで処理されたコール+ネットワークでルーティングされたコール+ショート コール。
ただし、コール タイプで提供コールが増加するが、この増加に対応するデータベース フィールドが存在せず、レポートの均衡を確保できない場合があります。この場合に該当するコールは、次のとおりです。
• エージェントの電話から応答がないため再ルーティングされるコール
• ラベル ノードを経由して、スクリプトを監視対象外のデバイスで終端させるコール(音声メールなど)
この項では、コール タイプ レポートの均衡確保が妨害されるシナリオについて説明します。また、この項では、コール タイプ レポートの均衡を確保するための推奨事項についても説明します。
ルーティング中に放棄されるコールとは、IVR への送信過程でネットワーク内に放棄されるコールのことです。たとえば、CallManager の CTI ルート ポイントから IVR に送信される過程で放棄されるコールが該当します。コール タイプでは、このコールも CallErrors の一部としてカウントされます。このフィールドは、すべてのフィールドでレポートされるコール タイプに含まれています。CallErrors には、デフォルトでルーティングされたコール、および次にリストされている他のコール シナリオが含まれています。構内 IVR を使用している場合、このコールが発生する可能性はほとんどありません。
このコールには不良ラベルが定義されており、デフォルト ラベルは定義されていません。デフォルト ラベルを定義することを推奨します。これにより、ラベルの設定が誤っているコールはデフォルト ラベルに送信されて処理が行われ、コール タイプ レポートの計算に含まれます。ルータのイベント ビューアを使用すると、不良ラベル条件に該当するコールを確認できます。このコールは、コールタイプ テーブルの[Call Errors]フィールドにカウントされます。このフィールドは、すべてのフィールドでレポートされるコール タイプに含まれています。
Reroute on No Answer コールとは、エージェント デスクトップの設定に定義された Ring No Answer タイマーの値を呼び出し時間が超過したため、エージェントの電話からリダイレクトされるコールのことです。このコールの数は、エージェントとスキル グループのレポートに表示されます。
複数のコール タイプによって同じスキル グループにコールがキューイングされている場合は、コール タイプごとに Reroute on No Answer スクリプトを分割する必要があります。これにより、このスキル グループ レポートの[RedirectNoAnswer]フィールドを使用して、コール タイプ レポートの均衡を確保できます。
ラベル ノードは、音声メニュー使用時や他の条件に基づいて顧客が収集した番号が原因で ICM によって監視されない音声メール、Web アテンダント、または他のデバイスにコールを転送する場合に使用します。IVR サービスでは、[CallsHandled]フィールドにこのコールが含まれています。
システムのフェイルオーバーは、レポーティングに影響を与えます。この項では、システム コンポーネントに次のフェイルオーバーが発生した場合のレポーティングへの影響について説明します。
• ペリフェラル ゲートウェイおよび CTI Manager サービス
• アプリケーション インスタンス、エージェントの PG CTI サーバ、および PIM
エージェントの PG(PIM または JTAPI GW コンポーネント)や CallManager の CTI Manager サービスがダウンすると、エージェントは一時的にログアウトしますが、バックアップ PG または CTI Manager が起動されると、自動的にログイン状態に戻ります。ログアウト履歴レポートには、50002 のログアウト理由コードが表示されます。エージェントが Available 状態または Not Ready 状態であった場合、このエージェントは、再度ログインするときに元の状態に戻ります。エージェントが以前に Wrap-up 状態であった場合、このエージェントは Available 状態に戻ります(コールの前に Available 状態であった場合)。これ以外の場合、このエージェントは Not Ready 状態に戻ります。
エージェント デスクトップがダウンしたり CTI-OS サーバとの通信が失われたか、または CTI-OS サーバがダウンした場合、エージェントは、通信が失われたペリフェラルでサポートされているすべてのメディア ルーティング ドメインからログアウトします。ただし、エージェント デスクトップが復元されたり CTI-OS サーバとの通信が回復されるか、またはエージェントがバックアップ CTIOS サーバに戻された場合、エージェントは自動的にログイン状態に戻ります。ログアウト履歴レポートには、50002 のログアウト理由コードが表示されます。エージェントが Available 状態または Not Ready 状態であった場合、このエージェントは、再度ログインするときに元の状態に戻ります。ただし、エージェントが Reserved 状態であった場合、このエージェントは Available 状態に戻ります。エージェントが以前に Wrap-up 状態であった場合、このエージェントは Available 状態に戻ります(コールの前に Available 状態であった場合)。これ以外の場合、このエージェントは Not Ready 状態に戻ります。このことは、CTI-OS デスクトップに適用されます。
デスクトップで CTI ツール キット アプリケーションを使用している場合も、エージェントは自動的にログインして適切な状態に戻ります。
エージェントの電話に直接接続されていない CallManager がダウンしても、エージェントへの影響はありません。
ただし、(CallManager がダウンしたりエージェントの電話が再起動されたため)エージェントの電話で CallManager との接続が失われるか、またはエージェントの電話と CallManager の間でネットワーク上の問題が発生した場合、このエージェントは自動的にログアウトされます。このエージェントは、電話をバックアップ CallManager 向けに設定した後、手動で再度ログインする必要があります。
ログアウトしたエージェントは、再度ログインまでリアルタイム ステータスから削除された状態になります。履歴情報は、エージェントが再度ログインした時点から再開されます。ログアウト履歴レポートには、50003 の理由コードによりエージェントがログアウトしたことが表示されます。フェイルオーバー以前のエージェントの状態やリカバリ状態は維持されません。
フェイルオーバーやリカバリ状態が発生したときにエージェントがコールに応対している場合は、このコールが切断されない限り、エージェントがフェイルオーバーしたり、バックアップ CallManager やプライマリ CallManager に戻ることはありません。エージェントがフェイルオーバーしたりバックアップ CallManager やプライマリ CallManager に戻るまで、PG へのシグナリングが停止している状態が継続するため、エージェントはこのコールへの応対を継続できますが、記録は履歴レポートに残りません。エージェントは、バックアップ CallManager に戻った後、再度ログインする必要があります。フェイルオーバー以前のエージェントの状態やリカバリ状態は維持されません。
アプリケーション インスタンスと MR PG の間の接続がダウンするか、または MR PIM かアプリケーション インスタンスがダウンすると、ICM セントラル コントローラでは、アプリケーションから受信した保留中のすべての NEW_TASK リクエストが削除されます。アプリケーション インスタンスは接続が復元されるのを待機し、アプリケーション インスタンスによってエージェントの PG CTI サーバに割り当てられた既存のタスクと新規のタスクに関するメッセージの送信を継続します。接続、MR PIM、またはアプリケーション インスタンスが復元されると、アプリケーション インスタンスでは、ICM セントラル コントローラからの返信を受信していない保留中のすべての NEW_TASK リクエストが再送信されます。接続がダウンしているときにアプリケーション インスタンスによってエージェントに割り当てられたタスクのうち、接続が復元される前に完了したタスクは、WebView レポートに表示されません。
(注) アプリケーション インスタンスがダウンすると、エージェントの PG CTI サーバの接続にも影響を与えます。
MR PIM と ICM セントラル コントローラの間の接続がダウンするか、または ICM セントラル コントローラがダウンすると、MR PIM からアプリケーション インスタンスに ROUTING_DISABLED メッセージが送信され、これにより、アプリケーション インスタンスから ICM セントラル コントローラへのルーティング リクエストの送信が停止します。接続がダウンしているときに送信されたリクエストはすべて拒否され、NEW_TASK_FAILURE メッセージが表示されます。アプリケーション インスタンスは、アプリケーション インスタンスによってエージェントの PG CTI サーバに割り当てられた既存のタスクと新規のタスクに関するメッセージの送信を継続します。接続または ICM セントラル コントローラが復元されると、MR PIM からアプリケーション インスタンスに ROUTING_ENABLED メッセージが送信され、これにより、アプリケーション インスタンスから ICM セントラル コントローラへのルーティング リクエストの送信が再開されます。接続がダウンしているときにアプリケーション インスタンスによってエージェントに割り当てられたタスクのうち、接続が復元される前に完了したタスクは、WebView レポートに表示されません。
ICM セントラル コントローラと MR PG の間の接続に障害が発生すると、ICM ルータでは、保留中のすべての新規タスクが削除されます。接続が復元されると、MR PG に接続されているアプリケーションからすべてのタスクが再送信されます。
(注) ICM セントラル コントローラがダウンすると、アプリケーション インスタンスとエージェントの PG CTI サーバのインターフェイスにも影響を与えます。
アプリケーション インスタンスかエージェントの PG CTI サーバがダウンするか、またはこれらを結ぶ接続がダウンした場合でも、エージェントはログイン状態を継続します。タスクは、MRD の task life 属性に基づいて一定の時間残存します。接続がダウンしている間に task life が期限切れとなったタスクは終了し、状態コード 42(DBCD_APPLICATION_PATH_WENT_DOWN)が表示されます。
(注) 電子メール MRD の場合は、エージェントの PG CTI サーバやこのサーバとの接続がダウンしても、エージェントは自動的にログアウトされません。代わりに E-Mail Manager でエージェントの状態が記録され、エージェントにタスクが割り当てられます。接続が復元されると、E-Mail Manager では、エージェントの PG CTI サーバで管理されているペリフェラル上の最新のエージェント状態情報が CTI サーバに送信され、この CTI サーバから ICM ソフトウェアにこの情報が送信されます。ICM ソフトウェアでは、履歴データの再作成が試行され、現在のエージェントの状態が修正されます。接続またはエージェントの PG CTI サーバのダウン状態が、MRD に設定されている制限時間よりも長く続く場合は、タスクのレポーティングが ICM ソフトウェアによって早期終了し、接続の再確立と同時に再開されることがあります。
アプリケーション インスタンスでは、接続または CTI サーバがダウンしているときでも、タスクをエージェントに割り当てることができます。MR PG への接続が確立されると、アプリケーション インスタンスでは、ICM セントラル コントローラへのルーティング リクエストの送信、およびルーティング方法の受信が継続されます。ただし、接続がダウンしている間、タスクのレポーティング データは保存されません。また、接続または CTI サーバがダウンしているときに割り当てられて完了したタスクは、WebView レポートに表示されません。
エージェントの PG CTI サーバとルータの間の接続がダウンするか、またはルータがダウンした場合、アプリケーション インスタンスでは、CTI サーバへのメッセージの送信が継続され、エージェントのアクティビティがトラッキングされます。ただし、接続またはルータが復元されて、キャッシュされたレポート情報が ICM セントラル コントローラに送信されるまで、この情報はルータに送信されません。
(注) ICM セントラル コントローラがダウンすると、アプリケーション インスタンスと MR PG のインターフェイスにも影響を与えます。
CallManager PIM がダウンすると、この PIM に関連付けられたエージェントは、音声メディア ルーティングを使用できなくなります。ただし、ICM セントラル コントローラでは、PIM に関連付けられたエージェントへの音声以外のタスクの割り当てを継続できます。CTI サーバでは、音声以外のメディア ルーティング ドメインの PIM に関連付けられたエージェントに関するメッセージおよびリクエストの処理を継続できます。接続が復元されると、音声メディア ルーティングを再度使用できるようになります。