Cisco Unified Contact Center Enterprise ソリューション リファレンス ネットワーク デザイン（SRND）Releases 7.0

特性

Unified OUTD ソリューションを使用すれば、エージェントが、ソフトウェアの IP ベースのダイヤラを使用して、アウトバウンド キャンペーンおよびインバウンド コールに参加できます。

Unified OUTD には、次のような利点があります。

• 複数のコール センター サイトに IP ダイヤラを配置して、企業全体のダイヤリング機能を実現できます。Campaign Manager サーバは、中央サイトに置かれます。

• Unified ICM アドミン ワークステーションから集中管理と集中設定が行われます。

• インバウンド コールとアウトバウンド コールを、コールごとにブレンドできます。

• Unified ICM スクリプト エディタを使用してアウトバウンド モードを制御し、アウトバウンド処理で使用するスキルを持つエージェントの比率を制御することで、アウトバウンド モードを柔軟に制御できます。

• アウトバウンド固有のレポート テンプレートを使用した統合 WebView レポートを作成できます。

ベスト プラクティス

Unified OUTD の実装では、次のガイドラインとベスト プラクティスに従ってください。

• メディア ルーティング PG を使用してください。また、ダイヤラごとにメディア ルーティング PIM を使用してください。 メディア ルーティング PG には、複数の PIM を設定して複数のダイヤラをサポートできます。

• 耐障害性を実現するには、1 つのペリフェラルに複数のダイヤラを展開してください。 「耐障害性」を参照してください。

• ダイヤラは、そのダイヤラの登録先である Cisco Unified CallManager クラスタに近い場所に展開してください。

• 転送時間を 1 秒以下にする必要がある場合は、G.729 コーデックを使用しないでください。顧客からのコールに対して、IP ダイヤラがサポートしているコーデックは G.711 音声コーデックだけです。 G.729 コーデックが使用されている地域に Unified OUTD を配置することはできますが、コーデックの切り替えにより、顧客とエージェントの間の転送時間が長くなります。

• Unified OUTD エージェント用に IP Communicator ソフトフォンを使用すると、顧客コールをエージェントに転送するときに、さらに遅延が発生する場合があるので注意してください。

• Cisco Unified CallManager PG あたり 3 つ以上のダイヤラを使用しないでください。

• 各ダイヤラはそれ自身のデバイス プール内に設定して、そのダイヤラのすべてのポートを 1 つの CallManager ノードに登録してください。 このようにすれば、1 つの CallManager ノード内で 2 つのダイヤラがタッグ チームのように動作するのを防止できます。

• 特定のペリフェラルに複数の Unified OUTD がある場合は、各 Unified OUTD 用に同じ数のポートを設定してください。

• Unified OUTD をインストールする際には、Cisco Unified CallManager サーバのサイジングが適切であることを確認してください。 Unified OUTD で実行される膨大な件数のコール転送のために、Cisco Unified CallManager サーバに対するパフォーマンス負荷が増大します。

• Cisco Unified CallManager サーバが過負荷にならないように、ダイヤラのコール スロットリングを有効にしてください。 「ダイヤラのスロットリングと CallManager に関する注意点」を参照してください。

アウトバウンド コールには、CallManager のルーティングとダイヤル プランが使用されます。 そのため、トール バイパスおよびより安価な市内通話料金を利用できるように展開されたゲートウェイを使用してコールを発信できます。 Unified OUTD でテスト済みのゲートウェイは次のとおりです。

• Cisco AS5350 および AS5400 シリーズ

• Cisco 6608

コール フローの説明：エージェント ベースのキャンペーン

エージェントベースのキャンペーンの場合、完了したダイヤラ コールは、Unified IP Phone とデスクトップを使用して、実際のエージェントにルーティングされます。 プリディクティブ モードまたはプログレッシブ モードのダイヤリングのコール フローは次のとおりです（図5-1）。

1. Dialer プロセスは、CTI サーバからのペリフェラル スキルグループに関する統計情報を継続的に監視して、受信可能なエージェントを探します。 同時に、Campaign Manager は、顧客レコードのデータベースを監視して、アクティブなレコードをダイヤラに転送します。 ダイヤラは、アウトバウンド キャンペーンに使用できる受信可能なエージェントを見つけると、MR PIM にルーティング要求を送信します。

2. MR PIM は、そのルーティング要求をルータに転送します。

3. Unified ICM ルータは、ルーティング スクリプトを実行し、受信可能なエージェントを選択してそのエージェントを予約してから、予約したエージェントを示すルーティング ラベル（内線番号）を返します。

4. MR PG は、受信可能なエージェントのラベルをダイヤラに返します。

5. 次に、ダイヤラは、そのエージェントの内線番号に予約コールを発信します。 ダイヤラは、そのエージェントに対する予約コールを CTI サーバ経由で自動応答し、その予約コールを自動的に保留状態にします。

6. ダイヤラは、CallManager と音声ゲートウェイを使用して、顧客コールを開始します。

