Cisco ICM ソフトウェア: IP Contact Center 管理ガイド Release 5.0
IPCC レポーティング アーキテクチャ
IPCC レポーティング アーキテクチャ
発行日;2012/07/20 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 3MB) | フィードバック

目次

IPCC レポーティング アーキテクチャ

内容

IPCC レポーティング アーキテクチャについて

IPCC システムのコンポーネント

IPCC とレガシー ACD ICM との比較

音声だけの設定(マルチチャネル オプションなし)

IPCC レポーティングに対するコール フローとタスク フローの影響

IPCC コール フローの影響を受ける主なデータベース フィールド

マルチチャネル オプションの設定

追加情報

30 分ごとに影響を受けるフィールド

リアルタイム更新

IPCC レポーティング アーキテクチャ

Cisco IP Contact Center(IPCC)アーキテクチャには、Cisco Intelligent Contact Management(ICM)ソフトウェア、Cisco CallManager、Interactive Voice Response(IVR)、および Peripheral Gateway(PG; ペリフェラル ゲートウェイ)が含まれています。IPCC アーキテクチャには、コラボレーション サーバ、E-Mail Manager などのマルチメディア オプションが含まれることもあります。IPCC アーキテクチャはレポートに影響を与え、レガシー ACD を使用する ICM 設定のアーキテクチャとはかなり異なります。IPCC のレポーティングについて理解するには、最初に IPCC コンポーネント、IPCC アーキテクチャとレガシー ACD 設定の ICM との相違点、および IPCC システムでのタスク フローについて理解する必要があります。

IPCC レポーティング アーキテクチャについて

IPCC アーキテクチャは、従来のレガシー ACD の ICM 設定のアーキテクチャとは大きく異なります。次のトピックでは、両方のアーキテクチャの設定および主な相違点について説明します。

「IPCC システムのコンポーネント」

「IPCC とレガシー ACD ICM との比較」

IPCC システムのコンポーネント

IPCC システムを構成する基本コンポーネントは、次のとおりです。

Cisco Intelligent Contact Management(ICM)ソフトウェア 。セントラル コントローラ上の ICM ソフトウェアには ACD 機能があり、エージェント状態の監視および制御、タスクのルーティングとキューイング、CTI 機能、エージェントとスーパーバイザのリアルタイム データの収集、管理用の履歴レポートなどが実行されます。

Cisco CallManager 。Cisco CallManager には、Cisco IP Phone や VoIP ゲートウェイなど、Voice
over IP テレフォニー デバイスに対する従来の PBX テレフォニーの機能があります。


) IPCC 設定では、CallManager のコール パークおよびコール ピックの機能は使用できません。


Interactive Voice Response(IVR)。 Interactive Voice Response システムはルーティング クライアントとして機能します。このシステムでは、DTMF ディジットコレクトを使用して顧客からの情報が収集されます。また、このシステムは、顧客にアナウンスメントや音楽を流すことによって IPCC ソリューションのキュー ポイントとしても機能します。

Peripheral Gateway(PG; ペリフェラル ゲートウェイ) 。ペリフェラル ゲートウェイは、ICM セントラル コントローラの CallManager および IVR コンポーネントの代理として機能します。また、ペリフェラル ゲートウェイでは、IVR やエージェントのアクティビティに関する履歴データおよびリアルタイム データが収集され、ICM セントラル コントローラに送信されます。IPCC システムにマルチメディア オプションが統合されている場合は、ルーティング リクエストをマルチメディア アプリケーションから ICM ソフトウェアに送信する Media Routing(MR; メディア ルーティング)PG も構成に含まれます。

マルチチャネル オプション。マルチチャネル オプションには、コラボレーション サーバと E-Mail Manager があります。コラボレーション サーバを使用すると、エージェントと顧客は Web コラボレーションを使用できます。E-Mail Manager では、コンタクト センター内の電子メール アクティビティが制御されます。IPCC システムに統合されている場合、マルチメディア オプションは IPCC システム内の ICM ソフトウェア コンポーネントに接続されます。マルチメディア オプションでは、MR PRG を介してエージェント グループまたはスキル グループを選択するために、受信タスク リクエストが ICM ソフトウェアに送信され、選択されたエージェントがこのタスクのセッションに設定されます。コラボレーション サーバ エージェントと E-Mail Manager エージェントのエージェント ステータスおよびアクティビティ情報は、エージェント PG を介して ICM ソフトウェアに送信されます。

