Packaged CCE アドミニストレーション ガイド リリース 9.0(x)
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月21日
章のタイトル： レポート
目次
- レポート
- レポーティング データ
- リアルタイム データの収集
- 履歴データと間隔データの収集
- 設定データ
- コールの詳細データ
- レポーティング データを保持するデータベース テーブル
- レポート データが異なる理由
- リアルタイム レポートおよび履歴レポート
- 間隔境界
- レポーティング エンティティおよび概念
- エージェント状態
- レポートでのエージェント状態の計算方法
- エージェント状態、スキル グループ、およびプレシジョン キュー
- エージェント状態とタスク状態の関係
- エージェント状態を示すレポート
- エージェントのログアウト理由コード
- エージェントのログアウト理由コードを示すレポート
- エージェントの受信不可理由コード
- エージェントの待受停止理由コードを示すレポート
- エージェントのタスク処理
- タスクのタイプ
- タスク時間
- エージェントのタスク処理を示すレポート
- エージェントの稼働率：フルタイム換算および稼働率
- 稼働率と FTE メトリックを示すレポート
- エージェント状態を示すレポート
- エージェントのログアウト理由コードを示すレポート
- エージェントに関するレポーティング
- スキル グループ（Skill Groups）
- デフォルトのスキルグループ（Default Skill Group）
- レポーティングにおけるデフォルトのスキル グループのロール
- 新規コールによるデフォルトのスキル グループ統計の増加
- エージェント間のダイヤリングによるデフォルトのスキル グループ統計の増加
- 転送コールおよび会議コールによるデフォルトのスキル グループ統計の増加
- スキル グループの操作に関するレポート
- 提供されたコールのスキル グループに対する計算方法
- スキル グループ操作を示すレポート
- エージェント チームとスーパーバイザ
- エージェント チームとスーパーバイザ
- エージェント チーム レポート
- スーパーバイザのアクション レポート
- 既存のコールに対するスーパーバイザ アシストおよび緊急支援
- 割り込み
- 代行受信
- エージェント チームに関する情報を示すレポート
- スーパーバイザに関するレポーティング
- エージェント チームに関する情報を示すレポート
- 平均応答時間
- ASA の計算方法
- エージェントおよびスキル グループの ASA
- エージェントの ASA を示すレポート
- コール タイプの serviceASA
- コール タイプの ASA を示すレポート
- 再クエリー
- コール タイプ
- コール タイプのレポート
- コール タイプ
- コール タイプに関するベスト プラクティス
- コール タイプの変更
- コール タイプ レポーティング
- 提供されたコールのコール タイプに対する計算方法
- コール タイプ レポーティングに対するコール エラーの影響
- 無効なラベルを持つコールがコール タイプ レポーティングに与える影響
- CVP で無応答が発生したコールがコール タイプ レポーティングに与える影響
- ラベル ノードで終了して監視されていないデバイスにルーティングされるコールがレポートに与える影響
- コール タイプ レポート
- コールに関するレポーティング
- バケット間隔
- バケット間隔レポート
- サービス レベル
- サービス レベルについて
- サービス レベルしきい値（Service Level Threshold）
- サービス レベル タイプ（Service Level Type）
- コール タイプのサービス レベル
- スキル グループのサービス レベル
- サービス レベルのベスト プラクティス
- サービス レベル関係：MRD、スキル グループ、およびプレシジョン キュー
- ショート コール、放棄呼、およびオーバーフロー コール
- ショート コール
- 放棄ショート コール
- 応答ショート コール
- ショート コール レポート
- 放棄呼
- 放棄呼によるレポーティングへの影響
- 放棄ショート コールによるレポーティングへの影響
- 放棄呼レポート
- 転送および会議
- 転送および会議について
- 転送および会議に関する設定とスクリプティング
- 動作レポート
- トランクおよびトランク グループ
- IVR/VRU セルフサービス
- CVP について
- CVP アプリケーション レポート
- CVP のタイプがレポート データに与える影響
- セルフサービス、情報収集、およびキューイング CVP アプリケーション
- セルフサービス アプリケーションおよび情報収集アプリケーションの進行状況の監視
- VRUProgress 変数
- VRU メトリックを示すレポート
- データ損失およびコンポーネント フェールオーバー
- レポーティングのデータ フロー
- リカバリと複製
- 考えられる遅延または不一致のポイント
- ロガーおよび HDS の障害によるデータ損失を防止する方法
- PIM 障害およびレポーティングからのデータ損失
- その他に考えられるフェールオーバーのポイント
- Peripheral Gateway/CTI Manager Service のフェールオーバー
- Agent Desktop/CTI OS サーバのフェールオーバー
- コール タイプおよびスキル グループ メトリック
- コール タイプのリアルタイム テーブル メトリック
- ネットワーク VRU およびスキル グループ メトリック
- スキル グループに関するレポーティング
- プレシジョン キューに関するレポーティング
この章では、レポーティング データの収集方法、レポートに表示されるシステム エンティティ、エンティティごとのレポートの一覧、およびデータ収集とレポートのコンテンツに影響する設定について説明します。
- レポーティング データ
- レポーティング エンティティおよび概念
- データ損失およびコンポーネント フェールオーバー
- コール タイプおよびスキル グループ メトリック
- スキル グループに関するレポーティング
- プレシジョン キューに関するレポーティング
レポーティング データ
Packaged CCE は、大量のコール データを管理します。それらは Packaged CCE Data Server 上で処理されます。 この項では、どのようにシステムでレポート データが複製され、レポートに表示されるかについて説明します。
リアルタイム データの収集
Unified CCE Peripheral Gateway とコール ルータによってリアルタイム データが生成され、データ サーバと外部の AW/HDS/DDS サーバに転送されます。 古いリアルタイム データは常に新しいリアルタイム データで上書きされます。 履歴は保存されません。 リアルタイム データはデータ フィールドに保存され、次の表のように 4 つの時間増分が反映されます。
| リアルタイム データの時間増分 |
説明 |
|---|---|
| Half |
「Half」の値には、現在の 30 分間の値が格納されます。 リアルタイムの 30 分間の値は、間隔設定の影響を受けません。 つまり、履歴レポート間隔を 15 分に設定した場合、リアルタイム テーブルの Half 値は xx:00:00 ～ xx:29:59 または xx:30:00 ～ xx:59:59 のいずれかに入る現在の 30 分間を表します。 たとえば、現在の時刻が 09:18:33 である場合、Call_Type_Real_Time テーブルの [CallsOfferedHalf] カラムには特定の 30 分間における最初の 18 分と 33 秒を反映する値が格納されます。 09:00:00 または 09:30:00 の時刻に新しい 30 分間が始まると、データベース要素はゼロにリセットされます。 |
| Now |
「Now」には、特定の瞬間（最後のチェック）におけるアクティビティのスナップショットが格納されます。 たとえば、Packaged CCE ソフトウェアでは CallsQNow がトラッキングされます。これは、サービスまたはルートのキューに現在格納されているコールの数です。 コールが応答されるとコールがキューを離れるため、CallsQNow のカウントはすぐに 1 少なくなります。 この変更は、この値をクエリーするレポートが次回リアルタイム アップデートされるときに表示されます。 |
| To5 |
「To5」の値には、直近の 5 分間にトラッキングされたデータが格納されます。 直近の 5 分間のデータには、5 分間の「スライディング」ウィンドウが使用されます。 |
Today |
各値の午前 0 時以降のカウントが格納されます。 |
履歴データと間隔データの収集
Packaged CCE は、一部の履歴データを Half_Hour テーブルに保存し、その他の履歴データを間隔テーブルに保存します。 間隔テーブルには 30 分単位のサマリーが格納されます。 間隔データは 13 ヵ月間保存されます。 レポートをさらに長期間保存したい場合は、オプションのデータベース サーバ（AW/HDS/DDS）を追加します。
履歴データ |
説明 |
||
|---|---|---|---|
間隔（30 分） |
インターバル テーブルには次のものがあります。 |
||
Half Hour |
Half_Hour テーブルには、完了した 30 分間隔のデータのみが格納され、データ フィールドは、拡張子が「ToHalf」のデータベース（Application_Gateway_Half_Hour.ErrorsToHalf など）に保存されます。 これらの要素には、完了した 30 分インターバルの値が含まれています。 完了したインターバルは、xx:00:00 ～ xx:29:59 または xx:30:00 ～ xx:59:59 の範囲の期間です。 たとえば、現在の時刻が 15:50:00 であるとします。 15:47:00 にエラーが発生しました。 現時点でレポートされる 30 分間の間隔は、15:00:00 ～ 15:29:59 の範囲内です。 15:47:00 に発生したエラーは、16:00:00 にデータベースに書き込まれます。これは 15:30:00 ～ 15:59:59 の 30 分間の間隔が完了する時刻です。 Half_Hour テーブルの例を次に示します。 |
設定データ
設定テーブルは、Configuration Manager および Web Config で定義されたエンティティおよびエンティティ名を定義します。 これらには、履歴テーブルをレポートで使用されているテキスト ラベルと関連付ける [EnterpriseName] フィールドが含まれます。
設定テーブルの例は、エージェント、エージェント チーム、スキル グループ、およびコール タイプのテーブルです。 たとえば、Web Config で新しいエージェント チームを追加すると、エージェント チーム データベース テーブルでそのチームの EnterpriseName が追加されます。
 （注） |