7. Call Progress Analysis が設定されているときには、Dialer プロセスが RTP ストリームを分析して、人が応答した（または留守番電話が応答した）ことを検出します。 人が応答したことがわかれば、ダイヤラは、ダイヤラ自身が保持しているリスト内の次の予約済みエージェントの内線に、（画面ポップアップに表示するためのコール コンテキストとともに）コールの転送をすぐに開始します。 同様に、留守番電話検出が有効になっている場合には、エージェントまたは IVR にコールが転送されるかコールがドロップされる場合があります。 転送されたコールは、エージェントの Unified IP Phone の 2 番目のライン アピアランスに着信します（そのため、CallManager の Unified CC の内線のコール ウェイティングと 2 番目のライン アピアランスを Unified OUTD 用に有効にしておく必要があります）。

8. ダイヤラは、CTI サーバ経由でエージェントに転送されたコールに自動応答して、顧客とエージェントの間の音声パスがすばやく確立されるようにします。 この処理により、顧客をコールするために使用されたダイヤラ ポートは開放されます。 次に、ダイヤラは、このエージェントに対する予約コールを切断します。 また、ダイヤラは Campaign Manager を更新して、このコールで人による応答が検出されたことを示します。 エージェントがアウトバウンド コールを処理し終わると、同じメッセージ フローを使用して、そのエージェントを別のアウトバウンド コールに予約できます。

前述のメッセージ フローには、プリディクティブ モードまたはプログレッシブ モードのダイヤリングのフローが説明されています。 これら 2 つのダイヤリング モードの違いは、ダイヤラがアウトダイヤル レートを決定する方法（ダイナミックまたは固定）だけです。 プレビュー ダイヤリングの場合、エージェントには顧客レコードの画面ポップアップが表示されます。 エージェントがこのコールを発信する場合は、エージェント デスクトップ上でエージェントが［承認 （accept)］をクリックする必要があります。 この操作により CTI イベントが生成されて、ダイヤラがこの顧客へのコールを開始します。

場合によっては、ダイヤラが発信したコールに、留守番電話やビジー シグナルの応答があったり、呼び出しても応答がない場合もあります。 そのような場合、ダイヤラは Campaign Manager に更新メッセージを送信してキャンペーンから次のレコードを取得し、その顧客の電話番号にコールを発信します。

図5-1 エージェントベースのキャンペーンのコール フロー

コール フローの説明：IVR に転送する形態のキャンペーン

IVR ベースのキャンペーンの場合、次のプロセスに従って、人が応答したコールが IVR システムに転送されます（図5-2）。

1. 顧客へのコールをダイヤラが開始します。

2. RTP ストリームが分析されて、音声が検出されます。

3. ダイヤラは、事前に設定されたルートポイントへのインライン転送を要求します。

4. CallManager PG が、そのルータに対するトランスレーション ルートを要求します。

5. ルータが応答します。

6. 応答が変換されて CallManager に送信されます。

7. CallManager がコールを IVR に転送します。

図5-2 IVR ベースのキャンペーンのコール フロー

アウトバウンド ダイヤリング モード

Unified OUTD は、スキルグループに応じて、次の数種類のモードのいずれかを使用してコールを開始します。

• プレディクティブ モード：エージェントごとにダイヤルする回線数が動的に計算されます。

• プログレッシブ モード：管理者がエージェントごとに固定的に設定した回線数が使用されます。

• プレビュー モード：顧客のコールをエージェントが（デスクトップで有効になっているボタンを使用して）手動で承認、拒否、またはスキップします。 エージェントあたり 1 回線がダイヤルされます。

• ダイレクト プレビュー モード：エージェントがデスクトップでコールのリング音を聞けるようにします。エージェントがコールを直接発信する場合に似ています。 エージェントあたり 1 回線がダイヤルされます。

• パーソナル コールバック モード：後で行われるコールバックが自分に転送されるようにエージェントが指定できます。 エージェントと顧客の間で事前に決められた時刻に、エージェントが顧客をコールバックします。

Campaign Manager

サイド A の Logger に常駐する Campaign Manager は次のタスクを処理します。

• キャンペーン スケジュールを管理する

• システムとダイヤラの設定を保守する

• 設定で変更可能なクエリー ルールに基づいて、キャンペーンからどのコンタクト レコードを取得するかを決定し、コンタクト レコードをダイヤラに配信する

• Import プロセスおよびシステム内のすべての使用可能なダイヤラに設定データを配信する

• リアルタイム データと履歴データを収集して、Unified ICM CallRouter に送信する

• メモリ内の Do-Not-Call（コール不可）リストを保守し、変更されたときには更新する

• データベース内の Do-Not-Call（コール不可）リストにある顧客レコードをマーキングして、これらのレコードに対しては、それ以上処理が行われないようにする

Campaign Manager は、サイド A の Logger と同じシステムで動作するので、コンタクト リストの大規模なインポートは業務時間外にスケジュールすることが重要です。

Enterprise 版の展開