IPCC とレガシー ACD ICM との比較

この項では、次の設定タイプでの IPCC と従来のレガシー ACD ICM の相違点について説明します。

「音声だけの設定(マルチチャネル オプションなし)」

「マルチチャネル オプションの設定」

音声だけの設定(マルチチャネル オプションなし)

次の 2 つの図を見てください。

最初の図は、1 つのレガシー ACD システムに接続された基本 ICM 設定のトポロジを示しています。レガシー ACD の場合は、設定に ACD PG というペリフェラル ゲートウェイが 1 つ含まれます。IVR は情報収集やセルフサービスのために使用できますが、必須ではありません。タスクはレガシー ACD システム内でキューイングされます。

図 1 レガシー ACD 設定の ICM


) レガシー ACD 設定には VRU を含めることもできます。ただし、ACD 設定では VRU はオプションであるため、顧客の情報を収集する場合に役立ちますが、レガシー ACD 設定でのコールのキューイングには使用できません。


次の図に、基本 IPCC サイトのトポロジを示します。

図 2 IPCC 設定の ICM

 

ACD 設定とは異なり、IPCC 設定では IVR が必要となります。このため、IPCC には、IVR PG および CallManager PG の 2 つのペリフェラル ゲートウェイが必要となります。CallManager PG はエージェント アクティビティをサポートするために使用され、IVR PG はタスクをキューイングする場合に ICM とやり取りするために使用されます。PG では ICM とともに、エージェントやタスクに関するレポート情報が収集されます。

IPCC のコール フローは、レガシー ACD の ICM のコール フローとは大きく異なります。レガシー ACD の ICM の場合は、ICM ソフトウェアによって、コールのルーティング先となる ACD サービスが特定され、ルーティング クライアントに通知されます。コールはキューイングされ、ACD サービスのエージェントが応答します。ACD サービスでは、キューイングとエージェントの情報はすべて保持され、追跡されます。

IPCC の場合は、ICM ソフトウェアによってコールのキューイングにおける統合ロールが実行されます。ただし、ICM ソフトウェアにはメディアの終端ポイントがないため、ICM ソフトウェア内でキューイングされている物理的なコールを IVR に送信する必要があります。

このアーキテクチャでは、タスク統計が次のように分散されます。

IVR サービス(待ち時間)

エージェント サービスおよびスキル グループ(通話/アクティブ時間、保留/一時停止時間、まとめ時間)

ICM ソフトウェア(コール タイプおよびスキル グループ キュー情報)

開始 CTI ルート ポイントで生成されるレコード、IVR で生成されるレコード、およびエージェントで生成されるレコードの 3 種類の Terminal Call Detail(TCD)レコードが生成されます。

IPCC レポーティングに対するコール フローとタスク フローの影響

レポートで取得されるデータについて理解するには、IPCC システムでのコール フローとタスク フローについて理解する必要があります。

以降の項の内容は、次のとおりです。

「IPCC コール フローの影響を受ける主なデータベース フィールド」

「30 分ごとに影響を受けるフィールド」

「リアルタイム更新」

IPCC コール フローの影響を受ける主なデータベース フィールド

タスクはコンタクト センターに着信すると、さまざまな状態になります。この項では、簡単な音声コール フローのシナリオを 5 つのステップに分けて説明します。


ステップ 1 コールが CallManager PG を介して CallManager に着信しましたが、応答可能なエージェントがいません。このコールは、IVR にキューイングされます。

図 3 コールが IVR にキューイングされる

 

a

パブリック ネットワークのコールが音声ゲートウェイを介してルーティングされ、TDM コールから IP コールに変換されます。このコールは、CallManager Voice over IP ネットワークにルーティングされます。CallManager によって CallManager PG に受信コールの到着が通知されます。ICM セントラル コントローラにルート リクエストが送信されます。