Web Config 内のフィールド名は、データベース内のエンタープライズ名にマップされます。 |
コールの詳細データ
Packaged CCE は、データ サーバ上のこれらの 2 つの詳細テーブルのそれぞれのレコードを 5 週間保持します。 さらに詳細レポートを保持したい場合は、オプションのデータベース サーバ（AW/HDS/DDS）を設定に追加する必要があります。 次に示すように、コールの詳細は 2 つのデータベース テーブルに保存されます。
- ルート コールの詳細 ルータは、処理するすべてのコール ルーティング要求について、コールおよびそのコールが Unified ICM によってどのように Peripheral にルーティングされたかに関する詳細なデータを記録します。 このルート コールの詳細データ（RCD レコード）は、Route_Call_Detail テーブルに格納されます。 RCD データは、スクリプト終了時にデータベースに書き込まれます。 直接ダイヤル、転送、会議などのルーティングされないコールには、RCD レコードはありません。 Route_Call_Detail テーブル内のデータを使用して、コールの開始点を確認できます。 たとえば、入力された自動番号識別（ANI）および行われた要求のタイプを確認できます。 一般的な Route_Call_Detail レコードには、CVP 要求で発信されたコール、および 9785551000 という ANI が含まれている場合があります。 また、ルート コールの詳細データにより、コールがキューに保持されていた時間もわかります。
- 終了コールの詳細 詳細な終了コールの詳細データ（TCD レコード）は、Peripheral に着信するすべてのコールに対して書き込まれます。 TCD レコードは、コール セグメントの終了後、および後処理の完了時に書き込まれます。 たとえば、一般的な Termination_Call_Detail データには、コールがインバウンドの ACD コールであること、そのコールが特定のスキル グループによって処理されたこと、特定のエージェントがそのコールを処理したことなどが示されます。 Termination_Call_Detail レコードにもコールの最終的な結果（たとえば、コールの終了方法（ネットワーク内で放棄、接続解除/ドロップ、および放棄遅延）が記録されます。 Packaged CCE では、大半のインバウンド コールには、少なくとも 2 つの TCD があります。1 つは CVP にあったコールのセグメント用、もう 1 つはエージェントによって処理されたコールのセグメント用です。 Termination_Call_Detail テーブルには、コール タイプ レポート、コール タイプ プレシジョン キュー レポート、およびコール タイプ スキル グループ レポートの作成に使用された TCD を示すレコードが含まれます。
コールの詳細レコードは、Route_Call_Detail テーブルと Termination_Call_Detail テーブルに格納されますが、パフォーマンス上の理由から、標準の（ストック）レポートは、この 2 つのテーブルからはデータを取得しません。
レポートでコールの詳細データを使用するには、カスタム データベースから生成されるカスタム レポートを作成する必要があります。 この 2 つの詳細テーブルは、5 週間に制約されます。 さらに詳細レコードのレポートが必要な場合は、外部データベース（AW/HDS/DDS）を設定に追加する必要があります。
レポーティング データを保持するデータベース テーブル
レポート データはすべて、Packaged CCE データベースのテーブルおよび行から取得されます。 多くのフィールドは、レポートに表示されるカラム名を反映する、直接データベース値です。
次に例を示します。
他のレポート データ フィールドはわかりにくいですが、これは、算出値を表示している、同じデータ エンティティ名が複数のコンテキストで使用されている、名前が明確に示されていない発信データベース値であるためです。
算出フィールド。 多くのレポート値は、算出フィールドの結果です。 たとえば、スキル グループのリアルタイム アクティビティを表すレポートで、平均アクティブ時間（AAT）は次のように算出されます。Skill_Group_ Real_Time.HandledCallsTalkTimeTo5 /Skill_Group_ Real_Time.CallsHandledTo5 算出フィールドの詳細については、『Unified Intelligence Center Report Template Guide』を参照してください。
複数のテーブルおよびコンテキストで使用されているフィールド。 例としては、[削除済み（Deleted）]、[説明（Description）]、および [EnterpriseName] フィールドがあり、これらは複数のテーブルに表示されます。
レポート データが異なる理由
この章では、レポートでどのようにデータが異なるか、およびその理由について説明します。
リアルタイム レポートおよび履歴レポート
リアルタイム データは 30 分間隔で履歴データベースに移動されるため、リアルタイム データのカウント（CallsHandledTo5 など）は履歴間隔レコードのカウント（CallsHandled など）とは一致しません。
8:55 にコールがコンタクト センターに着信して、エージェントが応答する例を考えます。
間隔境界
[CallsOffered] や [CallsHandled] などのカウントは 1 日単位では通常一致しますが、特定の間隔では必ずしも一致するとはかぎりません。 このような不一致は、一部のデータ要素のカウントが境界をまたいで増加している場合があるために発生します。
次の例を検討してください。8:55 にコールがコンタクト センターに着信し、エージェントが応答したとします。 エージェントは 9:05 にコールを完了しました。
- 履歴データベースでは、このコールは 8:30:00 ～ 8:59:59 の間隔で提供されたものとしてカウントされます。
- また、9:00:00 ～ 9:29:59 の間隔に処理されたものとしてカウントされます。
- 9:00:00 ～ 9:29:59 の間隔に対応するレポートを実行すると、その間隔の間に処理されたタスク数と提供されたタスク数は一致しません。
また、その間隔の間に提供されたタスク数が、放棄されたタスクと処理されたタスクの合計数と一致しない場合もあります。 提供されたタスクには、このインターバルの間にエージェントに提供されたコールとタスクの数が表示されますが、処理されたタスクおよび放棄されたタスクには、直前のインターバルで提供されてこのインターバルで完了したコールが含まれる場合があります。 一部の履歴レポート テンプレートでは、統計を「完了タスク」に分類しています。これはその統計が、特定の間隔で完了したすべてのコールとタスクを表すことを示しています。
一般には、間隔の境界問題は、日報を作成すれば低減されます。 ただし、コンタクト センターが 24 時間運用の場合、11:30:00 ～ 11:59:59 や 12:00:00 ～ 12:29:59 の間隔などでは依然として不一致が生じる可能性があります。
レポーティング エンティティおよび概念
この項では、レポートを使用できる Unified CCE エンティティについて説明します。 各エンティティの定義と、そのエンティティに関して使用できる情報の説明があります。
- エージェント状態
- エージェントのログアウト理由コード
- エージェントの受信不可理由コード
- エージェントのタスク処理
- エージェントの稼働率：フルタイム換算および稼働率
- エージェント状態を示すレポート
- エージェントのログアウト理由コードを示すレポート
- エージェントに関するレポーティング
- スキル グループ（Skill Groups）
- エージェント チームとスーパーバイザ
- 平均応答時間
- 再クエリー
- コール タイプ
- バケット間隔
- サービス レベル
- ショート コール、放棄呼、およびオーバーフロー コール
- 転送および会議
- 動作レポート
- IVR/VRU セルフサービス
エージェント状態
エージェント状態は、スキル グループ内のエージェントのアクティビティから決定されます。 エージェント状態は、多数のデータベース テーブルに記録され、レポートでは、番号（[待受停止（Not Ready）]）とパーセンテージ（[% 待受停止（% Not Ready）]）で表示されます。
現在のエージェントのアクティビティを表示するために、エージェント状態をリアルタイムでモニタすることができます。 また、エージェント状態の傾向を特定するために過去のパフォーマンス データを検討することもできます。 たとえば、履歴レポートを使用すれば、エージェントがスケジュールを守っているかどうかを示す、エージェントが待受停止状態であった時間を表示することができます。
チャット メディア ルーティング ドメイン（MRD）の場合には、一部の状態の情報が異なります。 この表では、これらの違いを明示しています。
スキル グループでの状態 |
チャットを除くすべての MRD の説明 |
チャット MRD の説明 |
|---|---|---|
アクティブ/通話中（Active/Talking） |
エージェントはこのスキル グループで、タスクまたはコールを処理中です。 音声以外のタスクを処理するエージェントの場合、この状態は「アクティブ」としてレポートされます。 音声タスクを処理するエージェントの場合、この状態は「通話中」としてレポートされます。 |
エージェントは、このスキル グループに関連付けられた 1 つ以上のチャット リクエストを処理しています。 これらのエージェントに対しては、状態は「アクティブ」としてレポートされます。 |
後処理後待受（Work Ready） |
エージェントは、このスキル グループのコールまたはタスクの後処理を行っています。 音声コールを処理している場合は、後処理の完了時に非アクティブ状態になります。 エージェントが音声以外のタスクを処理している場合は、後処理が終わるとエージェントが対応タスクなし状態または待受停止状態になる場合があります。 |
エージェントは、このスキル グループに関連付けられたタスクのラップアップを行っています。 エージェントは、このスキル グループに関連付けられたタスクに関してアクティブ状態ではありません。 |
後処理後待受停止（Work Not Ready） |
エージェントは、このスキル グループのコールの後処理を行っています。 後処理が完了すると、エージェントは待受停止状態になります。 |
エージェントは、このスキル グループのコールの後処理を行っています。 後処理が完了すると、エージェントは待受停止状態になります。 |
一時停止/保留（Paused/Hold） |
音声以外のタスクを処理するエージェントの場合、状態は「一時停止」としてレポートされます。 音声タスクを処理するエージェントの場合、状態は「保留」としてレポートされます。 アウトバウンド オプション コールを処理するエージェントの場合、保留状態はエージェントがコールに対して確保されていることを示します。これは、アウトバウンド ダイヤラがコールの接続中にエージェントを保留にするためです。 |
このスキル グループに関連付けられたチャット タスクに関して、エージェントは「一時停止」状態です。 |
リザーブ（Reserved） |
このスキル グループに関連付けられたコールまたはタスクがエージェントにすでに提供されています。 音声コールの場合は、エージェントの電話機が呼び出されているときに予約済み状態になります。 アウトバウンド オプション コールを処理するエージェントがリザーブ状態になることはありません。アウトバウンド オプション ダイヤラでは、コールに対してエージェントを確保する際にエージェントを保留にします。 |
エージェントは、このスキル グループにおいて、アクティブ、後処理後待受、一時停止のいずれの状態でもありません。 このスキル グループに関連付けられた 1 つ以上のタスクが、エージェントにすでに提供されています。 |
他スキル ビジー（Busy Other） 他スキル ビジー状態とは、間隔の間に、他のスキル グループに割り当てられているコールをエージェントが処理している状態を指します。 たとえば、あるエージェントは、1 つのスキル グループにおいてインバウンド コールで通話しながら、同時に別のスキル グループにログオンして、このスキル グループからのコールを受け入れられるようにしている場合があります。 エージェントがアクティブ状態になれるのは（コールで通話したり、コールを処理したりできるのは）、一度に 1 つのスキル グループのみです。 したがって、このエージェントが 1 つのスキル グループでアクティブ状態になっている間は、別のスキル グループでは他スキル ビジー状態になっているものと見なされます。 |
同じ MRD の別のスキル グループで、エージェントがアクティブ、後処理後待受、リザーブ、または保留/一時停止のいずれかの状態になっています。 |
エージェントは、このスキル グループに関連付けられたタスクに関してアクティブ、後処理後待受、リザーブ、または一時停止の状態ではありません。 同じ MRD の別のスキル グループで、エージェントがアクティブ、後処理後待受、リザーブまたは一時停止のいずれかの状態になっています。 |
対応タスクなし（Not Active） |
エージェントはこのスキル グループに関連付けられたタスクまたはコールの作業をしていません。 |
エージェントはこのスキル グループに関連付けられたタスクまたはコールの作業をしていません。 |
待受停止（Not Ready） |
エージェントにタスクを割り当てることはできません。 エージェントが 1 つのスキル グループで待受停止の場合、エージェントは同じ MRD 内のすべてのスキル グループで待受停止になります。 |
エージェントにタスクを割り当てることはできません。 エージェントが 1 つのスキル グループで待受停止の場合、エージェントは同じ MRD 内のすべてのスキル グループで待受停止になります。 |
レポートでのエージェント状態の計算方法
エージェントの状態は、多くのレポートでパーセンテージで表されます。
| テーブル.フィールド |
計算 |
|---|---|
| % 対応中（%Active） |
Agent_Skill_Group_ Interval.TalkInTime + Agent_Skill_Group_ Interval.TalkOutTime + Agent_Skill_Group_ Interval.TalkOtherTime + Agent_Skill_Group_ Interval.TalkAutoOutTime + Agent_Skill_Group_ Interval.TalkPreviewTime + Agent_Skill_Group_ Interval.TalkReserveTime / Agent_Skill_Group__ Interval.LoggedOnTime |
| % ビジーその他（%BusyOther） |
Agent_Skill_Group _Interval.BusyOtherTime / Agent_Skill_Group_ Interval.LoggedOnTime |
| % 保留中（%Hold） |
Agent_Skill_Group_ Interval. HoldTime / Agent_Interval.LoggedOnTime |
| % 対応タスクなし（%NotActive） |
履歴：Agent_Skill_Group_ Interval.AvailTime / Agent_Interval.LoggedOnTime リアルタイム：Skill_Group_Real_Time.Avail / Skill_Group_Real_Time.LoggedOn |
| % 予約済（%Reserved） |
Agent_Skill_Group _ Interval.ReservedStateTime / Agent_Skill_Group _Interval.LoggedOnTime |
| % 後処理（%WrapUp） |
(Agent_Skill_Group _Interval.WorkReadyTime + Agent_Skill_Group_ Interval.WorkNotReadyTime ) / Agent_Skill_Group_Interval.LoggedOnTime) |
| % 待受停止（% Not Ready） |
Agent_Skill_Group _Interval.NotReadyTime / Agent_Skill_Group_Interval.LoggedOnTime |
エージェント状態、スキル グループ、およびプレシジョン キュー
エージェントは、MRD 内の複数のスキル グループまたはプレシジョン キューに属することができます。 エージェントがスキル グループにルーティングされたタスクを処理するとき、エージェントはそのスキル グループでアクティブになります。
- 直接着信コールの場合、またはルーティングされたコールがダイヤル番号を使用せずに転送された場合、アクティブなスキル グループはそのエージェントのデフォルト スキル グループまたは最初に定義されているスキル グループです。
- 新規発信コール（AgentOutCall または InternalCall）または転送されたアウトバウンド コールの場合、アクティブなスキル グループは、エージェントに最初に定義されているスキル グループです。
チャット タスクを処理する（および同時に複数のタスクを作業できる）エージェントに関してレポートする場合は、[MRD で利用可能（Available in MRD）] カラムおよび [エージェント状態（Agent State）] カラムの両方からエージェントの状態の情報を収集します。
アクティブなスキル グループまたはプレシジョン キューにおけるエージェントの状態によって、所属する MRD の他のスキル グループまたはプレシジョン キューの状態が、次のように決まります。
エージェント状態とタスク状態の関係
エージェント状態時間は、コールまたはタスクが終了しているかどうかにかかわりなく、間隔の境界ごとにレポートされます。 コールおよびタスクの状態時間は、タスクが終了した時点でだけレポートされます。 コールまたはタスクは、ラップアップが完了した時点で終了します。
次の図は音声コールの場合のエージェント状態とコール状態の相関関係を示しています。 エージェントのリザーブ時間には、コールがエージェントの電話を呼び出していた時間、またはエージェントのデスクトップで待った時間（提供/呼び出し時間）だけでなく、コールがエージェントの電話またはデスクトップに到達するのにかかった時間（ネットワーク時間）も含まれています。
コールがエージェントの電話を呼び出しているときに間隔の境界が終了した場合、エージェントのリザーブ時間には、エージェントのリザーブ時間にはネットワーク時間と呼び出し時間の一部が含まれます。 残りの呼び出し時間は、次の間隔で、そのエージェントのリザーブ時間にレポートされます。 ただし、コールの時間はそのコールのラップアップが完了するまでレポートには表示されません。
エージェント状態を示すレポート
エージェントの状態に関する情報を示すレポートの一部は、次のとおりです。
エージェントのログアウト理由コード
エージェントのログアウト理由コードは、エージェント デスクトップ ソフトウェアで定義し、履歴レポートでは、テキスト コードを持たない相当する数字として表示されます。 たとえば、理由コード 1 が「End of Shift」に相当し、エージェントがログアウトでその理由を選択した場合、レポートには「1」と表示されます。
デスクトップで設定されたコードに加えて、エージェントがソフトウェアによってログアウトされると一部のコードが自動的に生成されます。 次の表では、これらの事前定義されたログアウト理由コードについて説明します。
事前定義されたログアウト理由コード |
説明 |
|---|---|
-1 |
Peripheral の再起動により、エージェントが再び初期化されました。 |
-2 |
PG によってエージェントがリセットされました。通常は、PG の障害が原因です。 |
-3 |
エージェントがログインしている間に、管理者がそのエージェントの内線を変更しました。 |
50002 |
CTI OS コンポーネントに障害が発生したために、エージェントがログアウトされました。 これは、エージェント デスクトップ アプリケーションのクローズ、ハートビートのタイムアウト、CTI OS サーバの障害、または CTI OS の障害のいずれかが原因である可能性があります。 |
50004 |
Agent Desk Settings で設定されている非アクティブ状態が発生したため、エージェントがログアウトされました。 |
50020 |
エージェントのスキル グループの割り当てが動的に変更されたため、エージェントがログアウトされました。 |
50030 |
エージェントのスキル グループの割り当てが Administration & Data Server 上で動的に変更されたため、エージェントがログアウトされました。 |
50040 |
コールに失敗したためモバイル エージェントがログアウトされました。 |
50042 |
固定接続モードを使用しているときに電話回線が切断されたため、モバイル エージェントがログアウトされました。 |
エージェントのログアウト理由コードを示すレポート
エージェントのログアウト理由コードに関する情報を含むレポートの一部は、次のとおりです。
エージェントの受信不可理由コード
待受停止状態になる際にエージェントが選択したコードを示し、待受停止状態であった経過時間のパーセンテージを計算し、指定する時間範囲に基づいて特定の待受停止理由を示すレポートがあります。
これらのレポートは、エージェントが適切な回数の休憩を取っているか、休憩の長さは適切かを確認するのに役立ちます。
一部のレポートには、理由コードのテキスト（設定している場合）および対応する番号の両方が表示されます。 たとえば、エージェントが待受停止状態になる際に「ブレーク（Break）」を理由コードとして選択し、Configuration Manager でこのコードにテキストを設定した場合、レポートには「ブレーク [1]（Break [1]）」と表示されます。 他のレポートには、待受停止理由コードの番号のみが表示されます。
エージェントのログイン セッション全体が指定された時間範囲に含まれていない場合（エージェントが時間範囲の終わりにまだログイン中の場合など）は、レポートではエージェント名の横にアスタリスク（*）が表示されて、その時間範囲のエージェントのデータが完全なものではないことが示されます。
Unified CC の場合は、ユーザが定義した待受停止理由コードに加えて、ソフトウェアによって自動的にエージェントが待受停止状態にされた場合のために事前定義された待受停止理由コードがあります。 次の表では、これらの事前定義された待受停止理由コードについて説明します。
事前定義された待受停止理由コード |
説明 |
||
|---|---|---|---|
50001 |
CTI OS クライアントの接続が解除され、エージェントがログアウトされました。
|
||
50002 |
CTI OS コンポーネントに障害が発生したために、エージェントがログアウトされました。 これは、エージェント デスクトップ アプリケーションのクローズ、ハートビートのタイムアウト、CTI OS サーバの障害、または CTI OS の障害のいずれかが原因である可能性があります。 |
||
50003 |
Unified CM によって、そのデバイスがアウト オブ サービスであるとレポートされたため、エージェントがログアウトされました。 |
||
50004 |
エージェント デスク設定で定義されているエージェントの非アクティブ状態が発生したため、エージェントはログアウトされました。 |
||
50005 |
Peripheral で複数回線のエージェント制御が有効な Packaged CCE による展開で、複数回線のエージェントの動作がエージェント状態に影響を与えるように設定されている場合、エージェントは、非 ACD 回線でのコールの通話中に、このコードを使用して待受停止に設定されます。 |
||
50010 |
エージェントは、ルーティングされた複数のコールを連続して受信しませんでした。 エージェントにコールがこれ以上ルーティングされないように、システムはエージェントを自動的に待受停止にします。 デフォルトでは、コールを連続して 2 件受信しないと、そのエージェントが待受停止になるように設定されています。 |
||
50020 |
エージェントのスキル グループが Administration & Data Server 上で動的に変更されたため、エージェントはログアウトされました。 |
||
50030 |
あるエージェントが、PG 静的デバイス ターゲットと同じダイヤル番号（DN）を使用する動的なデバイス ターゲットにログインした場合、このエージェントはログアウトされます。 |
||
50040 |
コールに失敗したため、モバイル エージェントはログアウトされました。 |
||
50041 |
モバイル エージェントの電話回線がビジーで呼び出したときにコールが失敗したため、このモバイル エージェントの状態は待受停止に変更されました。 |
||
50042 |
常時接続モードの使用中、電話回線が切断されたため、モバイル エージェントはログアウトされました。 |
||
50041 |
エージェントの電話回線がビジーで呼び出したときにコールが失敗したため、エージェントの状態が待受停止に変更されました。 |
||
32767 |
エージェントがコールに応答せず、コールが別のエージェントまたはスキル グループにリダイレクトされたため、エージェントの状態が待受停止に変更されました。 |
||
-1 |
エージェントが再初期化されました（Peripheral の再起動時に使用されます）。 |
||
-2 |
PG によってエージェントがリセットされました。通常は、PG の障害が原因です。 |
||
-3 |
エージェントがログインしている間に、管理者がそのエージェントの内線を変更しました。 |
デフォルトでは、事前定義された待受停止理由コードには、文字による理由コードは関連付けられていません。 レポートには番号で表示されます。 これらの待受停止理由コードに対応する文字コードを表示する場合は、Reason Code ガジェットで事前定義された待受停止理由コードを入力して、関連付けるテキストを入力してください。 たとえば、32767 の待受停止理由コードに「Redirection on No Answer」というラベルを付けることができます。
エージェントの待受停止理由コードを示すレポート
待受停止コードに関する情報と受信不可として経過した時間を含むレポートの一部は、次のとおりです。
エージェントのタスク処理
エージェントはさまざまなタイプのタスクの受信と発信を行えます。 エージェントが処理するタスクのタイプおよびエージェントのタスクの処理効率を示すレポートがあります。 たとえば、発信、受信、転送、および会議コールの統計情報を示すレポートがあります。また、エージェントがコールに応答できなかったときに、再ルーティングされたコールの数を示すレポートもあります。
タスクのタイプ
タスクには、内部または外部、受信または発信があります。
- 内部タスクは、1 人のエージェントに対して別の人または Packaged CCE 内の別のエージェントから発信されるコールです。
- 外部タスクは、Packaged CCE 外に発信されるコール、CVP 経由で着信するタスク 、または Packaged CCE 外の 人からエージェントに対してルーティングされるタスクです。 たとえば、コール センターから顧客へのコールは外部と見なされます。
- 受信タスクは、1 人のエージェントが受信するタスクです。 マルチチャネルのタスクは常に受信になります。
- 発信タスクは、1 人のエージェントが発信するコールです。 たとえば、顧客がエージェントに電話を掛ける場合、そのコールはエージェントにとっては受信になります。 エージェントがスーパーバイザに電話を掛ける場合、そのコールはエージェントにとっては発信になります。
音声コールの場合だけ、エージェントは、コールの転送、転送されたコールの受信、コンサルティング コールの発信、および会議コールへの参加を行えます。
次の表では、エージェントが受信および発信を行えるタスクとそれらのタスクのレポート方法について説明します。
タスクのタイプ |
説明 |
レポートされる項目 |
||
|---|---|---|---|---|
受信直接/内部 |
受信直接タスクは、エージェントの内線に直接到達するタスクです。 この種類のコールの例としては、スクリプトを通過せずに別のエージェントから直接転送されたコールやエージェント転送コールの結果として発生したコールがあります。 これらのコールのデータは、Agent_Skill_Group_Interval 履歴データベース テーブルの [InternalCallsRcvd] フィールドに保存されます。 |
内部受信 |
||
発信外部 |
これらは、エージェントが自分の内線から発信するコールで、コンタクト センターの外側に発信されます。 発信外部タスクは常に音声タスクです。 コンサルタティブ コール、会議発信コール、および転送発信コールは、それらのコールがコンタクト センターの外側または別のサイトでリモート エージェントの内線に発信された場合、発信外部コールとしてカウントされます。 エージェント転送ダイヤリングは、接続先エージェントに到達するためにコールがコンタクト センターの外側に発信される場合は、コールを開始するエージェントにとっては発信外部となります。 これらのコールのデータは、Agent_Skill_Group_Interval 履歴データベース テーブルの [AgentOutCalls] フィールドに保存されます。 |
外部発信タスク |
||
発信内部 |
これらはエージェントが自分の内線からコンタクト センター内の別の内線に発信するコールです。 発信内部タスクは常に音声タスクです。 コンサルタティブ コール、会議発信コール、および転送発信コールは、それらのコールが別の CVP に発信された場合、発信内部コールとしてカウントされます。 エージェント転送コールは、コールを開始するエージェントにとっては発信内部コールとなります。 これらのコールのデータは、Agent_Skill_Group_Interval 履歴データベース テーブルの [InternalCalls] フィールドに保存されます。 |
内部発信タスク |
||
Packaged CCE ルーティング コール |
エージェントへルーティングされるすべてのコールです。 アウトバウンド オプション コールは Packaged CCE ルーティング/受信コールと見なされます。 これらのコールのデータは、Agent_Skill_Group_Interval 履歴データベース テーブルの [CallsHandled] フィールドに保存されます。 |
処理タスク 処理タスクには、転送されるコールおよび電話会議になるコール、およびコンサルティング コールを含むすべてのコールが含まれます。 処理タスクの情報を利用すれば、ルーティングされたタスクの全体像を把握できます。 [転送受信（Transfer In）] および [会議発信（Conf Out）] などの他のレポート カラムには、タスクがどのように処理されたかを示す詳細情報が表示されます。 |
||
転送受信 |
1 人のエージェントに別のエージェントから転送されるコールです。 再ルーティングのため 1 人のエージェントから CVP へブラインド転送されるコールは、この列の再ルーティングされたコールを受信するエージェントにカウントされます。
これらのコールのデータは、Agent_Skill_Group_Interval 履歴データベース テーブルの [TransferredIn] フィールドに保存されます。 |
転送受信（Transfer In） |
||
転送発信 |
エージェントから転送されたコール。 エージェントは、受信コールと発信コールの両方を転送できます。 これらのコールのデータは、Agent_Skill_Group_Interval 履歴データベース テーブルの [TransferredOut] フィールドに保存されます。 |
転送発信（Transfer Out） |
||
コンサルタティブ |
エージェントが別のコールを保留状態にして、別のエージェントまたはスーパーバイザに相談したコール。 これらのコールのデータは、Agent_Skill_Group_Interval 履歴データベース テーブルの [ConsultativeCalls] フィールドに保存されます。 |
コンサルト発信 |
||
会議受信 |
受信した会議コール。 これらのコールのデータは、Agent_Skill_Group_Interval 履歴データベース テーブルの [ConferencedInCalls] フィールドに保存されます。 |
会議受信 |
||
会議発信 |
発信した会議コール。 これらのコールのデータは、Agent_Skill_Group_Interval 履歴データベース テーブルの [ConferencedOutCalls] フィールドに保存されます。 |
会議発信 |
タスク時間
エージェントが行えるタスクのタイプごとに、エージェントがそのタスクの処理に費やした時間が Agent_Skill_Group_Interval データベース テーブルに次のように記録されます。
- Packaged CCE ルーティング タスク：これらのタスクの時間は、エージェントがタスクに応答した時点で開始し、エージェントがラップアップを完了した時点で終了します。 この時間は [HandledCallsTime] フィールドに保管されます。
- 受信直接タスク：これらのタスクの時間は、エージェントがタスクに応答した時点で開始し、タスクが切断された時点で終了します。 この時間は [InternalCallsRcvdTime] フィールドに保管されます。
- 外部発信タスク：これらのタスクの時間は、エージェントがタスクを開始した時点で開始し、タスクが切断された時点で終了します。 この時間は [AgentOutCallsTime] フィールドに保管されます。
- 内部発信タスク：これらのタスクの時間は、エージェントがタスクを開始した時点で開始し、タスクが切断された時点で終了します。 この時間は [InternalCallsTime] フィールドに保管されます。
- 転送受信タスク：これらのタスクの時間は、エージェントが転送されたタスクに応答した時点で開始し、タスクが切断された時点で終了します。 この時間は [TransferredInCallsTime] フィールドに保管されます。
- 転送発信タスク：これらのタスクの時間は、エージェントが転送ボタンをアクティブにした時点で開始し、転送が完了した時点で終了します。 この時間は [TransferredOutCallsTime] フィールドに保管されます。
- コンサルタティブ タスク：これらのタスクの時間は、エージェントが転送ボタンをアクティブにした時点で開始し、ターゲット エージェントが応答して保留中のタスクが復元された（コンサルト コールがドロップされた）とき、またはコンサルト先の通話者がドロップした時点で終了します。 この時間は [ConsultativeCallsTime] フィールドに保管されます。
- 会議受信タスク：これらのタスクの時間は、エージェントがタスクに応答した時点で開始し、タスクが切断された時点で終了します。 この時間は [ConferenceInCallsTime] フィールドに保管されます。
- 会議発信タスク：これらのタスクの時間は、エージェントが会議ボタンをアクティブにした時点で開始し、エージェントが会議コールから切断され、スーパーバイザがコールからドロップした時点で終了します。 この時間は [ConferenceOutCallsTime] フィールドに保管されます。
さまざまなタイプのコールの、時間に関するレポート データが重複していることに気付く場合があります。 これは、エージェントに直接 ルーティングされるタスクおよびコールなどの受信タスクは、転送受信と会議受信になり得るために起こります。 エージェントにより行われた受信コールまたは発信コールは両方とも、転送発信と会議発信になり得ます。 受信コールまたは発信コールの合計時間には、転送と会議の時間も含まれています。
（注） |
エージェントは、着信コールに対して、受信と発信の両方向に転送と会議を実行できます。 ただし、発信コールの場合にエージェントが転送と会議を実行できるのは、発信方向だけです。 この違いは、エージェントが発信タスクを別のエージェントに転送する場合、そのタスクは引き続き発信タスクと見なされることを意味します。 |
エージェントのタスク処理を示すレポート
Unified IC エージェント - 履歴全フィールド レポートには、待受停止コードに関する情報と待受停止として経過した時間が含まれます。
エージェントの稼働率：フルタイム換算および稼働率
エージェントは複数のメディアや複数のスキル グループで作業できるため、全時間を 1 つのスキル グループのタスクの処理に費やすことは通常はありません。 スキル グループとメディアで作業するエージェントを基準として必要なスタッフを調べることが難しい場合があります。
レポート テンプレートではエージェントの稼働率と、特定のスキル グループで一定期間内に実行される作業の処理に必要なフルタイム勤務のエージェントの人数を簡単に確認できる、2 つのタイプの統計が用意されています。
これらの統計は、次のとおりです。
稼働率（レポートでは [% 稼働率（% Utilization）]）は、スキル グループでエージェントがコール処理に費やした合計時間を、エージェントがタスクを処理できる状態であった合計時間で除算して算出されます。 エージェントが待受中であった時間を算出する場合、システムは、エージェントがログオンしていた合計時間から待受停止状態であった時間を減算して算出されます。 稼働率は、スキル グループ内でのエージェントの稼働率を示します。 たとえば、40 分間コールの処理が可能であったエージェントが、実際のコールの処理に 20 分を費やした場合、そのエージェントの稼働率は 50% になります。
フルタイム換算（レポートでは [FTE]）は、その一定期間内にそのスキル グループで処理された作業を実行するために必要となる、フルタイム勤務のエージェントの人数を表します。 システムでは FTE を算出するために、作業が実行された合計時間をその間隔の合計時間で除算します。 たとえば、エージェントが間隔（30 分）の間にタスクの処理に合計 3 時間（180 分）を費やした場合、その間隔内のタスク処理の FTE は 180 分/30 分であり、フルタイム勤務のエージェント 6 人に相当します。 つまり、すべてのエージェントがフルタイムでタスクを処理した場合、その作業は 6 人のエージェントで処理できたことになります。
レポートには、8 時間シフトの計算に基づいた FTE 値も示されます。 エージェントは 1 日 8 時間のシフトで働くものと仮定しています。 FTE は、作業が実行された合計時間を 8 時間で除算して計算されます。 たとえば、複数のエージェントが 8 時間の作業シフト（480 分）の間にタスクの処理に合計 48 時間（2,880 分）を費やした場合、その間隔内のタスク処理の FTE は 2,880 分/480 分であり、フルタイム勤務のエージェント 6 人に相当します。 つまり、すべてのエージェントがフルタイムでタスクを処理した場合、その作業は 6 人のエージェントで処理できたことになります。
（注） |
8 時間未満の間隔をレポートで選択した場合、結果の値は予想より低くなります。 |
稼働率と FTE メトリックを示すレポート
使用率と FTE に関する動作情報を含むレポートの一部は、次のとおりです。
エージェント状態を示すレポート
エージェントの状態に関する情報を示すレポートの一部は、次のとおりです。
エージェントのログアウト理由コードを示すレポート
エージェントのログアウト理由コードに関する情報を含むレポートの一部は、次のとおりです。
エージェントに関するレポーティング
これらは、エージェントに関する Cisco Unified Intelligence Center のレポートです。
スキル グループ（Skill Groups）
スキル グループとは、同じタイプの要求を処理できる共通の能力を持つ、エージェントの集まりです。 たとえば、同じ言語を話すエージェントや、請求に関する問い合わせに対応できるエージェントの集まりなどです。
各スキル グループは、1 つのメディア ルーティング ドメインに属しています。
エージェントは、ゼロ、1 つ、または複数のスキル グループのメンバーになることができます。
エージェントのパフォーマンスをモニタする際には、エージェントのレポートを個別に作成することも、1 つ以上のスキル グループのすべてのエージェントを対象にレポートを作成することもできます。
スキル グループのレポートを作成し、エージェントのアクティビティ（たとえば通話中のエージェント数、応答可能なエージェント数、または特定のスキル グループの後処理をしているエージェント数など）を表示できます。
エージェント スキル グループ レポートの作成に加えて、スキル グループ レポートを使用して動作のパフォーマンスを監視することもできます。 たとえば、あるスキル グループのパフォーマンスを別のスキル グループと比較したり、ルーティング スクリプトと設定によってコールが均等に分配されているかどうかを確認したりできます。
デフォルトのスキルグループ（Default Skill Group）
デフォルトのスキル グループは、音声コールと音声以外のタスクに関する情報を取得するバケットとして機能します。
- レポーティングにおけるデフォルトのスキル グループのロール
- 新規コールによるデフォルトのスキル グループ統計の増加
- エージェント間のダイヤリングによるデフォルトのスキル グループ統計の増加
- 転送コールおよび会議コールによるデフォルトのスキル グループ統計の増加
レポーティングにおけるデフォルトのスキル グループのロール
次の状況では、デフォルト スキル グループがバケットとして動作し、情報を取得します。
- Packaged CCE ルーティング スクリプトによりルーティングされないコールの場合
- スキル グループがルーティング スクリプトで指定されない場合
- エージェント転送ノードがエージェント間ダイヤリング用ルーティング スクリプトで使用されている場合
- エージェント キューイング ノードがエージェントにタスクをキューイングし、エージェントがエージェント キューイング ノードで指定されたスキル グループにログインされない場合
デフォルト スキル グループを使用すると、次の利点があります。
- サービスおよびコール タイプ レポートには Packaged CCE ルーティング コールのみが含まれるため、エージェントまたはスキル グループ レポートがサービスおよびコール タイプ レポートとバランスします。
- エージェントおよびスキル グループ レポート内で非 Packaged CCE ルーティング コールを隔離または識別します。
デフォルトのスキル グループの統計は、さまざまなタイプのコール（新規コール、エージェント間のダイヤリング、転送コール、会議コール）によって影響を受けます。
Packaged CCE システムでマルチチャネル オプションを導入すると、設定されるメディア ルーティング ドメインごとにデフォルト スキル グループが作成されます。
新規コールによるデフォルトのスキル グループ統計の増加
すべての直接発信コールおよび直接受信コールが新規に発生した場合、デフォルトのスキル グループのコール統計は、次のフィールドが増加します。
-
外部発信コールの [AgentOutCalls]
（注）
エージェントがコンサルタティブ コールの一部としてコールを発信する場合、コールにはデフォルトのスキル グループの属性が設定されません。 元のコールのコンサルティング エージェントのスキル グループの属性が設定されます。 - 内部発信コールの [InternalCalls]
- 直接着信コールの [InternalCallRcvd]
（注） |
デフォルトのスキル グループはどのスクリプトでも参照されないため、デフォルトのスキル グループの [CallsHandled] は増加しません。 |
エージェント間のダイヤリングによるデフォルトのスキル グループ統計の増加
スクリプト内でエージェント転送ノードを使用してエージェント間のダイヤリングを行った場合も、デフォルトのスキル グループは影響を受けます。 OutgoingExternal または OutgoingInternal は、エージェント間のコールを開始したエージェントのデフォルトのスキル グループに対して増加します。 デフォルトのスキル グループである InternalCallsReceived は、エージェント間のコールを受信したエージェントのデフォルトのスキル グループに対して増加します。
転送コールおよび会議コールによるデフォルトのスキル グループ統計の増加
デフォルトのスキル グループは、転送コールと会議コールの影響も受けます。 エージェント A が、 Packaged CCE/IPCC でルーティングされたコールを、スクリプトを使用せずに直接別のエージェントへ転送するか会議を実行した場合、エージェント A の OutgoingExternal または OutgoingInternal は、 Packaged CCE でコールがルーティングされたスキル グループに計上されます。 ただし、エージェント B の IncomingDirect コールは、デフォルトのスキル グループに計上されます。
ただし、そのエージェント（エージェント A）が、 Packaged CCE/IPCC でルーティングされたコールを、エージェント転送ノードを含む転送スクリプトまたは会議スクリプトにアクセスするためのダイヤル番号に転送するか会議を実行した場合、エージェント A の OutgoingExternal または OutgoingInternal は、 Packaged CCE/IPCC でコールがルーティングされたスキル グループに対して増加します。 エージェント B の IncomingDirect コールは、デフォルトのスキル グループに対して増加します。
既存のコールが存在しない場合、デフォルトのスキル グループは、緊急アシスト コールおよびスーパーバイザ アシスト コールに対しても増加します。
スキル グループの操作に関するレポート
スキル グループ テンプレートを使用すると、操作について深く理解したり、あるスキル グループが他のスキル グループと比較してどのように実行されるかを確認したり、ルーティング スクリプティングと設定によりコールが均等に分散されるかどうかを追跡したりできます。
（注） |
複数のスキル グループのエージェントについては、エージェント パフォーマンスを監視するためにスキル グループ テンプレート別にエージェントをツールとして使用することもできます。 |
提供されたコールのスキル グループに対する計算方法
スキル グループでの RouterCallsOffered の完了状態は、Skill_Group_Interval テーブルの次のフィールドを使用して計算されます。
スキル グループ操作を示すレポート
スキル グループに関する動作情報を含むレポートの一部は、次のとおりです。
エージェント チームとスーパーバイザ
この項では、エージェント チームとスーパーバイザについて説明します。
エージェント チームとスーパーバイザ
この項では、エージェント チームとスーパーバイザについて説明します。
エージェント チーム レポート
スーパーバイザは、監視するチームのエージェントに関するレポートを作成して、特定のチームのパフォーマンスをモニタできます。
プライマリ スーパーバイザはエージェント チームに、0 または 1 人選択できます。セカンダリ スーパーバイザは、各チームに複数選択できます。 各スーパーバイザは、複数のチームのスーパーバイザになれます。
スーパーバイザのアクション レポート
エージェント チームのスーパーバイザは、デスクトップ上でスーパーバイザ機能を利用できます。 これらの機能には、スーパーバイザ アシスト、緊急支援、割り込み、および代行受信があります。 スーパーバイザ アシストと緊急支援には、既存のコールとコールなしの 2 つの種類があります。
（注） |
これらのスーパーバイザ機能は、音声以外の MRD を使用しているエージェントでは利用できません。 |
既存のコールに対するスーパーバイザ アシストおよび緊急支援
Unified Intelligence Center では、スーパーバイザ アシストと緊急支援を有効にできます。
エージェントは、チームに割り当てられているプライマリ スーパーバイザまたはセカンダリ スーパーバイザからの特別なアシスタンスが必要な場合、デスクトップ上の [SV アシスト（supervisor assist）] または [緊急アシスト（emergency assist）] ボタンをアクティブにできます。
次のガイドラインに従うと、正しくて役に立つデータをこれらの機能から取得できます。
- スーパーバイザ アシスト リクエストおよび緊急アシスト リクエストを処理するスーパーバイザのためのスキル グループを設定するように計画します。 たとえば、各エージェント チームのプライマリ スーパーバイザとセカンダリ スーパーバイザに対して、1 つのスキル グループを設定します。 このようにすると、これらのスキル グループにリクエストを転送でき、これらのスキル グループのスーパーバイザ アシストおよび緊急アシストのコール アクティビティに関してレポートを作成できます。
- コール タイプを作成し、作成されたコール タイプにマップされるダイヤル番号を設定することを計画します。
- 要求を適切なスーパーバイザ スキル グループに送信するスクリプトを実行します。 スクリプトでは、まずプライマリ スーパーバイザを対象とした後、セカンダリ スーパーバイザが設定されている場合は、セカンダリ スーパーバイザにキューイングします。
スーパーバイザ アシストまたは緊急支援に対して、エージェントのデスクトップ設定で [コンサルト（consult）] がオプションとして選択されている場合： エージェントがスーパーバイザ アシストまたは緊急支援のデスクトップ機能をアクティブにするときにエージェントがコール中の場合、CTI ソフトウェアはエージェントの電話の代わりに会議キーをアクティブにし、スーパーバイザ アシストまたは緊急支援のスクリプトを使用してスーパーバイザをコールします。 （この例では、緊急アシストまたはスーパーバイザ アシストのスクリプトに、スーパーバイザを検出するためのエージェント転送ノードがあると仮定しています。 スーパーバイザ アクションのレポートについては、『Configuration and Scripting Considerations for Reporting on Supervisor Action』を参照してください）。スーパーバイザは、コールに応答し、エージェントにプライベートで相談します。 Agent Skill Group テーブルと Skill Group テーブル内で、次のフィールドが増加します。
コールのルーティング先のエージェント スキル グループに対して増加するフィールド |
スーパーバイザのデフォルトのスキル グループに対して増加するフィールド |
|---|---|
CallsHandled、InternalCall、SupervisorAssistCalls/EmergencyAssist |
InternalCallsRcvd |
エージェントについては、コールは [処理タスク（Tasks Handled）] レポート フィールド、および [SV アシスト（Sup Assist）] または [緊急（Emergency）] レポート フィールドのいずれかにレポートされます。 スーパーバイザの場合、コールは [処理タスク（Tasks Handled）] レポート フィールドにレポートされます。
（注） |
コンサルテーション中、スーパーバイザは、スーパーバイザのデスクトップの介入機能を使用して、コールへの介入を決定できます。 |
割り込み
スーパーバイザがデスクトップへの割り込み機能をアクティブにすると、エージェントのデスクトップはスーパーバイザへの会議を完了し、スーパーバイザがコールに参加できるようにします。 エージェント スキル グループおよびスキル グループのテーブルで割り込み機能がアクティブにされた場合、エージェントとスーパーバイザの両方の次のフィールドが増加します。
コールのルーティング先のエージェント スキル グループに対して増加するフィールド |
スーパーバイザのデフォルトのスキル グループに対して増加するフィールド |
|---|---|
CallsHandled、InternalCall、BargeInCalls |
BargeInCalls、InternalCallsRcvd |
エージェントについては、コールは [処理タスク（Tasks Handled）] レポート フィールドおよび [割り込み（Barge-In）] レポート フィールドにレポートされます。 スーパーバイザについては、コールは [処理タスク（Tasks Handled）] レポート フィールドおよび [割り込み（Barge-In）] レポート フィールドにレポートされます。
代行受信
スーパーバイザはコールを代行受信（引き継ぎ）する場合、[代行受信（Intercept）] デスクトップ ボタンを有効にします。 これにより、エージェントが会議から切断されるため、スーパーバイザはコールを代行受信できるようになります。 代行受信の操作中には、Agent Skill Group テーブルと Skill Group テーブルの両方に対して、次のフィールドが増加します。
コールのルーティング先のエージェント スキル グループに対して増加するフィールド |
スーパーバイザのデフォルトのスキル グループに対して増加するフィールド |
|---|---|
InterceptCalls |
InterceptCalls |
エージェントの場合、コールは [代行受信（Intercept）] レポート フィールドにレポートされます。 スーパーバイザの場合、コールは [代行受信（Intercept）] レポート フィールドにレポートされます。
エージェント チームに関する情報を示すレポート
これらは、エージェント チームの情報を含むレポートの一部です。
スーパーバイザに関するレポーティング
これらは、スーパーバイザに関する Cisco Unified Intelligence Center のレポートです。
エージェント チームに関する情報を示すレポート
これらは、エージェント チームの情報を含むレポートの一部です。
平均応答時間
平均応答時間（ASA）は、サービスに対するすべての受信タスクが応答されるまで待機した時間の合計です。 これには、遅延時間、キュー時間、および呼び出し時間が含まれます。
ASA はコールがキューに入った時点で開始し、次のレベルで設定されます。
エージェント レベルとスキル グループ レベルでは、エージェントおよびスキル グループのパフォーマンスの監視に ASA メトリックが役立ちます。
コール タイプ レベルでは、ASA メトリックにより、発信者のシステム操作およびコールへの応答速度に関する情報が得られます。
エージェントの場合：エージェントの平均応答時間は、HH:MM:SS（時、分、秒）の形式で、タスクが応答されるまでに発信者がキューで待機した時間とエージェント デスクトップで呼び出していた時間の合計をエージェントが応答したタスクの数で除算することによって得られる値。
スキル グループの場合：スキル グループの平均応答時間は、HH:MM:SS（時、分、秒）の形式で、タスクが応答されるまでに発信者がキューで待機した時間とエージェント デスクトップで呼び出していた時間の合計を応答されたタスクの数で除算することによって得られる値。
コール タイプの場合：コールが最初のスキル グループ キューイングまたは最長時間対応可能なエージェント（LAA）選択ノードで処理されてから、そのコールが応答されるまでにかかった、平均応答時間。 この時間は、コールの量やスタッフのレベルに応じて 1 日の間でも変化するので、サービス品質の重要な尺度となります。
プレシジョン キューの場合：プレシジョン キューの平均応答時間は、HH:MM:SS（時、分、秒）の形式で、タスクが応答されるまでに発信者がキューで待機した時間とエージェント デスクトップで呼び出していた時間の合計を応答されたタスクの数で除算することによって得られる値。
ASA の計算方法
ASA の計算方法は、レポーティング オブジェクトに関連付けられているシステムのタイプによって異なります。
テーブル.フィールド |
計算 |
|---|---|
Skill_Group_Interval |
Skill_Group_ Interval.AnswerWaitTime / Skill_Group_ Interval.CallsAnswered |
CallType _Interval |
Call_Type_ Interval.AnswerWaitTime / Call_Type_ Interval.CallsHandled |
Call_Type_Skill_Group_Interval |
Call_Type_Skill_Group_Interval AnswerWaitTime / Call_Type_Skill_Group_Interval.CallsAnswered |
Precision_Queue_Interval |
Skill_Group.AnswerWaitTime / Skill_Group_Interval.CallsAnswered |
エージェントおよびスキル グループの ASA
エージェント。 エージェントに対する ASA は、PG レベルで計算されます。
エージェントがコールに応答可能になると、この内部キューイング時間が Packaged CCE によって PG に送信されます。 PG は、内部キュー時間、呼び出し時間、およびネットワーク時間を合計し、これをエージェント スキル グループ テーブル内の AnswerWaitTime に追加します。 次に AnswerWaitTime は、エージェントの CallsAnswered で除算されます。
スキル グループ。 スキル グループに対する ASA は、PG レベルで計算されます。
次の例を検討してください。
- コールがスキル グループ X でキューイングされている。
- 時刻 T に、コールはその後時刻 T + 30 秒にスキル グループ Y でキューイングされる。
- スキル グループ Y でエージェントがコールに応答する前に、さらに 10 秒経過する。
この場合、内部キューイング時間は 40 秒になります。 これはコールがキューイングしていた合計時間ですが、コールがスキル グループ Y でキューイングしたのは 10 秒間だけです。
エージェントの PG は、内部キュー時間、呼び出し時間、ネットワーク時間を追加してコールの合計 AnswerWaitTime を作成し、これをスキル グループ テーブル内の AnswerWaitTime に追加します。 次に、AnswerWaitTime は、スキル グループの ASA を得るために Skill Group テーブル内の CallsAnswered で除算されます。
プレシジョン キュー。 ASA は、プレシジョン キューに関連した PG 間のスキル グループを合計して、プレシジョン キューに対して算出されます。
エージェントの ASA を示すレポート
エージェントおよびスキル グループの ASA 統計情報を示すレポートの一部は、次のとおりです。
コール タイプの serviceASA
コール タイプ ASA は、AnswerWaitTime を CallsAnswered で除算した値です。
コール タイプ ASA は、コールがトランスレーション ルーティングされ、エンタープライズ キューでの経過時間と ACD キューでの経過時間が含まれる場合のみ適用できます。
コール タイプの ASA を示すレポート
次のレポートには、ASA 統計情報が含まれます。
再クエリー
コールに応答しないエージェントにコールが送信された場合、Packaged CCE は再クエリーと呼ばれる方法を使用してコールを処理します。
再クエリーを使用すると、開始時からコールの監視が行われます。 コールがエージェントに送られ、戻され、別のエージェントにルーティングされた時間を含む、コール用のタイマーがあります。
再クエリー機能を使用するには、キュー ノードでターゲットの再クエリー設定を有効にします。 再クエリーの設定は、CVP および CUCM で設定される時間を使用して行われます。 コール タイプは変わらず、コールは同じスクリプトにとどまります。 再クエリー プロセス中、CVP はコールの制御を維持します。
次の手順は、一般的な再クエリー プロセスを示します。
再クエリーのベスト プラクティス
- ルーティング スクリプト内では、ターゲットの再クエリー オプションを有効にします。 ターゲットの再クエリーは、キュー、エージェント キューイング、プレシジョン キュー、ラベル、選択、およびルート選択の各ノードで使用できます。
- 新しいエージェントまたはスキル グループにリダイレクトされるまでに、コールが呼び出しを行う時間を決めます。 再クエリーされたコールがサービス レベルにどのように影響するかを考慮します。 つまり、サービス レベルのしきい値時間が CVP の再クエリー タイムアウトと正しく整合していることを確認します。
- 再クエリー状態用に別のコール タイプを作成するように計画します。 別のコール タイプを使用すると、再クエリーされたコール タイプのアクティビティに関してレポートできます。 このコール タイプのデータを表示すると、再クエリーされたコールの数を判断し、それらのコールが最終的にどのように処理されたかを確認できます。
- キュー ノードから再クエリーが発生した場合、スクリプト実行は、選択したエージェントに対応するノードのエラー経路を取ります。 スクリプトのキュー ノードのエラー経路で、コール タイプを変更します。
コール タイプ
この項では、コール タイプについて説明します。
コール タイプのレポート
サービスおよびコール タイプ レポートで提供される主な統計情報には、次が含まれます。
- 平均応答時間（ASA）
- 受信、処理、および放棄されたコールの数
- 発信者がキューで待機した時間
- 利用可能なエージェントにキューイングされたコール数
- サービス レベルの目的が一致しているかどうか
- 発信者が転送する必要があるかどうか
- ビジー信号を聞いた発信者の数
- エラーが発生したコール数
スキル グループおよびエージェント レポートは、ASA、平均 処理時間、放棄、リダイレクト、および処理されたコールなど、多くの同じメトリックを提供しますが、コール タイプ レポートはこれらのメトリックをカスタマー エクスペリエンスのさらに全体像を提供し、アプリケーション別に編成された統計情報の検討を支援する形式で表示します。
コール タイプ
コール タイプとは、受信コールのカテゴリです。 コール ルータは、コール タイプに基づいて、適切なエージェントにコールを最終的に送信するルーティング スクリプトを選択します。 コール タイプごとに、どのルーティング スクリプトを実行するかがスケジュールされています。
コール タイプは、最も高いレベルのレポート エンティティであり、Peripheral から独立しています。
コール タイプには、音声（電話）および音声以外（電子メールおよびテキスト チャットなど）の 2 種類があります。
- 音声コール タイプの場合は、まずダイヤル番号（DN）で分類されますが、さらに発呼者回線 ID（CLID）で分類することもできます。
- 音声以外のコール タイプの場合は、まずスクリプト タイプ セレクタでカテゴリ分けされますが、さらにアプリケーション文字列 1 およびアプリケーション文字列 2 で分類することもできます。
発信者が希望するサービスの種類に対応するコール タイプを作成し、スクリプトにおいてコール タイプを変更すると、カスタマー エクスペリエンスを反映したレポート統計情報になります。
（注） |
提供するコール処理ごとに別のコール タイプを設定すると、大半のカスタム レポートの必要性をなくすことができます。 |
コール タイプに関するベスト プラクティス
レポートのニーズを満たすために作成する必要があるコール タイプを考慮し、提供するコール処理のタイプごとに個別のコール タイプを設定します。
導入モデル、スクリプティング、キューイング、およびコールがトランスレーション ルーティングされるかどうかに基づいて、次のようにコール タイプを定義できます。
- 異なる Peripheral にルーティングされるコールの数やルーティング エラーが発生したコールの数など、コール センターのエンタープライズ ライドのルーティング統計情報を提供します。
- コンタクト センター内で発生したアクティビティの特定のタイプに関するレポートを作成するために、コールをグループ化することができます。 たとえば、応答がない場合にリダイレクトするコールまたは別のエージェントに転送されるコールに個別のコール タイプを作成する場合があります。
- セルフ サービス CVP アプリケーションの統計情報に関するレポートを作成します。
コールの転送および会議に関連付ける別のコール タイプを設定しますか。
設定すると、別のルーティング スクリプトで処理できます。
ネットワーク CVP セルフサービス アプリケーションまたは情報収集アプリケーション内の個々のトランザクションに関するレポート作成を計画しますか。
計画する場合は、トランザクションごとに別のコール タイプを設定します。
情報収集 CVP メトリックをキュー メトリックから分離しますか。
分離する場合は、キューイングに別のコール タイプを設定します。
RONA の状況に関連付けられる別のコール タイプを設定しますか。
設定すると、無応答のコールを、無応答時リダイレクト状態を処理するルーティング スクリプトに転送することができます。さらに、この無応答時リダイレクト コール タイプに関するレポートを作成して、無応答時にリダイレクトされたコールが最終的にどのように処理されたかを表示することもできます。
エージェント チームごとに、スーパーバイザ アシストおよび緊急支援スクリプトに関連付ける別のコール タイプを設定しますか。
設定すると、スーパーバイザおよびそのエージェントのチームのプライマリ スーパーバイザまたはセカンダリ スーパーバイザにリクエストを割り当てることができる緊急アシスト ルーティング スクリプトに、アシスタンス リクエストを転送することができます。 コール タイプ レポートを使用して、スーパーバイザ アシスタンス コールのデータを表示できます。
コール タイプのサービス レベルを決定しますか?
サービス レベルは、コールの応答目標がどの程度達成されたかを示しています。
コール タイプごとに個別のサービス レベルを設定することも、すべてのコール タイプを対象にしたグローバル サービス レベルを設定することもできます。
非常に短時間で放棄されたコールを放棄ショート コールからフィルタ処理で除外するように設定しますか?
放棄ショート コールを使用する場合は、放棄待機時間コール タイプを Configuration Manager で設定します。 放棄待機時間内に放棄されたコールがショート コールとしてレポートされます。
放棄ショート コールを使用しない場合は、[Abandon call wait time] フィールドを空白のままにしておきます。
そのコール タイプで、応答されたコールおよび放棄されたコールに関するレポートを作成する「バケット間隔」を定義しますか。
これらの「バケット間隔」は、各間隔で応答されたコール数と放棄されたコール数を表示するコール タイプ レポートに表示され、いつコールが放棄、または応答されているかをモニタするのに役立ちます。
コール タイプの変更
コール タイプは、コールを新しいルーティング スクリプトに転送する、またはさまざまな行程やトランザクションのレポート メトリックを収集するために、コールの存続期間中に変更される場合があります。
ルーティング スクリプト内でコール タイプを変更する理由には、次のものが含まれます。
- セルフサービス CVP スクリプトでは、トランザクションが完了したことを示すために、スクリプトの特定のポイントでコール タイプを変更する場合があります。 たとえば、顧客が銀行に電話を掛けていて、セルフサービス スクリプトを使用して自分の口座残高を正しく確認できた場合、口座残高のトランザクションが完了して新しいトランザクションが始まったことを示すために、コール タイプの変更が必要な場合があります。 この場合は、レポートが必要なトランザクションごとにコール タイプを作成します。
- 情報収集のメトリックとキューイングのメトリックを分けるために、情報収集 CVP スクリプトの最後にコールがキューに入れられた時点で、コール タイプを変更する場合があります。 この場合は、情報収集アプリケーションに関連付けられたコール タイプとキューイングに関連付けられたコール タイプを作成します。
コール タイプのサービス レベルのしきい値タイマーは、サービス レベルが定義されているコール タイプにコールが入った時点で開始します。 サービス レベル タイマーが経過すると、サービス レベルは、このコールに関連付けられている現在のコール タイプに適用されます。
コール タイプがスクリプト変更またはコール タイプ ノードを使用して変更されると、サービスしきい値タイマーはリセットされます。
サービス レベルは、キューイング ノードおよび LAA の選択ノードを使用するスクリプトに関連付けられているコール タイプに対してだけ定義します。
（注） |
コール タイプは次の要因に応じて変更されます。 |
コール タイプ レポーティング
コール タイプ レポートの使用は、エンタープライズでのビジネス ニーズに基づいており、Packaged CCE ソフトウェアによって提供される機能の使用をどのように計画するかによって決まります。
コール タイプ レポーティングは、Unified CC での完全なカスタマー エクスペリエンスを、Packaged CCE でのサービス レポーティングと同様に提供します。
コール タイプ レポートは次の目的で使用できます。
- エージェントが応答したコール
- CVP で放棄されたコール
- エージェントへのルーティング中またはエージェントの電話機が応答する前に放棄されたコール
- ショート コール
- ビジー、呼び出し、デフォルト ルーティング、またはネットワーク ルーティング処理が提供されるコール
- コール タイプまたはスクリプト変更ノードを使用して、ルーティング スクリプト内の別のコール タイプに移動したコール
- VRU へのルーティング中に放棄されたコール
- 無効なラベルを持つコール
- エージェントの電話機の無応答時に再ルーティングするコール
- ラベル ノードを使用してスクリプトを終了する、監視されていないデバイス（ボイス メールなど）へのコール
- コールがトランスレーション ルーティングされた際のコール処理統計情報の全コール期間のレポートの作成
- グローバルなコール処理の目的でグループ化されたコールに関するレポートの作成
- 異なる Peripheral へルーティングされるコール数、およびルーティング エラーが発生したコール数など、コール センターのエンタープライズ全体のルーティング統計情報の提供
- セルフ サービス CVP アプリケーション の統計情報のレポートの作成
- 転送されたコールなど、特定のアクティビティに関するレポートの作成（これらのアクティビティにコール タイプが設定されている場合）
- 提供されたコールのコール タイプに対する計算方法
- コール タイプ レポーティングに対するコール エラーの影響
- 無効なラベルを持つコールがコール タイプ レポーティングに与える影響
- CVP で無応答が発生したコールがコール タイプ レポーティングに与える影響
- ラベル ノードで終了して監視されていないデバイスにルーティングされるコールがレポートに与える影響
- コール タイプ レポート
提供されたコールのコール タイプに対する計算方法
コール タイプ レポーティングに対するコール エラーの影響
コール エラーによってデータベースがどのように増分されるかは、次の条件に依存します。
- CCE/CVP スクリプトへのルーティング中に放棄されたコールとは、VRU へ送信される途中にネットワーク内で放棄されたコールです。 たとえば、Communications Manager の CTI ルート ポイントから VRU への送信中にコールが放棄される場合があります。 これらのコールによって、Call_Type テーブルの [ErrorCount] カラムが増加します。 コール タイプに設定された放棄待機時間内に発信者がコールを放棄した場合、CVP へのルーティング中に放棄されたコールは、エラーではなくショート コールとしてカウントされます。 放棄されたショート コールの詳細については、次の項を参照してください。
- エージェントへのルーティング中に放棄されるコールとは、コールがエージェント デスクトップにあるときにエラーが発生したコールです。 このコールは、Call_Type テーブルの [AgentErrorCount] の一部としてカウントされます。
コール タイプ レポートの [Calls Error] フィールドは、両方のエラー カラムが結合された算出フィールドです。 5o\ たとえば、コールタイプ - 履歴全フィールド レポートの [Calls Error] フィールドは、Call_Type_Interval.IncompleteCalls + Call_Type_Interval.AgentErrorCount で導出されます。
無効なラベルを持つコールがコール タイプ レポーティングに与える影響
無効なラベルとは、設定が誤っているラベルまたは見つからないラベルのことです。 これには、デフォルト ラベルを定義するのが有効です。デフォルト ラベルを定義すると、設定が誤っているラベルに遭遇したコールが、少なくともデフォルト ラベルまで移動でき、コール タイプ レポートで計算および処理されるようになります。
ラベルの設定が誤っている原因は次のものが考えられます。
- スクリプト ノードで指定されたラベルがルーティング クライアント上に存在しない。この場合、スクリプト ノードで指定されたラベルがルーティング クライアントに存在していない可能性があります。
- ラベルが不正なエージェントを指している。この場合、コール前のメッセージはあるエージェントに送信されますが、実際のコールは別のエージェントに送信されます。 このコールは、不完全なコールとしてレポートされます。
ノードでラベルが定義されていない場合は、コールのエラー条件が発生し、エラーとしてレポートされます。
CVP で無応答が発生したコールがコール タイプ レポーティングに与える影響
CVP 無応答コールの数は、エージェント レポートおよびスキル グループ レポートで表示できます。
CVP 無応答機能により、エージェントがコールに応答しない場合は、指定された秒数の後、コールがエージェントから切断され、別のエージェントに再割り当てされるか、再キューイングされます。 無応答は、コールがエージェントの電話から再ルーティングされたときに、エージェント状態を待受停止に変更する場合にも使用されます。 CVP 無応答機能により、エージェントはルーティング要求に対して応答不可になります。 Packaged CCE CVP の無応答タイムアウトを超過すると、コールは別のスキル グループまたはエージェントにルーティングするために再キューイングされます。
（注） |
セントラル コントローラは、CVP からの応答を最大 30 秒間待ちます。したがって、CVP の無応答タイムアウトは 30 秒未満にする必要があります。 30 秒以内に応答が受信されない場合、コールは失敗します。 |
無応答の状況を処理するルーティング スクリプトは 2 通りの方法で設定できます。つまり、コールが再クエリーされた場合にスクリプトのコール タイプを変更するか、あるいはスクリプトで同じコール タイプを使用し続けるかを指定できます。
無応答に関するスクリプトの内容は、表示されるレポート データに次のような影響を与えます。
- コール タイプを変更する場合、CallsOffered、CallsRequeried および OverflowOut が最初のコール タイプに対して更新されます。 CallsOffered およびコールの完了に関連するフィールド（[CallsHandled] など）は、2 番目のコール タイプに対して増加します。 2 つのコール タイプを使用すると、コール タイプ レポートで無応答の発生を識別できます。 たとえば、無応答の状況で使用する特定のコール タイプを作成すると、そのコール タイプに提供されたコールを監視することで、コールがリダイレクトされているかどうかを確認できます。 また、他のコール タイプに対して [フロー発信（Flow Out）] フィールドが増加しているかどうかも確認できます。
- コール タイプを変更しない場合、CallsOffered およびコールの完了に関連するフィールド（[CallsHandled] など）が増加します。 [フロー発信（Flow Out）] は増加しません。 エージェント レポートまたはスキル グループ レポートを表示しない場合は、コールが応答なしでリダイレクトされているかどうかがわかりません （カスタム レポートを書けば CallsRequeried の値を表示できます）。
（注） |
Unified CVP アプリケーションは再クエリーを実行し、別のスクリプトへの分岐を行わずに他のエージェントまたはスキル グループにコールをリダイレクトするため、コール タイプの [CallsRONA] フィールドは増加しません。 |
ラベル ノードで終了して監視されていないデバイスにルーティングされるコールがレポートに与える影響
ラベル ノードは、音声メールまたは Web コンソール担当者にコールを転送するときに使用します。また、音声メニュー中に発信者によってダイヤルされる番号またはその他の条件が原因で、Unified ICM/CC によって監視されていない他のデバイスにコールを転送するときにも使用します。 これらのコールは RoutedNonAgent としてカウントされ、コール タイプ レポートの [その他（Other）] カラムに表示されます。
コール タイプ レポート
次のレポートには、コール タイプに関するデータが表示されます。
コールに関するレポーティング
バケット間隔
バケット インターバルを指定すると、特定の時間増分（0 ～ 8 秒、60 秒未満など）内の放棄呼または応答呼のデータを追跡できます。
バケット間隔は次のものに関連付けられます。
これらはシステム全体に対して、および個々のコール タイプに対して設定できます。 ローカル設定がシステム レベルの設定に優先します。
サービス レベルでは、何パーセントのコールが特定の時間内に応答されたかがわかりますが、サービス レベルのどれくらい近くで、コールが応答または放棄されたかはわかりません。 バケットの間隔では、コールが応答されるまでに、または放棄されるまでに、発信者がどれくらい待っているかも把握できます。
たとえば、サービス レベルが 2 分の場合に、間隔を 30 秒、1 分、90 秒、120 秒、180 秒、210 秒、および 240 秒に設定したとします。 これらのインターバルを使用すれば、コールが 180 秒のサービス レベルしきい値の 30 秒後までに応答されたのか、ほとんどの人が応答されるまでにさらに 1 分長く待っているのかがわかります。
この間隔は、発信者が放棄するまでにどれぐらい待とうという意志があるかについての洞察も得られます。 たとえば、サービス レベルを 2 分過ぎるまでは、発信者の多くはコールを放棄しないとします。 この場合は、サービス レベルの目標を変更できることが示されている可能性があります。
レポートの不一致を回避するには、特定の時間境界（つまり、1 日、週、または月の終わり）でのみバケット間隔設定を変更します。 時間境界を変更するときには、変更するインターバルに対してレポートを実行しているユーザがいないことを確認してください。
Packaged CCE には、1 つのシステム デフォルト バケット間隔があります。この間隔の境界（増分）は、8、30、60、90、120、180、300、600、および 1,200（秒）です。
バケット間隔レポート
バケット間隔データを示すレポートは、次のとおりです。
サービス レベル
サービス レベルは、コールへの応答に関する目標を設定し、評価する際に役立ちます。 サービス レベルは設定可能です。必要な情報の種類に応じて、異なる方法で定義できます。
サービス レベルについて
指定された期間内にサービス レベル イベントを持つすべてのコールは、その期間に提供されたサービス レベル コールであると見なされます。 これは、サービスに最初に提供された時に各コールをカウントする、コールに提供された値とは異なることを示しています。
（注） |
サービス レベルは、サービス レベル時間内に応答も放棄もされていないコールの影響は受けません。 たとえば、サービス レベルのしきい値内でエラー条件が発生したコール、または監視されていないデバイスに（ラベル ノードを使用して）送信されたコールは、サービス レベルに影響を与えません。 |
サービス レベルの計算では、次の 2 つの設定パラメータが重要です。
- サービス レベルしきい値（Service Level Threshold）
- サービス レベル タイプ（Service Level Type）
- コール タイプのサービス レベル
- スキル グループのサービス レベル
- サービス レベルのベスト プラクティス
サービス レベルしきい値（Service Level Threshold）
サービス レベルしきい値は、コールとエージェントを接続する場合の目標として設定する秒数単位の値です。
たとえば、コールの 80% を 2 分以内に応答するという目標を立てたとします。 この場合、サービス レベルしきい値を 120 秒に設定します。 レポートには、しきい値の時間内に応答されたコールのパーセンテージが表示されるため、目標を達成しているかどうかが確認できます。
サービス レベルしきい値を 0 秒に設定すると、コールにサービス レベル イベントが設定されず、コールはサービス レベル コールとして処理されません。
サービス レベル タイプ（Service Level Type）
サービス レベルのタイプによって、サービス レベルのしきい値よりも前に放棄されたコールがサービス レベル計算に与える影響が決まります。
サービス レベル タイプは、Configuration Manager で 3 つのオプション（プラス、マイナス、またはまったく影響なし）として示されます。
- 放棄呼が、プラスの影響を与える計算方法 一部のコンタクト センターでは、放棄呼がサービス レベルにプラスの影響を与えるようにする必要があります。 これらのコンタクト センターでは、サービス レベルしきい値の時間内に放棄されたコールは処理済みコールと見なされます。 放棄呼は、サービス レベルにプラスの影響を与えると見なされます。
- 放棄呼が、マイナスの影響を与える計算方法 他のコンタクト センターでは、サービス レベルのしきい値時間内に応答されたコールだけが処理済みコールと見なされます。 これらのコンタクト センターでは、サービス レベル時間内に放棄されたコールによってサービス レベルに悪い影響が出ます。 放棄呼は、サービス レベルにマイナスの影響を与えます。
- 放棄呼の無視 他のコンタクト センターでは、サービス レベルの計算から放棄呼が除外される場合があります（放棄呼を無視する計算方法）。
サービス レベルの計算は、サービス レベル設定に定義されたサービス レベル タイプに基づきます。 これらについては、次の表で説明します。
サービス レベル タイプ（Service level type） |
サービス レベルを決定するために使用される数式 |
|---|---|
放棄呼の無視 |
コール タイプおよびサービスに対して：ServiceLevelCalls/（ServiceLevelCallsOffered – ServiceLevelAband） |
放棄呼へのマイナスの影響 |
コール タイプおよびサービスに対して：ServiceLevelCalls/（ServiceLevelCallsOffered） |
放棄呼へのプラスの影響 |
コール タイプとサービスに対して：（ServiceLevelCalls + ServiceLevelAband）/（ServiceLevelCallsOffered） |
サービス レベル タイプの計算方法の例については、次のコール数を考慮してください。
- サービス レベルしきい値（ServiceLevelCalls）内に応答 = 70 コール
- サービス レベルしきい値（ServiceLevelAband）内に放棄 = 10 コール
- 超過サービス レベルしきい値（ServiceLevelCallsOffered –（ServiceLevelCalls + ServiceLevelAband））= 20 コール
- 合計サービス レベル イベント（ServiceLevelCallsOffered）= 100 コール
これらのコール数では、次のように、各タイプに対してサービス レベルが計算されます。
このサービス レベル タイプの場合： |
サービス レベル計算： |
|---|---|
放棄呼を無視する計算方法 |
70/（100 - 10）= 77% |
放棄呼が、マイナスの影響を与える計算方法 |
70/100 = 70% |
放棄呼が、プラスの影響を与える計算方法 |
（70 + 10）/100 = 80% |
放棄呼を追跡しない場合は、[放棄待機時間（Abandon Wait Time）] フィールドを空白のままにします。
コール タイプのサービス レベル
カスタマー エクスペリエンスを全体的に測定するためにコール タイプを使用すると、コール処理全体と発信者によるシステムの使用状況について深く理解できるようになります。
コール タイプのサービス レベルのしきい値タイマーは、サービス レベルが定義されているコール タイプにコールが入った時点で開始します。 サービス レベル タイマーが経過すると、サービス レベルは、このコールに関連付けられている現在のコール タイプに適用されます。
キューイングノードを使用するスクリプトに関連付けられているコール タイプだけが、サービス レベルを定義します。 コール タイプがスクリプト変更またはコール タイプ ノードを使用して変更されると、サービスしきい値タイマーはリセットされます。
このコール タイプに対して発生する可能性があるサービス レベル イベントは、次の 4 つです。
- サービス レベルのしきい値が経過する前に、エージェントがコールに応答します。 この場合、ServiceLevelsCallsOffered および ServiceLevelCalls データベース フィールドが増加します。
- サービス レベルのしきい値が経過する前に、CVP またはエージェントの電話でコールが放棄された場合。 この場合、ServiceLevelCallsOffered および ServiceLevelAband データベース フィールドが増加します。
- サービス レベルのしきい値が経過する前に応答されなかったため、コールがリダイレクトされた場合。 この場合、[ServiceLevelCallsOffered] データベース フィールドの値が増加します。
- サービス レベルのしきい値タイマーが経過した場合。 例：コールがエージェントによって応答、または放棄されないまま、サービス レベルのしきい値に達しました。 この場合、ServiceLevelCallsOffered データベース フィールドが増加します。
サービス レベルしきい値が経過する前にコールにエラーが発生した場合、[ServiceLevelError] データベース フィールドの値は増加しますが、[ServiceLevelOffered] の値は増加しません。 サービス レベルしきい値が経過した後にコールにエラーが発生した場合は、[ServiceLevelOffered] の値が増加します。
サービス レベル計算からエラーを除外するには、次の手順を実行します。
スキル グループのサービス レベル
スキル グループ レベルでは、エージェントおよびスキル グループ パフォーマンスを監視する場合にサービス レベル メトリックが役に立ちます。 スキル グループのサービス レベルのしきい値タイマーは、コールがスキル グループにキューイングされた時点で開始されます。
プレシジョン キューを使用してスキル グループを拡張または置換できます。 プレシジョン キューの詳細については、「Create Precision Queue」を参照してください。
（注） |
デフォルトでは、スキル グループのサービス レベルしきい値は、エージェント Peripheral のデフォルト値に設定されます。 |
このスキル グループに対して発生する可能性があるサービス レベル イベントは、次の 5 つです。
- サービス レベルのしきい値が経過する前に、エージェントがコールに応答します。 この場合、コールに応答したスキル グループの [ServiceLevelsCallsOffered] および [ServiceLevelCalls] データベース フィールドの値が増加します。 コールが複数のスキル グループにキューイングされた場合は、他のスキル グループに対する [ServiceLevelsCallsOffered] および [ServiceLevelCallsDequeued] データベース フィールドの値が増加します。
- サービス レベルしきい値が経過する前に、スキル グループからコールがキューイング解除されます。 この場合、ServiceLevelsCallsOffered および ServiceLevelCallsDequeued データベース フィールドが増加します。 コールは、別のスキル グループにルーティングされるスキル グループからキューイング解除される場合に、キャンセル キュー ノードを使用してキューイング解除されることがあります。
- サービス レベルのしきい値が経過する前に、VRU（キュー）またはエージェントの電話でコールが放棄された場合。 この場合、ServiceLevelCallsOffered および ServiceLevelAband データベース フィールドが増加します。
- サービス レベルのしきい値が経過する前に応答されなかったため、コールがリダイレクトされた場合。 この場合、ServiceLevelCallsOffered データベース フィールドが増加します。
- サービス レベルのしきい値タイマーが経過した場合。 例：コールがエージェントによって応答、または放棄されないまま、サービス レベルのしきい値に達しました。 この場合、ServiceLevelCallsOffered データベース フィールドが増加します。
使用するスクリプティングによってはコールを複数のスキル グループにキューイングできるため、1 つのコールがキューイングされたそれぞれのスキル グループのサービス レベル メトリックが更新されます。
そのような場合に、サービス レベルにどのような影響があるかを理解することが重要です。
- コールが複数のスキル グループにキューイングされ、サービス レベルしきい値が経過する前に応答された場合は、コールに応答したスキル グループの [ServiceLevelsCallsOffered] および [ServiceLevelCalls] データベース フィールドの値が増加します。 他のスキル グループでは、[ServiceLevelsCallsOffered] および [ServiceLevelCallsDequeued] データベース フィールドの値が増加します。
- コールが複数のスキル グループにキューイングされ、サービス レベルしきい値が経過する前にキュー内で放棄された場合は、すべてのスキル グループの [ServiceLevelsCallsOffered] および [ServiceLevelCallsAband] データベース フィールドの値が増加します。 この結果によりすべてのスキル グループのサービス レベルにマイナスまたはプラスのどちらの影響が出るかは、個々のスキル グループの設定でのサービス レベルの計算で放棄呼をどのように処理するかに基づきます。
- コールが複数のスキル グループにキューイングされ、サービス レベルしきい値が経過した後にキュー内で放棄された場合は、すべてのスキル グループの [ServiceLevelsCallsOffered] データベース フィールドの値が増加します。 この結果、サービス レベルにマイナスの影響が出ます。
- コールが複数のスキル グループにキューイングされ、スキル グループにルーティングされてから（例：エージェントを呼び出す場合に放棄する）、サービス レベルしきい値が経過するまでにコールを放棄する場合は、放棄されたスキル グループに対して [ServiceLevelCallsOffered] および [ServiceLevelCallsAband] データベース フィールドの値が増加し、他のスキル グループで [ServiceLevelCallsOffered] および [ServiceLevelCallsDequeued] データベース フィールドの値が増加します。
ServiceLevelCallsOffered からエラーを削除する場合は、カスタム レポートで ServiceLevelCallsOffered –（Errors – SLErrors）という数式を使用できます。
サービス レベルのベスト プラクティス
サービス レベルの設定およびスクリプティングを行う場合は、次のガイドラインを考慮してください。
- サービス レベル時間は、コールがコール タイプに入った時点で開始されます。 コールがスキル グループにキューイングされる時点でサービス レベル時間が開始されるように、キューおよびエージェントの統計の収集に使用するコール タイプ スクリプトを設定します。 サービス レベルは、スキル グループ キューイング ノードを含むスクリプトを指しているコール タイプに対してだけ定義します。
- 1 つのコール タイプ（つまり、コール タイプのマッピングを使用してスクリプトに対して指定された最初のコール タイプ）を、キューより先に統計情報を収集するように設定します。
- キューおよびエージェントの統計の収集に使用される他のコール タイプを設定します。
- ルーティング スクリプトで、キューイング情報の収集に使用されるコール タイプにコールを送信するために、スクリプト変更またはコール タイプ ノードを含めます。
- スキル グループ/プレシジョン キューおよびサービス レベル メトリックは、1 つのコールがキューイングされるそれぞれのスキル グループ/プレシジョン キューで更新されます。 そのようなケースでは、コールがサービス レベルしきい値の内外で放棄された場合に、サービス レベルにマイナスの影響を与える場合があります。 サービス レベルの計算に放棄呼を含める場合に、放棄呼がサービス レベルにマイナスの影響を与えないようにする必要がある場合は、1 つのスキル グループ/プレシジョン キューにキューイングすることを検討してください。
これらのガイドラインに従った場合、最初のコール タイプ（コールの最初のマップ先）によって、コールがスキル グループにキューイングされる前に統計が収集されます。 その後、スクリプトによって、スキル グループ/プレシジョン キューにコールがキューイングされた後で情報を収集するように設定されたコール タイプにコールが渡されます。
サービス レベル関係：MRD、スキル グループ、およびプレシジョン キュー
MRD、スキル グループ、およびプレシジョン キューのサービス レベル設定は、階層形式であり、次のように解釈されます。
MRD は最大レベルです。 MRD のデフォルト設定値は Service level threshold = 30 seconds と Service level type = Ignore Abandoned Calls です。 Ignore Abandoned Calls は唯一の値であり、保護されます。 スキル グループとプレシジョン キューは、明示的に設定されていない限り、MRD から値を継承します。 スキル グループとプレシジョン キューのデフォルト設定は MRD から取得されますが、上書きできます。
ショート コール、放棄呼、およびオーバーフロー コール
この項では、ショート コール、放棄呼、およびオーバーフロー コールについて説明します。
ショート コール
ショート コールとは、すぐに放棄されたコールまたは応答後すぐに切断されたコールのことです。 ショート コールを定義することによって、システムに留まっていた時間が短すぎるためイベントとは見なされないコールをレポート メトリックから除外できます。
破棄呼の待ち時間タイマーは、放棄呼がカウントされないしきい値を定義します。 放棄しきい値がサービス レベルしきい値よりも小さい場合、コールによってサービス レベルは影響を受けません。 コール待機時間がこのしきい値よりも大きい場合、コールは提供済みとしてカウントされます。
応答ショート コールしきい値は、コールが応答済みとしてカウントされず、エージェント パフォーマンスに影響を与えない時間を定義します。
ショート コールを使用して False の放棄をフィルタで除外する場合、またはコールの応答および終了が早すぎて処理済みと見なされないことを検出する場合は、次のことを考慮してください。
- Peripheral に対して放棄ショート コールを設定できます。 これらのコールは、その Peripheral に設定されたサービスに対して追跡されます。
- どれだけ早く放棄するかに関係なく、すべての放棄呼をショート コールとしてカウントしないことを選択できます。
- 放棄呼がどのようにサービス レベルに影響を与えるか（マイナス、プラス、またはまったく影響なし）を選択できます。
- コール タイプに対して応答ショート コールを設定することはできません。
- どれだけ早く終了するかに関係なく、すべての応答コールをショート コールとしてカウントしないことを選択できます。
（注） |
ショート コールのコンセプトは、音声メディア クラスにのみ適用されます。 |
これらのショート コール機能にアクセスするには、次の項を参照してください。
ショート コールをフィルタおよび検出デバイスとして使用
次の一般的な手順を実行します。
- AW（DataServer）にアクセスします。
- [Configuration Manager] > [ツール（Tools）] > [エクスプローラ ツール（Explorer Tools）] > [PG Explorer] を選択します。
- [取得（Retrieve）] をクリックします。
- [汎用 PG（Generic PG）] を展開します。
- [CUCM_PG] # をクリックします。
画面の右側に、タグのグループがあります。
放棄ショート コール
放棄呼待機時間しきい値に対して設定された値より後で放棄呼は、放棄されたと見なされます。 これはグローバルな設定です。
放棄呼待機時間しきい値よりも前に放棄されたコールは、ショート コールとしてレポートされます。
放棄ショート コールによって、[CallsOffered] フィールドは変更されますが、[CallsAbandon] フィールドは変更されないため、レポートに影響を与えます。
応答ショート コール
電話に応答するエージェントが不在の場合、発呼者がすぐに電話を切ると応答ショート コールが反映されます。
応答ショート コールは、スキル グループおよびエージェント スキル グループに対してレポートされます。
ショート コール タイマーは、エージェントがコールに応答した時点で開始し、CallsAnswered メトリックはこれらのコールに対して更新されます。
通話時間が Peripheral に設定された応答ショート コールしきい値よりも短い場合は、Skill_Group_Interval および Agent_Skill_Group_Interval テーブル内の [ShortCalls] フィールが増加します。 そのコールは、処理コールとショート コールの両方としてレポートされます。
エージェントに対して自動応答が有効になっている場合で、一定期間内に多数のショート コールがある場合は、ショート コールでのレポートを使用することで、コールが自動応答されたときに端末の前にいなかったエージェントを特定できます。 これは、エージェントが不在の場合は、発信者がすぐに電話を切るものと想定しています。
ショート コール レポート
複数の全フィールド レポートには、提供されたが、処理および放棄されないコールを追跡できるようにする [ショート タスク（Short Tasks）] カラムが含まれます。
次のレポートは、ショート コールに関する動作情報を示します。
放棄呼
エージェントに接続される前に発信者が切断した場合、コールは放棄されたものと見なされます。 これには、CVPでキューイングされたまたは待機している間に発信者が電話を切った場合が含まれます。 放棄呼の数が多い場合、発信者がキューで長い間待たされていることを示している可能性があります。
サービス レポートには、すべての放棄呼の累積統計が示されます。 コール タイプ レポートには、コールが放棄された場所についての追加情報が表示されます。
（注） |
放棄呼待機時間しきい値よりも前に放棄されたコールは、ショート コールと見なされます。 たとえば、放棄呼待機時間を 10 秒に設定し、発信者が 9 秒で切断した場合、そのコールはショート コールと見なされ、受信や放棄とは見なされません。 |
放棄呼待機時間を設定するには、[xyz] 画面で [Peripheral] タブにアクセスします。 この手順に関する詳細については、ショート コールを参照してください。
放棄呼によるレポーティングへの影響
放棄のメトリックには、VRU（プロンプトまたはセルフサービス）での放棄、キューでの放棄、およびエージェントでの放棄の 3 つのタイプがあります。
Packaged CCE/CC では、これらの放棄タイプごとの放棄カウントが別々に追跡されます。 また、これらの放棄呼が放棄される前に経過した時間もトラッキングされます。
コール タイプ レポートの [放棄（Aban）] カラムに表示される値には、そのコール タイプの合計放棄カウントが示されており、それには VRU（プロンプトまたはセルフ サービス）で放棄されたコール、キューで放棄されたコール、およびエージェントの電話の呼び出しやエージェントの電話への転送中に放棄されたコールが含まれています。 この値は、[TotalCallsAband] データベース フィールドから取得されています。
レポートの [放棄平均遅延時間（Avg Aban Delay Time）] フィールドには、これらの放棄呼で経過した平均時間も表示されます。 このフィールドは、現在の間隔内にこのコール タイプで終了したすべての放棄呼の平均遅延時間を表しています。 この値は、Call_Type_Interval.CallDelayAbandTime/Call_Type_Interval.TotalCallsAband から取得されています。
情報収集とキューイングの統計情報を分割するために、コールが放棄されたコール タイプだけでコールの経過時間を計測することもできます。 この値は、CTDelayTotalAbanTime データベース フィールドで追跡されています。 このフィールドに含まれるのは、すべてのコール タイプではなく、コールが放棄されたコール タイプで経過した時間だけです。
次の例を検討してください。
- あるコールでは、「Info_Call_Type」という情報収集コール タイプで 30 秒が経過しています。
- 次に、たとえば、Queue_Call_Type というキューイング コール タイプにコール タイプがスクリプトによって変更されて、コールがキューイングされます。
- キューで 15 秒待った後、コールが放棄されます。
この場合、コールが放棄されるまでのコールの経過時間の合計は 45 秒になります。 ただし、コールが放棄された「Queue_Call_Type」におけるコールの経過時間は 15 秒です。 「Queue_Call_Type」のコール タイプの統計は次のように更新されます。
Queue_Call_Type
（注） |
カスタム レポートを書けば、さまざまな放棄呼やそれらの放棄呼の経過時間に関するレポーティングを行えます。 スクリプト内または VRU（プロンプトまたはセルフ サービス）にあるコールに対して、放棄呼に関連するカウントや時間を測定するには、放棄呼の合計からエージェントでの放棄とキューでの放棄を減算します。 |
放棄ショート コールによるレポーティングへの影響
コール タイプのショート コールとは、そのコール タイプの放棄待機時間しきい値内で放棄されたコールのことです。 ショート コールを定義することによって、システムに留まっていた時間が短すぎるため通常のコールとは見なされないコールを除外できます。 ショート コールは、コール タイプおよびサービスに対して定義できます。
（注） |
ショート コールは、すべてのコール タイプに対してグローバルに設定されます。 |
ショート コール タイマーは、コールに対してルート リクエストが受信された時点で開始します。 [CallsOffered] フィールドは、ルート リクエストが受信されると更新されます。 コールが放棄待機時間しきい値内で放棄された場合、[ShortCalls] フィールドは更新されますが、放棄呼数は更新されません。 コール タイプは最も高いレベルのレポート エンティティであるため、VRU またはエージェントの電話において放棄されたコールは、コール タイプの放棄待機時間しきい値内で放棄された場合には、コール タイプにおいて放棄されたショート コールと見なすこともできます。
放棄されるまでの時間に関係なく、すべての放棄呼をショート コールとしてカウントしないようにするには、コール タイプの [放棄呼待機時間（Abandon call wait time）] フィールドをブランクにしておくことで、放棄ショート コールを無効にできます。
放棄呼レポート
次のレポートは、コール タイプとサービスに関する放棄統計情報を示します。
転送および会議
音声コールは、転送または会議が可能です。 電子メール、チャット、およびブレンディッド コラボレーション タスクなどの音声以外のタスクは転送および会議はできません。
転送はブラインドです。 ブラインド転送では、エージェントは別のエージェントが対応可能かどうかを先に確認せずに、別のエージェントにコールを転送します。
転送および会議について
Packaged CCE は、エージェントおよびスキル グループへの直接の転送および会議をサポートしています。
転送と会議からの正確で役立つデータを得るために、次のガイドラインに従ってください。
- 関連するルート ポイントが指定されたダイヤル番号を、エージェントおよびスキル グループへの転送と会議用に設定します。
- 設定したダイヤル番号を使用して転送する場合には、別のスクリプトを作成するように計画してください。 最初のスクリプトで、コールを転送する際などにコール タイプを変更します。コールは転送スクリプトに送信されます。 別のスクリプトを準備すると、エージェントのデフォルトのスキル グループではなく、複数のコール タイプやスキル グループにまたがってデータをトラッキングできます。
- エージェントは、手動でコールを別のエージェントに転送を、または ACD 上でエージェントの内線を直接ダイヤルして別のエージェントで会議を行うことができます。
-
エージェントは、ACD 番号を使用して ACD 上のルーティング スクリプトにアクセスできます。また、オプションで、コールをPackaged CCE にポストルーティングすることができます。 後者の方法を推奨しますが、これは、Packaged CCE は転送されたコールおよびエンタープライズ間でどのように処理されるかを追跡できないためです。 また、コールを別の ACD サイトに転送する機能もあります。 直接エージェント転送を阻止することを推奨しますが、これは、レポートの目的では、スキル グループおよびサービス割り当てのために ACD に依存する必要があるためです。 ACD 自体で転送および会議を処理している場合は、ACD 番号を転送のレポート方法の制御に使用します。
（注）
エージェント拡張が設定されていない場合、Packaged CCE は、直接転送を認識しません。
ポストルーティングを使用したコールの転送および会議の提供を計画する場合は、正確で役立つデータを得るために、次のガイドラインに従ってください。
転送および会議に関する設定とスクリプティング
スキル グループへの転送および会議についての設定とスクリプティングを行う場合は、次のガイドラインに従ってください。
ダイヤル番号を設定します。
新しいコール タイプを作成するか、既存のコール タイプを識別して、コール タイプをダイヤル番号に関連付けます。
スキルグループ キューイング ノードを含むスキル グループに転送するためのルーティング スクリプトを作成します。 このスクリプトにより、転送コールおよび会議コールが正しいスキル グループにキューイングされます。
コール タイプをルーティング スクリプトに関連付けます。
動作レポート
動作レポートには、トランスレーション ルート、トランク、およびトランク グループに関するレポートが含まれます。
トランクおよびトランク グループ
すべての Peripheral には、1 つ以上の関連付けられたトランク グループがあり、それぞれのトランク グループには 1 つ以上の物理トランクが含まれています。
サービス中のトランク数、アイドル状態のトランク数、およびトランク グループ内のすべてのトランクが同時にビジーになっていた時間（全トランク使用中）などのデータに関してレポートすることができます。
次のレポートには、トランク グループに関する動作情報が含まれます。
IVR/VRU セルフサービス
この項では、音声自動応答装置（IVR）用の Customer Voice Portal（CVP）を使用したセルフ サービスについて説明します。
CVP について
CVP（音声応答装置）は、対話式音声自動応答装置（IVR）とも呼ばれ、録音されたアナウンスを再生して、タッチトーンの発信者入力番号に応答するテレコミュニケーション デバイスです。 CVP には、自動音声認識（ASR）または音声合成（TTS）機能を備えているものもあります。
Packaged CCE の用語では、CVP は、Peripheral に対応し、PG を使用して統合されます。
CVP での使用
エンタープライズには、初期コール処理およびエンタープライズ キューイングを提供する、1 種類以上の CVP アプリケーションが実装されている場合があります。
- セルフサービス アプリケーションの場合、顧客は CVP の一連のプロンプトを通じて情報を入手でき、すべてのトランザクションは CVP 内で行われます。 たとえば、顧客が銀行に電話をした場合、セルフサービス アプリケーションによって口座番号とパスワードの入力が求められた後に、口座残高の確認、最近の支払いの確認、および PIN 番号の変更などが可能になります。
- 情報収集アプリケーションの場合は、どの部署につなぐかなどの特定の情報を入力するよう CVP から発信者に求められた後、その情報を使用してルーティングが決定され、その情報がエージェントのデスクトップに渡されます。
- CVP は、顧客が応答可能なエージェントを待っている間にコールをエンタープライズ キューイングするためにも使用されます。 キューイング中には、保留中の音楽を再生したり、CVP アプリケーションを実行したりするように、CVP を設定する場合もあります。
CVP アプリケーション レポート
CVP は、キューイング、顧客のセルフサービス、情報収集など、さまざまな目的で使用できます。
- CVP のタイプがレポート データに与える影響
- セルフサービス、情報収集、およびキューイング CVP アプリケーション
- セルフサービス アプリケーションおよび情報収集アプリケーションの進行状況の監視
- VRUProgress 変数
- VRU メトリックを示すレポート
CVP のタイプがレポート データに与える影響
企業内で使用する CVP アプリケーションのタイプによって、監視すべきレポート データが決まります。
次に例を示します。
セルフサービス、情報収集、およびキューイング CVP アプリケーション
情報収集 CVP アプリケーションは、音声案内での発信者の入力に基づいて、コールをキューイングするスキル グループを決定するために使用されます。 発信者入力番号（CED）がルーティング スクリプト内で使用される CVP から返されて、コールに応答する最適なスキル グループを決定します。
情報収集に使用される IVR サービスから、次のことを判定できる必要があります。
コールがキューイングされる前に IVR 処理がある場合、ベスト プラクティスはキュー ノードの直前にコール タイプを変更することです。 コール タイプを変更すると、サービス レベル タイマーがリセットされ、IVR 時間が除外されます。 スキル グループ キューイング ノードの前にコール タイプを変更しない場合は、IVR 処理時間がサービス レベルの計算に含まれ、サービス レベルにマイナスの影響が出ます。次の図を参照してください。
次の図では、コールがどのように情報収集アプリケーションからキューイング アプリケーションへ移動するかを示します。
この例では、ASA を計算し、サービス レベルを決定するために、50 秒（30 + 20 秒）ではなく、20 秒が使用されます。
（注） |
キューイングを処理するコール タイプに対するスクリプト変更を行う前にコールが放棄される場合、コール放棄待機時間はリセットされません。 したがって、情報収集コール タイプの放棄待機時間は、次の図で示すように、コールが最初のコール タイプに入った時点で開始し、コールが放棄された時点で終了します。 |
次の表は、一部の基本メトリックがコール タイプと IVR サービスでどのように定義されるかを示しています。
| レポート メトリック |
コール タイプ |
VRU サービス |
スキル グループ |
|---|---|---|---|
| 放棄待機時間 |
コールが最初にコール タイプに入った時点で開始し、放棄された時点で終了します。 |
コールがサービスに入った時点で開始します。 |
該当なし |
| 平均応答時間（ASA） |
ルーティング スクリプト内の最初のスキルグループ キューイング ノードで開始します。 |
ルーティング スクリプト内の最初のスキルグループ キューイング ノードで開始します。 |
ルーティング スクリプト内の最初のスキルグループ キューイング ノードで開始します。 |
| サービス レベル |
サービス レベルが定義されているコール タイプにコールが入った時点で開始します。 |
コールがサービスに入った時点で開始します。 |
該当なし |
セルフサービス アプリケーションおよび情報収集アプリケーションの進行状況の監視
セルフサービス アプリケーションの効果を判定する方法は複数あります。
- アプリケーション全体の効果を監視する。 たとえば、CVP アプリケーションを通じて顧客のニーズが満たされたかどうか、発信者をエージェントに転送する必要がなかったかどうかだけを監視する場合です。
- アプリケーション内の個々のトランザクションの効果を監視する。 たとえば銀行取引サービスのアプリケーションで、顧客が複数のトランザクション（口座の参照、残高情報の取得、最近の支払いについての確認など）を実行できる場合です。 どのトランザクションが使用されたか、また発信者がトランザクションを正常に完了したかどうかを確認することができます。
- データベース参照の失敗などのシステム エラーが発生したために、発信者が CVP アプリケーションを続行せずにエージェントによって転送された失敗事例を監視する。
同様に、情報収集アプリケーションの効果を判定する方法も複数あります。
VRUProgress 変数
レポートでアプリケーション特有の用語を使用して、アプリケーション特有のイベントを説明する必要があるので、 CVP アプリケーションは、コール センターのアプリケーションの間で一意です。 そのようなレポートは、顧客から別の顧客へ、また VRU アプリケーションから別の VRU アプリケーションへ広範にわたって変化します。 一部の顧客は、いくつの CVP コールが、 CVP アプリケーションによって問題なく処理されたかを知るだけで十分ですが、他の顧客は、 CVP アプリケーション内の特定のトランザクションの使用率および成功率を追跡します。 特定の発信者により実行される実際の一連のアクティビティや、収集されたデータまたは配信されたデータの内容にさえ興味を持つ人もいます。
正常に処理されたコールの定義も異なります。 場合によっては、単一のトランザクションで成功となります。 その他の場合では、それぞれ個々のトランザクションには独自の成功基準があり、成功のいくつかの段階がある場合があります。 たとえば、一部の顧客は、エージェントへの転送前に完了したトランザクションがないコールとエージェントへの転送前に 1 つ以上のトランザクションが完了したコールを区別します。
システムでは、顧客がこれらの要件を満たすため、必要に応じて使用できるツールを提供しています
- コール ルータ コール オブジェクトの VRUProgress 変数
- Call_Type_Interval テーブルの 7 つの VRUProgress ロールアップ バケット
- Call_Type_Interval VRUProgress 統計に関するレポートのレポート テンプレート
- Route_Call_Detail テーブルの [VRUProgress] フィールド
次の表では、 CVP スクリプト アプリケーションで使用可能な VRUProgress 変数と、この変数とレポート カラムの対応関係について説明します。
これらの VRUProgress 変数は CVP アクティビティ レポート内のカラムにマップされ、コール タイプごとに各変数に対してカウントされたコール数を表示できるようになります。 必要な場合は、このデータを使用してアプリケーションを変更することもできます。 たとえば、エラー条件が頻繁に発生して発信者が強制転送されるような場合は、そのノードの関数を修正することができます。 多数の発信者がアプリケーションで処理される前にエージェントに転送されることを選択している場合、そのアプリケーションに機能を追加することをお勧めします。
スクリプトでの変数設定 |
レポートでの表示 |
説明 |
|---|---|---|
0 |
VRU コールでない：レポートに表示されません |
このコールが VRU コールではないことを示しています。 これはデフォルト値です。 |
1 |
VRU 未処理 |
発信者のニーズがアプリケーションのこのポイントでは満たされていないことを示します。 |
2 |
VRU 処理 |
発信者のニーズがアプリケーションのこのポイントまでに満たされていることを示します。 たとえば、発信者が口座残高を正常に受信した場合です。 |
3 |
VRU アシスト |
発信者のニーズがアプリケーションで満たされた後、このコールがエージェントに転送されたことを示します。 たとえば、発信者が口座情報を正常に受信した後、別の理由で、または自動応答では入手できない追加情報を得るために、エージェントとの通話をリクエストした場合です。 |
4 |
VRU オプトアウト未処理 |
発信者のニーズがアプリケーションによって満たされる前に、発信者のリクエストによってコールがエージェントに転送されたことを示します。 たとえば、自動トランザクションの実行前、またはトランザクションの完了処理中に、発信者がエージェントに転送されるように「0」を押した場合です。 |
5 |
VRU スクリプト転送 |
コールがアプリケーションによってエージェントに転送されたことを示します。 たとえば、発信者が口座残高を確認した後、新しい口座オプションについて検討するために、アプリケーションが発信者をエージェントに転送した場合です。 別の例としては、発信者が特定の種類のサービスをリクエストするために番号を入力した後、リクエストを処理するために、応答可能なエージェントにコールが転送された場合が挙げられます。 |
6 |
VRU 強制転送 |
システム エラーが原因で、発信者がエージェントに転送されたことを示します。 たとえば、アプリケーション内の特定ノードにおける失敗が原因で、コールがエージェントに転送された場合です。 |
7 |
VRU その他 |
コールの処理が、他の VRUProgress 変数のいずれとも一致しないことを示します。 |
VRUProgress 変数を使用すると、トランザクションの終了時点の最終的な VRU ステータスを示したり、アプリケーション内のさまざまなトランザクションを通じて VRU ステータスの変化を示したりすることができます。
（注） |
アプリケーションの至るところで VRUProgress 変数を変更できますが、コール タイプについては最終ステータスだけがレポートされます。 VRUProgress 変数の値は、ルーティング スクリプトの終了時にデータベースに書き込まれます。 コール タイプ VRU アクティビティ レポートを使用して、スクリプトに関連付けられたコール タイプの統計をモニタリングすることにより、アプリケーション全体の VRU ステータスをレポートできます。 |
（注） |
アプリケーションの至るところで VRUProgress 変数を変更できますが、コール タイプについては最終ステータスだけがレポートされます。 VRUProgress 変数の値は、ルーティング スクリプトの終了時にデータベースに書き込まれます。 コール タイプ VRU アクティビティ レポートを使用して、スクリプトに関連付けられたコール タイプの統計をモニタリングすることにより、アプリケーション全体の VRU ステータスをレポートできます。 |
アプリケーション内の個々のトランザクションについてレポートする場合は、VRUProgress 変数を変更した後、各トランザクションの終了時点でコール タイプを変更します。 トランザクションごとに、関連した VRUProgress 変数を持つ異なるコール タイプを設定しておく必要があります。 このアクションにより、VRUProgress 変数の値が、ルーティング スクリプトの終了時点だけでなく、特定のトランザクションで取り込まれるようになります。 コール タイプが変更されると、そのトランザクションに関連付けられたコール タイプに関する値がデータベースに書き込まれます。 コール タイプ VRU プログレス レポートを使用して、これらのトランザクションに関連付けられたコール タイプの統計をモニタリングすることにより、個々のトランザクションについてレポートできます。
VRU メトリックを示すレポート
次のレポートは、VRU アプリケーション用メトリックを示します。
データ損失およびコンポーネント フェールオーバー
Packaged CCE では、データの収集と保管に高度な手法が使用されます。 システムの複雑さ、収集されるデータの量、デバイスや Peripheral の多様性、関与する複雑なプロセスのために、履歴レポートに一貫性のないデータが表示される可能性があります。
このようなレポートの不一致は混乱を招きますが、大部分は、関与するプロセス間のタイム ラグやデータ自体の性質に起因する一時的な影響までトレースできます。
この項では、履歴データの一時的な不一致や永続的な不一致につながる共通の条件を特定し、説明します。 レポートに表示されるデータに対するシステム フェールオーバーの影響の可能性について説明し、データ損失を防ぐ方法に関するガイドラインを示します。
レポーティングのデータ フロー
データは Call Router からロガーに送信されます。 デフォルトでは、レポートはロガーから直接行われます。
Historical Data Server（HDS）はオプションです。 HDS が設定されている場合、ロガーは履歴データを履歴データ サーバに履歴間隔で転送します。
リカバリと複製
リカバリ キー
リカバリ キーとは、すべての履歴データ テーブルの基本キーです。 新しいレコードが履歴テーブルに挿入される前に、このキーが必ず 1 増加します。
デュプレックス構成では、最初に初期化を終えたロガーがプライマリ ロガーとして指定されます（ただし、両方のロガーは常にアクティブで、並行して動作します）。 リカバリ キーは常にプライマリ ロガーによって初期化されます。 リカバリ キーは現在の GMT 日時に基づいており、必ず以前に生成された値よりも大きい値を持ちます。 これにより、リカバリ プロセスでロガー間の同期を保つことができます。
ロガーでは HDS のデータを 1 テーブルずつ複製するため、この複製処理には 1 ～ 5 分程度の遅延が発生する場合があります。
複製（Replication）
複製プロセスでは、ロガーのセントラル データベースにコミットされたデータが HDS データベースに複製されます。
（注） |
外部 HDS はオプションのコンポーネントです。 デフォルトでは、レポーティングはロガーから実行されます。 |
複製メカニズムは 2 つのプロセス、すなわちロガー上で実行される複製サーバ プロセスと、ディストリビュータ上で実行される複製クライアント プロセスで構成されます。ディストリビュータには HDS もインストールされています。
複製クライアントは、複製サーバに要求を送信し、対応する履歴テーブルの現在のリカバリ キーよりも大きい値のリカバリ キーが関連付けられた履歴データを要求します。 複製サーバは、要求されたデータを毎回 2000 レコードのセットとして返します。
複製サーバは、ロガーの実際のテーブルから履歴データを読み取って複製クライアントへ送信します。複製クライアントは、この履歴データを HDS データベースにある実際の対応する履歴データに書き込みます。 ロガーから HDS へのデータの複製では、一時テーブルは使用されません。
考えられる遅延または不一致のポイント
HDS に接続されているロガーがオフラインになっても、HDS が別のロガーに接続されることはありません。 たとえば HDS がロガー B に接続されている場合、そのロガー B が故障しても HDS はロガー A に接続されません。 ロガー B が再び運用可能になったら、ロガー A のデータを使用して回復処理が行われ、現在の履歴情報の受信が開始されます。 ロガー B がロガー A からすべてのデータを取得して回復が完了すると、そのデータを使用して HDS への複製が開始されます。
ロガーがオフラインのとき、あるいはロガーがデータの回復中または複製中のときに、この HDS を使用して最近の間隔のレポートを実行する場合、それらの間隔のデータがレポートに表示されないことがあります。 この現象は一時的なものであり、そのレポートで使用されるテーブルの複製処理が完了すると、データが表示されるようになります。 2 台の HDS Administration & Data Server を使用したフォールトトレラント システムを使用している場合、プライマリ HDS がデータを受信していない間は、バックアップ HDS を使用してレポートを実行できます。
HDS がオフラインになっても、2 台の HDS Administration & Data Server を使用したフォールトトレラント システムを使用していれば、バックアップ HDS を使用してレポートを実行できます。 HDS が再び運用可能になると、最新の HDS データ バックアップを使用してデータが回復され、バックアップから取得できなかった最新のデータはロガーから複製されます。
回復データの複製は、通常のロガーと HDS のデータ複製よりも高速に行われます。 HDS の遅延が、ロガーと HDS の通常の遅延である 1 ～ 5 分にまで回復すると、データが通常どおり複製されるようになります。
ロガーおよび HDS の障害によるデータ損失を防止する方法
データ損失は、履歴データベース テーブル内で 1 つまたは複数のレコードが欠落しているデータ ホールとして表面化します。
データ損失には、一時的な損失と永続的な損失の 2 種類があります。
- 一時的なデータ ホールは、ロガーのリカバリ プロセスで発生する可能性があります。 たとえば、ロガー A が停止した後再び動作可能になり、ロガー B に同期するよう通知し、停止中に書き込まれた履歴データを回復したとします。 このリカバリ プロセスが進行している間、ロガー A のレポート データベースには一時的なデータ ホールができ、リカバリ プロセスが完了するとデータ ホールはなくなります。
- 永続的なデータ ホールは、緊急パージの実行中に発生する可能性があります。 たとえばあるロガーで、他のロガーまたは HDS にまだ送信されていないレコードが緊急パージによって削除されると、永続的なデータ損失が起こることがあります。
データの保持とバックアップ
HDS がオフライン状態から回復すると、バックアップからデータが欠落している期間について、すべてのデータがロガーから取得されます。 それ以外のデータは前回の HDS バックアップから手動で復元する必要があります。
CPU 使用率
空き領域の問題や SQL Server の過負荷が原因で、いずれかのロガーで処理速度が低下することがあります。 その場合、低速な SQL Server を使用しているロガー上のデータは、他のロガーに比べて履歴データの継続性が低下します。 これによって、対応する側の HDS でも処理が遅くなります。
その結果、両側で HDS が設定されており、両方の HDS で同じレポートを実行した場合でも、そのレポートが異なっていることがあります。 SQL Server の処理速度を低下させる条件は修正可能なため、このような不一致は通常は一時的なものです。 多くの場合、自然に拡大するデータベースと負荷状況は修正されます。 ロガーと HDS は、最終的には同じ状況に達して同期します。 後でレポートを実行すると、一致したレポートが生成されます。
ただし、データベース サーバがディスク領域を使い切っている場合、状況は非常に深刻です。問題が解決されるまで、長期間にわたってデータが一致しない可能性があります。 ピア ロガーからデータがパージされ、低速な側のロガーで複製されなかった場合、永続的なデータ損失が発生する可能性があります。
ロガーでのパージおよび保持のスケジュール設定
パージをスケジュールする目的は、最も古いデータを消去してデータベース領域を開放することです。
緊急パージ
Packaged CCE ロガーでは、万一ロガー セントラル データベースが一杯になるか、設定されたしきい値サイズに達した場合でも、データ用の十分なデータベース領域が確保されるように、データ保持とデータベース サイズが事前に設定されています。 その目的は、履歴データベースからデータを消去して領域を解放し、許容される最小の領域よりも広い領域をデータベース内に確保することです。
緊急パージでは、各履歴テーブルが事前定義された順序で 1 つずつ検証され、1 時間分のデータがテーブルからパージされます。 履歴テーブルからデータがパージされるとき、空き領域が最小しきい値よりも大きいかどうかが検証されます。 適切な領域が復旧すると、緊急パージ手順は停止します。 そうでない場合は次の履歴テーブルに移動し、必要なだけパージが繰り返されます。
HDS に保存されておらず、「停止」したピア ロガーまたはリカバリ プロセスでの複製もされていない履歴データが緊急パージによって削除されると、その履歴データは永久に失われる可能性があります。
データベースの使用率は、複製プロセスにおける通常の状態メッセージとして、数分ごとに表示されます。 この値を時々監視することで、使用率増加の頻度が高すぎないか、あるいは速すぎないかを確認できます。 使用率が設定値（通常は 90 %）を超えると緊急パージが発生します。
PIM 障害およびレポーティングからのデータ損失
次に、UCM または CVP VRU PIM 障害でデータ損失が発生した場合のレポートの考慮事項をいくつか示します。
Peripheral インターフェイス マネージャ（PIM）は、Peripheral への実際の接続および Packaged CCE に代わっての CTI インターフェイスの標準化を受け持つ、Peripheral Gateway 上のプロセスです。
PIM で障害が発生した場合に、PIM と UCM または CVP の間のリンクがダウンした場合または UCM か CVP がダウンした場合、PIM に関連付けられた Peripheral に対して収集されたすべてのレポート データは削除されます。
PIM の障害が発生した場合、Peripheral はセントラル コントローラに対してオフラインであるとマーキングされます。
UCCE エージェント PG の場合、その Peripheral 上のすべてのエージェントの状態はログアウト済みに設定され、コール ルータなどにレポートされます。
PG がデュプレックスの場合は、A 側または B 側の PIM が Peripheral に対してアクティブです。 片側が接続を失うと、他方が起動し、アクティブになります。
その他に考えられるフェールオーバーのポイント
Peripheral Gateway/CTI Manager Service のフェールオーバー
エージェントの PG または CTI Manager サービスが停止した場合、エージェントは一時的にログアウトします。 バックアップ PG または CTI Manager が稼働しはじめると、エージェントは自動的に再ログインする場合があります。 エージェント、エージェント スキル グループ、エージェント チーム、およびエージェント Peripheral に関するエージェントメディアログアウトステータスレポートには、ログアウト理由コード 50002 が表示されます。
フェールオーバー時のエージェント状態 |
フェールオーバー後のエージェント状態 |
|---|---|
利用可能 |
利用可能 |
待受停止（Not Ready） |
待受停止（Not Ready） |
ラップアップ |
コール前に応答可能状態であった場合、応答可能。 それ以外の場合、エージェントは待受停止に戻ります。 |
Agent Desktop/CTI OS サーバのフェールオーバー
エージェント デスクトップ（CTI OS デスクトップ）がシャットダウンしたり CTI OS サーバとの通信を失ったりした場合、または CTI OS サーバがシャットダウンした場合、エージェントは、 Packaged CCE ソフトウェアとの通信を失った Peripheral によってサポートされているすべての MRD からログアウトされます。
次の状況のいずれかが発生した場合、エージェントは自動的に再ログインします。
エージェント、エージェント スキル グループ、エージェント チーム、およびエージェント Peripheral に関するエージェントメディアログアウトステータスレポートには、ログアウト理由コード 50002 が表示されます。
次の表に示すように、エージェントがフェールオーバー後に戻る状態は、フェールオーバー発生時のエージェント状態によって異なります。
フェールオーバー時のエージェント状態 |
フェールオーバー後のエージェント状態 |
|---|---|
利用可能 |
利用可能 |
待受停止（Not Ready） |
待受停止（Not Ready） |
リザーブ |
利用可能 |
ラップアップ |
コール前に応答可能状態であった場合、応答可能。 それ以外の場合、エージェントは待受停止に戻ります。 |
コール タイプおよびスキル グループ メトリック
この項では、 コール タイプおよびスキル グループ メトリックについて説明します。
コール タイプのリアルタイム テーブル メトリック
次の表に、レポート メトリックに影響する Call_Type_Real_Time テーブルのフィールドをメトリックのカテゴリ別に示します。
キューイング メトリック |
VRU メトリック/応答メトリック |
サービス レベル メトリック |
放棄メトリック |
|---|---|---|---|
AvgRouterDelayQHalf AvgRouterDelayQNow AvgRouterDelayQTo5 AvgRouterDelayQToday CallsLeftQTo5 CallsAtVRUNow RouterCallsQNow RouterCallsQNowTime RouterLongestCallQ RouterQueueCallsHalf RouterQueueCallsTo5 RouterQueueCallsToday RouterQueueWaitTimeHalf RouterQueueWaitTimeTo5 RouterQueueWaitTimeToday ServiceLevelCallsQHeld |
CVP： CallsAtVRUNow 応答： AnsweredWaitTimeHalf AnswerWaitTimeTo5 AnswerWaitTimeToday CallsAnsweredHalf CallsAnsweredTo5 CallsAnsweredToday CallsAtAgentNow |
ServiceLevelAbandHalf ServiceLevelAbandTo5 ServiceLevelAbandToday ServiceLevelCallsHalf ServiceLevelCallsTo5 ServiceLevelCallsToday ServiceLevelCallsOfferedHalf ServiceLevelCallsOfferedTo5 ServiceLevelCallsOfferedToday ServiceLevelHalf ServiceLevelTo5 ServiceLevelToday |
CallDelayAbandTimeHalf CallDelayAbandTimeTo5 CallDelayAbandTimeToday CTDelayAbandTimeHalf CTDelayAbandTimeTo5 CTDelayAbandTimeToday DelayAgentAbandTimeHalf DelayAgentAbandTimeTo55 DelayAgentAbandTimeToday DelayQAbandTimeHalf DelayQAbandTimeTo5 DelayQAbandTimeToday RouterCallsAbandQHalf RouterCallsAbandQTo5 RouterCallsAbandQToday RouterCallsAbandToAgentHalf RouterCallsAbandToAgentTo5 RouterCallsAbandToAgentToday TotalCallsAbandHalf TotalCallsAbandTo5 TotalCallsAbandToday |
次の表に、レポート メトリックに影響する Call_Type_Interval テーブルのフィールドをメトリックのカテゴリ別に示します。
キューイング メトリック |
VRU メトリック/応答メトリック |
サービス レベル メトリック |
放棄メトリック |
|---|---|---|---|
AvgRouterDelayQ CallsQHandled RouterQueueCalls RouterQueueCallType Limit RouterQueueGlobalLimit RouterQueueWaitTime |
CVP： CTVRUTime VRUTime 応答： AnsInterval1 ～ AnsInterval10 AnswerWaitTime CallsAnswered |
ServiceLevelAband ServiceLevelCalls ServieLevelCallsOffered ServiceLevel |
AbandInterval1 ～ AbandInterval10 CallDelayAbandTime CTDelayAbandTime DelayAgentAbandTime DelayQAbandTime RouterCallsAbandQ RouterCallsAbandToAgent TotalCallsAband |
ネットワーク VRU およびスキル グループ メトリック
応答待機時間と ASA のメトリックには、ネットワーク キュー内で消費された時間は含まれません。サービス レベル メトリックにはこの時間が含まれます。
放棄スキル グループ メトリックでは、キューイング中に放棄されたコール数を判断できますが、コールが CVP を出てからエージェントがそれに応答するまでの間に放棄されたコール数は特定できません。
（注） |
どのスキル グループ メトリックにも、セルフサービスで消費された時間またはセルフサービス中に終了したコールは含まれません。コールはキューイングされるまではスキル グループに関連付けられず、セルフサービスの完了後にコールがキューイングされるからです。 |
次の表に、レポート メトリックに影響する Skill_Group_Real_Time テーブルのフィールドをメトリックのカテゴリ別に示します。
キューイング メトリック |
CVP メトリック/応答メトリック |
サービス レベル メトリック |
放棄メトリック |
|---|---|---|---|
CallsQueuedNow LongestCallQ RouterCallsQNow RouterLongestCallInQ |
CVP： なし。 応答： AnswerWaitTimeTo5 CallsAnsweredTo5 |
ServiceLevelTo5 ServiceLevelCallsTo5 ServiceLevelCallsAbandTo5 ServiceLevelCallsDequeuedTo5 ServiceLevelRonaTo5 ServiceLevelCallsOfferedTo5 |
RouterCallsAbandQTo5 RouterCallsAbandToAgentTo5 |
次の表に、レポート メトリックに影響する Skill_Group_Interval テーブルのフィールドをメトリックのカテゴリ別に示します。
キューイング メトリック |
CVP メトリック/応答メトリック |
サービス レベル メトリック |
放棄メトリック |
|---|---|---|---|
CallsQueued RouterQueueCalls |
CVP： なし。 応答： AnswerWaitTime CallsAnswered |
ServiceLevel ServiceLevelCalls ServiceLevelCallsAband ServiceLevelCallsDequeued ServiceLevelError |
AbandonRingCalls AbandonRingTime RouterCallsAbandQ RouterCallsAbandToAgent |
スキル グループに関するレポーティング
プレシジョン キューに関するレポーティング
次の Cisco Unified Intelligence Center レポート テンプレートは、プレシジョン ルーティング用の新規のテンプレートです。
- エージェント プレシジョン キューのメンバーシップ：このレポートには、選択されたエージェント、エージェントがログインするメディア ルーティング ドメイン、および最大 5 つの属性が関連付けられたアクティブなプレシジョン キューが表示されます。
- プレシジョン キュー - リアルタイム全フィールド：このレポートには、選択されたプレシジョン キューの現在のステータスが表示されます。
- プレシジョン キュー - 履歴全フィールド：このレポートには、統合されたコールの間隔データとプレシジョン キューの統計情報が表示されます。
- エージェント プレシジョン キュー - 履歴全フィールド：このレポートには、選択されたエージェントに関する選択された間隔のアクティビティが、プレシジョン キューでソートされた状態で表示されます。
次の Cisco Unified Intelligence Center レポート テンプレートには、プレシジョン ルーティングのアップデートが含まれます。
- エージェント - リアルタイム：このレポートには、各エージェントについて、アクティブ スキル グループまたはアクティブ プレシジョン キュー、状態、およびエージェントがログインする各メディア ルーティング ドメイン内のコール方法が表示されます。
- エージェント チーム - リアルタイム：このレポートには、選択された各エージェント チームの現在のステータスと、選択されたエージェント チーム内の各エージェントの現在の状態およびアクティブ スキル グループまたはアクティブ プレシジョン キューが表示されます。
- コール タイプ キュー - 履歴全フィールド：このレポートには、コール タイプ ID 内のスキル グループとプレシジョン キューの要約統計情報が表示されます。