Unified ICM 7.0 Bill of Materials（BOM; 製品構成表）（ 表5-1 ）に指定されている最小要件を満たす Windows サーバで Unified OUTD を実行します。

複数ダイヤラの展開

図5-3 に、複数のダイヤラを使用した推奨展開モデルを示します。 各ダイヤラは、それぞれのサイドの CallManager サブスクライバに関連付けられており、ダイヤラのすべてのポートがそのサブスクライバの 1 つのデバイス プールに設定されています。 図に示されている設定では、192 個のダイヤラ ポートがあります。 規模を拡張するには、ダイヤラ/PG/サブスクライバのペア（サイド A とサイド B）を最大 4 ペア（つまり、CallManager クラスタあたり 8 個のダイヤラ/PG/サブスクライバ）まで追加できます。 この配置モデルで複数のダイヤラを使用すると、耐障害性を実現できます。 「耐障害性」を参照してください。

図5-3 複数ダイヤラの展開

ダイヤラと CallManager クラスタの間の接続は、複数の SCCP（Skinny Client Control Protocol）セッションで構成されており、各ダイヤラ ポートに 1 つのセッションが割り当てられています。 図に示されている二重 PG（サイド A とサイド B）は、Generic PG（Unified CC PIM および Unified IP IVR PIM 搭載）、MR PG、CTI サーバ、および CTIOS サーバ プロセスで構成されています。 二重 PG と CallManager クラスタの間の接続は JTAPI リンクです。

（注） ダイヤラと IP エンドポイント（音声 GW または Unified IP Phone など）の間には、G.711 プロトコルが必要です。

単一ダイヤラの展開

図5-4 は、単一ダイヤラのインストールを示しています。 ダイヤラは二重 PG のサイド A にインストールされるように図示されていますが、これは要件ではありません。 単一ダイヤラの設定では、96 個のポートを設定できます。 この配置モデルは、拡張性および耐障害性が求められていない場合に使用します。

図5-4 単一ダイヤラの展開

Cluster Over the WAN（CoW; WAN 経由のクラスタリング）

WAN を経由して Unified CC をクラスタ構成にする展開モデルでは、WAN のもう一方の側に冗長化のためのコンポーネントを展開すれば、耐障害性を向上できます（「展開モデル」）。 Unified OUTD の耐障害性モデルは、CoW で使用されるモデルとは異なります。そのため、CoW を展開するときには、CoW の利点はインバウンド トラフィックだけに適用されることに注意してください。

分散型の展開

図5-5 は、分散型の展開モデルを示しています。1 つのサイトには、Logger にインストールされた Campaign Manager があり、中央の Unified ICM システムと CallManager も同じサイトに配置されています。 WAN 経由で到達可能な 2 番目のサイトには、ダイヤラ、PG、および Unified OUTD が配備された 2 つ目の CallManager システムが配置されています。 Campaign Manager は、ダイヤラ レコードを WAN 経由で送信し、ダイヤラはローカルの顧客にコールを発信します。 2 番目のサイトは、インバウンド エージェントもサポートします。 「IPT： 複数のサイトに対する分散型コール処理」を参照してください。

図5-5 分散型ダイヤラの展開

音声ゲートウェイの近さ

Unified OUTD は、Unified CC PG および CallManager クラスタ（音声ゲートウェイを含む）と同じ場所に配置する必要があります。 ダイヤラは G.711 ulaw だけをサポートしているので、WAN の帯域幅から大きなブロックを割り当てる必要がある場合があります。 ダイヤラが G.729 サポートしていない場合でも、Unified OUTD は G.729 をサポートできます。 このタイプの構成は、トランスコーダを使用しなくてもサポートできます。

この展開形態では、ダイヤラは（実際は G.729 をサポートしていませんが）G.729 機能をアドバタイズします この処理によって、ダイヤラからエージェントへの予約コールを完了させることができるようになります。 ダイヤラから顧客へのコールには G.711 を使用する必要があります。ただし、顧客のコールは、次にエージェントに転送され、再ネゴシエートされて G.729 で処理されます。

（注） 音声ゲートウェイが WAN 経由でリモート設置されている場合は、コール転送でさらに遅延が発生するため、再ネゴシエーションを使用しないことをお勧めします。 そのような構成では、G.711 コーデックを使用することをお勧めします。

ブレンデッド設定

Unified OUTD オプションでは、完全ブレンデッドの状態でキャンペーンを実行できます。 エージェントは、インバウンド コールとアウトバウンド コールを交互に処理できます。 MCS のインバウンド キャパシティについての詳細は、「Unified CC のコンポーネントとサーバのサイジング」を参照してください。 「Unified OUTD カルキュレータ」も参照してください。

System Unified CC の設定

System Unified CC は、Enterprise Unified CC のインストールと設定を簡素化した展開モデルです。 アウトバウンド コントローラは、ダイヤラとメディア ルーティング PG のコンポーネントがある別のコンピュータにインストールされています。 System Unified CC でサポートされるのは、1 つの Dialer プロセスだけなので、耐障害性はサポートされません。