b

ICM セントラル コントローラでは、CallManager PG からルート リクエストを受信すると、ダイヤル番号とコール タイプに基づいてスクリプトが実行されます。このスクリプトには、TranslationRteToVRU ノードが含まれています。ICM セントラル コントローラでこのノードが実行されると、CallManager PG にルート応答が送信されます。

ICM セントラル コントローラでは、次の処理が実行されます。

コール タイプの CallsOffered の増加

コール タイプのサービル レベル タイマーの開始

c

CallManager PG で ICM セントラル コントローラからのルート応答を受信すると、CallManager PG によって、コールを IVR に送信するよう CallManager に通知されます。コールの第 1 分岐の CallManager PG で Terminal Call Detail(TCD)レコードが生成されます。IVR では、CallManager PG からタスクを受信すると、ICM セントラル コントローラにリクエスト インストラクション メッセージが送信されます。

d

ICM セントラル コントローラでは、IVR PG からリクエスト インストラクション メッセージを受信すると、VRU Q サービス リクエスト メッセージが送信されます。このメッセージによって、コールに関する統計を増加する必要があるサービスが IVR PG に通知されます。IVR PG に送信されるサービスは、ICM スクリプトの TranslateRteToVRU ノードで使用される IVR サービスです。IVR サービスの IVR PG によって次のことが行われます。

CallsOffered の増加

サービス レベル タイマーの開始

放棄待機タイマーの開始

ステップ 2 コールは、スキル グループにキューイングされます。エージェントが応答可能になります。

図 4 エージェントが応答可能になる

 

a

ICM セントラル コントローラでは、引き続きスクリプトが実行されます。スクリプト内の次のノードは RUN VRU ノードです。このノードによって、顧客に対するアナウンスメントまたは音楽ファイルを再生するよう IVR に指示されます。次に実行されるノードは、Queue to Skill Group ノードです。ICM セントラル コントローラでコールがスキル グループにキューイングされます。

ICM セントラル コントローラでこのスキル グループの RouterCallsQueued が増加し、キューイングされた VRU イベントが IVR PG に送信されます。このメッセージによって、コールがキューイングされたため、コールの遅延時間を停止してキュー時間を開始するよう IVR PG に通知されます。

DelayTime が計算され、TCD レコードの LocalQTime が開始されます。

b

エージェントが応答可能になります。CallManager から ICM セントラル コントローラに対して、エージェント応答可能ステータス メッセージが送信されます。

c

ICM セントラル コントローラから CallManager PG に対して、コール前メッセージが送信されます。このメッセージには、コールがキューイングされていた時間(Local Queue Time)、コール タイプ、スキル グループなどの情報が含まれています。このメッセージによって、コールが間もなくエージェントにつながることが CallManager PG に通知されます。CallManager PG では、TCD レコードのネットワーク ディレイ タイマーおよびエージェントのリザーブ タイマーが開始されます。

d

ICM セントラル コントローラから IVR PG に対して、接続メッセージが送信されます。ダイヤル可能な番号(またはラベル)とともに送信されるため、IVR PG では、物理的にコールをエージェントにルーティングできます。

ステップ 3 IVR からエージェントにタスクが送信されます。

図 5 コールがエージェントに送信される

 

a

IVR からエージェントの IP Phone にコールが送信されます。CallManager PG では、CallManager からコール着信メッセージを受信すると、次のことが行われます。

スキル グループ:

CallsOffered の増加

AnswerWaitTime の開始(ステップ 2 のコール前メッセージで送信された LocalQTime も含む)

TCD:

NetworkQTime の計算

RingTime の開始

エージェント サービス

CallsOffered の増加

SL Timer の開始(ステップ 2 のコール前メッセージで送信された LocalQTime も含む)

AbandonWaitTime の開始(ステップ 2 のコール前メッセージで送信された LocalQTime も含む)

b

コールが IVR PG から送信された後、IVR PG では TCD レコード内の LocalQTime が計算され、TCD レコードが ICM セントラル コントローラに送信されます。TCD には、LocalQTime および NetworkTime が含まれています。

IVR サービスでは、IVR サービスで定義されたサービス レベル タイマーの時間内にコールがルーティングされた場合は、IVR PG によって SLCalls および SLCallsOffered が増加します。

ICM セントラル コントローラでは、このコール タイプの CallsRouted データベース フィールドが増加します。

ステップ 4 エージェントがコールに応答します。

図 6 エージェントがコールに応答する

 

結果は次のとおりです。

 

a

CallManager から CallManager PG に応答イベントが送信されます。CallManager から ICM セントラル コントローラに応答イベントが送信されます。

エージェント:CallsAnswered が増加する。

TCD:Ring Time が計算され、TalkTime が開始される。

エージェント サービス:サービスに対して定義されたサービス レベルしきい値内に、コールに応答した場合は、SLCallsOffered および SLCalls が増加する。

サービス/スキル グループ:CallsAnswered が増加し、AnswerWaitTime が計算される。

b

ICM セントラル コントローラが CallManager PG から応答イベントを受信すると、コール タイプに対して定義されたサービス レベルしきい値内にコールに応答した場合は、SLCalls および SLCallsOffered が増加します。

ステップ 5 コールが切断され、まとめが完了します。結果は次のとおりです。

図 7 コールが切断される

 

a

CallManager から CallManager PG に切断イベントが送信されます。CallManager PG が CallManager から切断イベントを受信します。TCD レコードが生成され、ICM セントラル コントローラに送信されます。レコードには、LocalQTime、SkillGroup、Call Type、NetworkQTime、RingTime、TalkTime、HoldTime、WorkTime が記述されます。

b

ICM セントラル コントローラで TCD レコードに基づいてコール タイプが計算される。

(TCD レコードの LocalQTime + NetTime + RingTime)という式に基づいて AnswerWaitTime が計算される。AnswerWaitTime は、ASA を計算する場合に必要となります。

CallsHandled が増加し、(TCD レコードの TalkTime + HoldTime + WorkTime)という式に基づいて CallsHandledTime が計算される。

マルチチャネル オプションの設定

IPCC にマルチチャネル オプションを設定する場合、レポーティング アーキテクチャは基本的にレガシー ACD 設定の ICM にマルチチャネル オプションを設定する場合と同じですが、レガシー ACD でのブレンディッド コラボレーションだけは例外です。

E-Mail Manager は、ルーティングに使用される Media Routing(MR; メディア ルーティング)PG を介して ICM セントラル コントローラに接続されます。E-Mail Manager は、ICM セントラル コントローラにエージェント ステータスを送信する CallManager PG(または エージェント PG)に接続されます。E-Mail Manager ではタスク リクエストを受信し、E-Mail Manager から ICM セントラル コントローラにタスク情報が送信されてルーティングされます。ICM セントラル コントローラからエージェントおよびスキル グループが返されると、E-Mail Manager ではエージェントにタスクがプッシュされます。エージェントが応答可能ではない場合、タスクは、エージェントが応答可能になるまで ICM ルータにキューイングされます。

シングルセッション チャットおよびマルチセッション チャットの場合は、コラボレーション サーバが MR PG を介して ICM セントラル コントローラに接続されます。また、ICM セントラル コントローラにエージェント ステータスを送信する CallManager PG(または エージェント PG)にも接続されます。コラボレーション サーバでは、シングルセッションまたはマルチセッションのタスク リクエストを受信し、ICM セントラル コントローラにタスク情報が送信されてルーティングされます。ICM セントラル コントローラからエージェントおよびスキル グループが返されると、コラボレーション サーバではエージェントにタスクがプッシュされます。エージェントが応答可能ではない場合、タスクは、エージェントが応答可能になるまで ICM ルータにキューイングされます。

次の図に、ICM セントラル コントローラと統合された E-Mail Manager および非音声コラボレーション サーバを示します。この図は、レガシー ACD 設定の ICM の場合にも IPCC 設定の ICM の場合にも当てはまります。

I

コラボレーション サーバが統合されており、コールバック、遅延コールバック、またはブレンディッド コラボレーションに使用されている場合、レポーティング アーキテクチャは、レガシー ACD の ICM の場合と IPCC 設定の ICM の場合とで異なります。IPCC 設定の場合、レポーティング アーキテクチャは上の図と同じになり、コラボレーション サーバが MR PG およびエージェント PG を介して ICM セントラル コントローラに接続されます。コラボレーション サーバでは、コールバック、遅延コールバック、またはブレンディッド コラボレーションのリクエストを受信し、ICM セントラル コントローラにタスク情報が送信されてルーティングされます。ICM セントラル コントローラからエージェントおよびスキル グループが返されると、メディア ブレンダによって、適切なエージェントと顧客の間で自動電話呼び出しおよび Web コラボレーションが行われるようになります。

レガシー ACD 設定の ICM では、ICM セントラル コントローラではなく ACD によって、タスクを処理するエージェントが選択されます。コラボレーション サーバは、メディア ブレンダおよび ACD とともに設定されています。コラボレーション サーバにリクエストが送信されると、コラボレーション サーバから ICM セントラル コントローラにルート リクエストが送信されます。ICM セントラル コントローラによってラベルが返されます。コラボレーション サーバでは、ラベルを受信すると、リクエストが ACD キューに配置されます。ACD では ICM から返されたラベルを使用して、タスクを処理する適切なエージェントが選択されます。メディア ブレンダによって、Web リクエストは電話およびコラボレーション サーバの適切なエージェントに対してキューイングされます。これにより、エージェントと顧客の通話が Web コラボレーション セッションと調和します。

追加情報

内容
参照先

マルチチャネル メディア クラスのタスク フロー

ICM Documentation CD の『ICM 5.0 Multichannel Implementation Map』

30 分ごとに影響を受けるフィールド

CallManager PG、IVR PG、およびエージェント PG では、ICM セントラル コントローラに蓄積されたすべてのサービス、スキル グループ、およびエージェントの統計が、30 分インターバルで送信されます。ICM セントラル コントローラでは、これらのレコードがセントラル データベース(Logger)に書き込まれます。これらのレコードは Historical Data Server(HDS)に複製されます。

CallManager PG では、30 分間に計算されたすべてのサービス、スキル グループ、およびエージェント統計が、30 分インターバルで ICM セントラル コントローラに送信されます。ただし、ICM セントラル コントローラのスキル グループの場合は、RouterCallsQueued フィールドおよび
RouterCallsAbandon フィールドが増加します。

コール タイプおよびサービスのレポートのデータには、30 分インターバルのシステム アクティビティのスナップショットが反映されているため、これらのレポートの値が食い違う場合もあります。

次に例を示します。

コールが 30 分インターバルの終了直前(1:29)に着信したとします。この時点で、1:00 ~ 1:30 のインターバルのコールに対する CallsOffered が増加します。

次の 30 分インターバルの間の 1:45 にコールが放棄されたとします。1:30 ~ 2:00 のインターバルの CallsAbandon は増加しますが、CallsOffered は 1:00 ~ 1:30 のインターバルですでに増加しているため増加しません。このため、1:30 ~ 2:00 のこのコールに関するレポートでは、CallsOffered は 0 になりますが、CallsAbandon は 1 になります(1:30 ~ 2:00 のインターバル中に別の新しいコールは着信しなかったと想定)。

リアルタイム更新

リアルタイム レポートでは、次の図に示すように 15 秒ごとにデータが更新されます。

図 8 リアルタイム更新


) この更新間隔は WebView のリアルタイム レポートにだけ適用されます。このメカニズムは CTI エージェント デスクトップで使用されるメカニズムとは異なります。


コラボレーション サーバまたは E-Mail Manager オプションで設定されたエージェントおよびスキル グループの場合、CTI サーバはエージェント PG となり、CTI サーバからコラボレーション サーバおよび電子メール エージェントに関するデータが ICM ソフトウェアに送信されます。