この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
目次
この章では、Cisco Unified Intelligent Contact Management(ICM)について、Unified CVP との関係という観点から説明します。 Unified ICM を考慮して展開モデルを選択する場合もあれば、Unified CVP の展開を考慮して Unified ICM のコンフィギュレーションを選択する場合もあります。
ここでは最初に、Unified CVP の導入に関連するため、Unified ICM のネットワーク VRU のタイプ全般、および Unified ICM について説明します。
このマニュアルでは、Voice Response Unit(VRU; 音声応答装置)と Interactive Voice Response(IVR; 音声自動応答装置)という用語は、同じように使用されています。
この項では、Unified CVP アプリケーションで使用される Unified ICM VRU のタイプについて説明します。 Unified ICM は、IVR 処理を必要とするコールには、スイッチ レッグと VRU レッグという 2 つの部分があると認識しています。 スイッチは、ネットワークまたは発信者からのコールを最初に受信するエンティティです。 VRU は、オーディオを再生し、プロンプト/コレクト機能を実行するエンティティです。 Unified CVP は、Unified ICM の観点からは、スイッチ ロールまたは VRU ロール、あるいはその両方に参加できます。 ネットワーク導入では、複数の Unified CVP デバイスはスイッチと VRU 部分を個別に提供します。
VRU へのコール配信は、コール参照 ID を VRU に渡すネットワーク機能に応じて、相関 ID メカニズムまたはトランスレーション ルート メカニズムに基づいて行うことができます。 Unified ICM はコールを完了する指示を出すために同じコールの 2 つのレッグを相関させる必要があるため、コール参照 ID が必要となります。 Unified ICM アプリケーションでは、VRU は、スイッチから受信した着信コールの処理方法に関する指示を要求するときに、このコール参照 ID を Unified ICM に提供します。 このメカニズムによって、Unified ICM はこの同じコールの適切なコール コンテキストを取得でき、この段階でコールの IVR 部分に進むことになります。 これら 2 つの相関メカニズムは、次のように動作します。
(注) |
展開される VRU は、ネットワーク内(ネットワーク VRU)または顧客構内に展開できます。 後者のシナリオでは、Network Applications Manager(NAM)がネットワーク内に導入され、カスタマー ICM(CICM)が顧客構内に導入されます。 VRU の位置によって、対応する相関 ID またはトランスレーション ルート ID が使用されます。 |
Unified CVP タイプ 10 VRU は、Unified CVP の包括モデル導入におけるコンフィギュレーション要件を簡略化するために設計されました。 タイプ 10 VRU は、すべての新規インストールに対して優先される VRU タイプですが、Cisco Unified ICM 7.1 以降を必要とします。 ICM Customers の使用が必要な展開では、以降で概説するその他の VRU タイプを使用できます。または、Unified ICM 7.5(3) 以降のリリースを使用できます。 ICM Customers は現在サポートされていますが、Unified CVP VRU スイッチ レッグから完全に別の Unified CVP への 2 ステップ転送(たとえば、SendToVRU を使用した 2 ステップでの CVP から CVP への転送)は開始できません。 そのような 2 ステップ転送を機能させるには、トランスレーション ルートを使用する必要があります。
タイプ 10 ネットワーク VRU の動作は、次のとおりです。
ICM Customers 機能を使用しない Unified CVP 実装(つまり、単一のネットワーク VRU を使用する Unified CVP 実装)では、単一のタイプ 10 ネットワーク VRU を定義する必要があり、すべての Unified ICM VRU スクリプトをそれに関連付ける必要があります。 Unified CVP スイッチ レッグ ルーティング クライアント用にラベルが 1 つ必要であり、コールを Unified CVP VRU レッグに転送します。 コールが Unified CM から Unified CVP に転送される場合、Unified CM ルーティング クライアント用にも別のラベルが必要であり、このラベルは CVP ルーティング クライアント用に使用されるラベルとは異なるラベルである必要があります。 このラベルによって、コールは Unified CVP スイッチ レッグに転送されます。 Unified ICM ルータは、このラベルに相関 ID を連結して Unified CM に送信します。 これらの任意の追加番号を処理するように Unified CM を設定する必要があります。
同じタイプ 10 ネットワーク VRU を指すように、Unified CVP スイッチ レッグ ペリフェラルを設定してください。 また、Unified CVP に転送されるコールのすべての着信番号を、同じタイプ 10 ネットワーク VRU を指すカスタマー インスタンスに関連付けてください。
コール ルーティング インターフェイス VRU または TDM ACD で発生するコールの場合、TranslationRouteToVRU ノードを使用してコールを Unified CVP のスイッチ レッグ ペリフェラルに転送します。 その他のすべてのコールの場合は、SendToVRU ノード(自動の SendToVRU 動作を含むノード(キューイング ノードなど))または RunExternalScript を使用します。
(注) |
Cisco Unified ICM 7.1 は、タイプ 10 ネットワーク VRU を導入しています。 Unified ICM 7.1 以降を使用する Unified CVP のすべての新規実装には、この VRU を使用してください。 アップグレードした既存の顧客導入または Unified ICM 7.1 以降を実行していない導入には、タイプ 5 VRU を使用する必要があります。 |
VRU エンティティがスイッチ(呼制御)と VRU(IVR)の両方として機能するという点で、タイプ 5 とタイプ 6 は似ています。 ただし、VRU への接続方法が異なります。
タイプ 6 では、スイッチと VRU は同じデバイスであるため、コールはすでに VRU にあります。 Unified ICM の観点からは、接続および要求命令のメッセージ シーケンスは必要ありません。
一方、タイプ 5 では、スイッチと VRU は Unified ICM の観点からは、同じサービス ノード内にある(つまり、どちらも同じ PG インターフェイスを介して Unified ICM と対話する)場合でも、異なるデバイスです。 そのため、Unified ICM は接続および要求命令のシーケンスを使用して IVR コールを完了します。
(注) |
Unified CVP アプリケーションには、Unified ICM によって認識されるコールの 2 つのレッグ(スイッチ レッグおよび VRU レッグ)があります。 Unified CVP がサービス ノード アプリケーションとして機能する場合(つまり、Unified CVP がコールをプレルーティングを使用してではなくネットワークから直接受信する場合)、コール制御(Unified CVP)と VRU デバイスが異なるため、Unified CVP は Unified ICM にとってタイプ 5 と見なされます。 したがって、スイッチ レッグに対する Unified ICM および NAM のコンフィギュレーションにおいて、Unified CVP を VRU タイプ 5 として設定する必要があります。 VRU レッグには、展開モデルに応じて異なるセットアップが必要です(たとえば、包括 Unified ICM 企業展開モデルでは、VRU レッグはタイプ 7 である場合があります)。 Unified CVP をタイプ 5 として設定する例については、最新バージョンの『Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP)』を参照してください。このマニュアルは http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html から入手できます。 |
Unified CVP が Unified ICM および NAM に対してタイプ 5 VRU として機能する場合は、相関 ID もトランスレーション ルート ID も必要ありません。 ただし、ラベルが必要となる場合があります。
(注) |
Cisco Unified ICM 7.1 は、タイプ 10 ネットワーク VRU を導入しています。 Unified ICM 7.1 以降を使用する Unified CVP のすべての新規実装には(VRU のみ(後述するモデル #4a)は除く)、この VRU を使用してください。 アップグレードした既存の顧客導入または Unified ICM 7.1 以降を実行していない導入には、タイプ 3 またはタイプ 7 VRU を使用してください。 |
VRU が相関 ID メカニズムを備えた IVR として機能する場合、Unified ICM はタイプ 3 およびタイプ 7 を使用し、相関 ID スキームの PG を使用して VRU のサブ動作を指定します。 タイプ 3 およびタイプ 7 VRU はどちらも相関 ID メカニズムを使用して到達可能であり、VRU を制御するために PG が必要です。 ただし、これら 2 つのタイプでは、VRU レッグの解放方法およびコールを最終宛先に接続する方法が異なっています。
タイプ 3 では、コールを VRU に配信するスイッチは、コールを VRU から取得して宛先(またはエージェント)に接続できます。
タイプ 7 では、スイッチはコールを VRU から取得できません。 IVR 処理が完了すると、Unified ICM は切断するか VRU レッグを解放する必要があり、その後で最終接続メッセージをスイッチ レッグに送信して、コールを宛先に接続するようにスイッチに命令できます。
インテリジェント ペリフェラル IVR として使用される場合、Unified CVP はタイプ 3 またはタイプ 7 で機能できますが、タイプ 7 のほうが多少効率的です。これは、VRU レッグが不要になったときに、(コールが引き出されたことを VoiceXML ゲートウェイから通知されるのを待機するのではなく)Unified ICM から明確な指示を取得するためです。
前述したように、コールにはスイッチ レッグと VRU レッグという 2 つのレッグがあります。 各レッグに対して異なる Unified CVP ハードウェアを使用できますが、Unified ICM 機能の観点からは、VRU タイプ 5 として機能する PG を使用した Unified CVP(サービス ノード)と、VRU タイプ 7 として機能する別の PG を使用した潜在的に異なる Unified CVP があり、IVR アプリケーション(セルフサービス、キューイングなど)を完了します。
VRU タイプ 3 またはタイプ 7 を使用する Unified CVP アプリケーションの設定例については、次の URL から入手可能な最新バージョンの『Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP)』を参照してください。
(注) |
Cisco Unified ICM 7.1 は、タイプ 10 ネットワーク VRU を導入しています。 Unified ICM 7.1 以降を使用する Unified CVP のすべての新規実装には(VRU のみ(後述するモデル #4a)は除く)、この VRU を使用してください。 アップグレードした既存の顧客導入または Unified ICM 7.1 以降を実行していない導入には、タイプ 8 またはタイプ 2 VRU を使用してください。 |
VRU がトランスレーション ルート ID メカニズムを備えた IVR として機能する場合、Unified ICM はタイプ 8 またはタイプ 2 を使用し、トランスレーション ルート ID スキームの PG を介して VRU のサブ動作を指定します。 タイプ 2 およびタイプ 8 VRU はどちらもトランスレーション ルート メカニズムによって到達可能であり、VRU を制御するために PG が必要です。 ただし、コールを最終宛先に接続する方法が異なります。
タイプ 8 では、コールを VRU に配信するスイッチは、コールを VRU から取得して宛先またはエージェントに接続できます。
コールを VRU から取得してエージェントに配信する機能がスイッチにない場合は、タイプ 2 を使用してください。 その場合、IVR 処理が完了すると、Unified ICM は最終接続メッセージを(元のスイッチではなく)VRU に送信して、コールを宛先に接続します。 VRU はコールを受信すると、スイッチングの制御責任を負います。 このプロセスは、ハンドオフと呼ばれます。
相関 ID の場合と同様に、コールにはスイッチ レッグと VRU レッグという 2 つのレッグがあります。 Unified CVP はスイッチ レッグと VRU レッグのどちらにも使用できます。 たとえば、ネットワーク インターフェイス コントローラ(NIC)、NAM、または CICM が含まれる場合、Unified CVP は VRU レッグでタイプ 2 またはタイプ 8 として設定する必要があります。
VRU タイプ 8 またはタイプ 2 を使用する Unified CVP アプリケーションの設定例については、次の URL から入手可能な最新バージョンの『Configuration and Administration Guide for Cisco Unified Customer Voice Portal (CVP)』を参照してください。
ここでは、ネットワーク VRU タイプが Unified CVP 導入モデルにどのように関連するかについて説明します。 この項では、次のトピックについて取り上げます。
Unified ICM では、ネットワーク VRU はコンフィギュレーション データベース エンティティです。 アクセスには Network VRU Explorer を使用します。 ネットワーク VRU エントリには、次の情報が含まれています。
アクティブ コールに関連付けられるまでは、ネットワーク VRU コンフィギュレーション エントリには値はありません。 Unified ICM でこの関連付けが行われる場所は、次の 3 つです。
Protocol-Level コール フローに応じて、具体化する Unified ICM Enterprise はペリフェラルまたはカスタマー インスタンスを参照し、コールを VRU に転送する方法を決定します。 Unified ICM Enterprise は、コールが最初にスイッチ レッグに着信するときはスイッチ レッグ ペリフェラルに関連付けられたネットワーク VRU を調べ、トランスレーション ルート メカニズムを使用してコールが VRU に転送されているときは VRU レッグ ペリフェラルに関連付けられたネットワーク VRU を調べます。 相関 ID メカニズムを使用してコールが VRU に転送されているときは、カスタマー インスタンスに関連付けられたネットワーク VRU を調べます。
Unified ICM Enterprise は、ルーティング スクリプト内に RunExternalScript ノードがあるたびに、VRU スクリプトに関連付けられたネットワーク VRU も調べます。 Unified ICM は、指定されたネットワーク VRU にコールが現在接続されていると判断しない場合、VRU スクリプトは実行されません。
Unified ICM Enterprise Release 7.1 では、ネットワーク VRU タイプ 10 が導入されました。これにより、Unified CVP のネットワーク VRU のコンフィギュレーションが容易になります。 ほとんどのコール フロー モデルでは、単一のタイプ 10 ネットワーク VRU が、カスタマー インスタンス、スイッチ、および VRU レッグ ペリフェラルに関連付けられていたタイプ 2、3、7、または 8 ネットワーク VRU の代わりになることができます。 タイプ 7 または 8 をまだ必要とする唯一の主要なコール フロー モデルは、VRU のみ(後述するモデル #4a)です。
以前に推奨されていた VRU タイプは、Unified ICM Enterprise 7.1 でも、これまでどおり機能します。 新規インストールでは可能であればタイプ 10 を使用する必要があり、既存のインストールではオプションでタイプ 10 に切り替えることができます。
スタンドアロン セルフサービス モデルは、通常は Unified ICM VRU スクリプトとインターフェイスしないため、ネットワーク VRU 設定は関係ありません。 Unified ICM ラベル ルックアップを使用するスタンドアロン セルフサービス モデルは、Unified ICM の VRU スクリプトを使用しません。単純にルート要求を VRU PG ルーティング クライアントに発行するため、ネットワーク VRU は必要ありません。
このモデルでは、Unified ICM(したがって Unified CVP)は、コール スイッチングだけに責任を負います。 キューイングまたはセルフサービスは提供しないため、VRU レッグはありません。 したがって、この場合にはネットワーク VRU 設定は必要ありません。
このモデルでは、Unified CVP デバイスはスイッチと VRU レッグの両方として機能しますが、コール処理(.wav ファイルの再生またはユーザ入力の受け入れ)の発生前に、コールをスイッチ レッグから VRU レッグに転送する必要があります。 この場合は、すべての Unified CVP ペリフェラルをタイプ 10 ネットワーク VRU に関連付けます。
(注) |
タイプ 10 は Unified ICM 7.1 以降だけで使用可能であり、新規実装ではこのコンフィギュレーションを使用する必要があります。 Unified ICM 7.0 では、この場合はタイプ 2 ネットワーク VRU を使用する必要があります。 |
すべての着信番号を、タイプ 10 ネットワーク VRU に関連付けられたカスタマー インスタンスに関連付けます。 このコールによって実行されるすべての VRU スクリプトは、同じタイプ 10 ネットワーク VRU に関連付けられる必要があります。 必ずしも必要というわけではありませんが、ベスト プラクティスは、最初の RunExternalScript ノードの前に Unified ICM ルーティング スクリプトで SendToVRU ノードを実行することです。
(注) |
タイプ 10 は Unified ICM 7.1 以降だけで使用可能であり、新規実装ではこのコンフィギュレーションを使用する必要があります。 Unified ICM 7.0 では、タイプ 7 を使用してください。 |
このモデルでは、コールは最初に Unified CVP ではなく ICM-NIC インターフェイスを介して Unified ICM に着信します。 少なくとも最初は、Unified CVP はスイッチ レッグに関与しません。唯一の目的は VRU として機能することです。 ただし、使用される NIC の種類によっては、コールを受信した後にスイッチ レッグを引き継ぐ必要がある場合があります。 このモデルには実際には 2 つのサブモデルがあり、次の項でそれぞれについて説明します。
このサブモデルは、コールを一時的にネットワーク VRU(つまり、Unified CVP の VRU レッグ)に配信し、後でエージェントが使用可能になったときにコールを取得してそのエージェントに配信できる、完全に機能する NIC を想定しています。 さらに、コールを別のエージェント、あるいはキューやセルフサービスに再転送することをエージェントが要求できる場合に、NIC がエージェントからコールを取得して要求されたとおりに再配信できることを想定しています。
このモデルには、VRU へのコールの転送に相関 ID メカニズムが使用されるかトランスレーション ルート メカニズムが使用されるかに応じて、2 つの種類があります。 ほとんどの NIC(ほとんどの PSTN ネットワーク)は、コールを特定の宛先電話番号に転送できず、任意の相関 ID を一緒に転送できません(相関 ID 転送メカニズムを正しく機能させるために、宛先デバイスは相関 ID を Unified ICM に戻すことができます)。 したがって、ほとんどの NIC では、トランスレーション ルート メカニズムを使用する必要があります。
ただし、このルールにはいくつかの例外があり、その場合には相関 ID メカニズムを使用できます。 相関 ID を送信できる NIC には、Call Routing Service Protocol(CRSP)、SS7 Intelligent Network(SS7IN)、Telecom Italia Mobile(TIM)があります。 ただし、この機能は NIC の背後で接続される PSTN デバイスにも依存するため、PSTN キャリアを確認し、相関 ID が宛先に渡されるかどうかを判別してください。
NIC が相関 ID を送信できる場合、着信番号はすべて、タイプ 7 ネットワーク VRU に関連付けられたカスタマー インスタンスに関連付ける必要があります。 タイプ 7 ネットワーク VRU には NIC ルーティング クライアントに関連付けられたラベルが含まれている必要があり、すべての VRU スクリプトもその同じタイプ 7 ネットワーク VRU に関連付けられている必要があります。 ペリフェラルはネットワーク VRU に関連付けられている必要はありません。 ベスト プラクティスは、最初の RunExternalScript ノードの前に Unified ICM ルーティング スクリプト SendToVRU ノードを実行することです。
NIC が相関 ID を送信できない場合、着信番号はすべて、ネットワーク VRU に関連付けられていないカスタマー インスタンスに関連付ける必要があります。 ただし、Unified CVP ペリフェラルはタイプ 8 のネットワーク VRU に関連付けられている必要があり、すべての VRU スクリプトもその同じタイプ 8 ネットワーク VRU に関連付けられている必要があります。 この場合は常に、最初の RunExternalScript ノードの前に、TranslationRouteToVRU ノードをルーティング スクリプトに挿入する必要があります。 コールがキューに格納されているために VRU レッグに向かう場合は、通常、TranslationRouteToVRU ノードは Queue ノードの後にあります。 このようにして、要求されたエージェントがすでに使用可能な場合に、Unified CVP からの不要な配信および削除を回避できます。
このサブモデルは、VRU またはエージェントにコールを 1 回だけ配信できる、機能の低い NIC を想定しています。 コールが配信されると、コールが取得され、別の場所に再配信されます。 そのような場合は、Unified CVP がコールのスイッチングの制御責任を引き受けます。 Unified ICM の観点からは、このプロセスはハンドオフと呼ばれます。
この特定のサブモデルに該当するコールは、トランスレーション ルート メカニズムを使用してコールを VRU に転送する必要があります。 相関 ID メカニズムを使用してハンドオフを実装する方法はありません。
Unified ICM 7.1 でこのモデルを実装するには、着信番号はすべて、タイプ 10 ネットワーク VRU に関連付けられたカスタマー インスタンスに関連付ける必要があります。 VRU ラベルは、NIC ではなく Unified CVP ルーティング クライアントに関連付けられます。 Unified CVP ペリフェラルおよび VRU スクリプトは、タイプ 10 ネットワーク VRU に関連付けられる必要があります。 この場合は常に、最初の RunExternalScript ノードの前に、TranslationRouteToVRU ノードとそれに続く SendToVRU ノードをルーティング スクリプトに挿入する必要があります。 コールがキューに格納されているために VRU レッグに向かう場合は、通常、これらの 2 つのノードは Queue ノードの後にあります。 このようにして、要求されたエージェントがすでに使用可能な場合に、Unified CVP からの不要な配信および削除を回避できます。
Unified ICM 7.0 でこのモデルを実装するには、着信番号はすべて、タイプ 7 ネットワーク VRU に関連付けられたカスタマー インスタンスに関連付ける必要があります。 VRU ラベルは、NIC ではなく Unified CVP ルーティング クライアントに関連付けられます。 Unified CVP ペリフェラルはタイプ 2 のネットワーク VRU に関連付けられている必要がありますが、すべての VRU スクリプトはタイプ 7 ネットワーク VRU に関連付けられている必要があります。 この場合は常に、最初の RunExternalScript ノードの前に、TranslationRouteToVRU ノードとそれに続く SendToVRU ノードをルーティング スクリプトに挿入する必要があります。 コールがキューに格納されているために VRU レッグに向かう場合は、通常、これらの 2 つのノードは Queue ノードの後にあります。 このようにして、要求されたエージェントがすでに使用可能な場合に、Unified CVP からの不要な配信および削除を回避できます。
(注) |
2 つの異なる VRU 転送ノードが必要です。 最初の転送では、ハンドオフによってコールを NIC から転送し、Unified CVP をこのコールのスイッチ レッグ デバイスとして確立します。 物理的にはコールは入力ゲートウェイに配信されます。 2 番めの転送では、コールを VoiceXML ゲートウェイに配信し、Unified CVP をコールの VRU デバイスとしても確立します。 |
ホスト型実装では、Unified ICM システムの 2 レベルの階層が組み込まれます。 Network Applications Manager(NAM)が上位レベルに、1 つ以上の Customer ICM(CICM)がその下に展開されます。 NAM と CICM はどちらも完全な ICM であり、それらの間の通信リンクは Intelligent Network Call Routing Protocol(INCRP)と呼ばれます。 各 CICM は孤立した形式で機能します。他の CICM を認識せず、NAM が別の ICM であることも認識しません。 他の CICM への接続はありませんが、NAM への接続は INCRP NIC を介して行われます。
従来から、シスコのお客様はサービス プロバイダーであるため、ホスト型の設定を実装しています。 お客様は ICM コンタクトセンター サービスを複数の顧客に提供する必要があります。 顧客はそれぞれ独自の CICM 上でホストされ、NAM がコールをルーティングする責任を負います。コールはサービス プロバイダーに配信され、適切な顧客の CICM に配信されます。 個々の顧客は、それぞれの自社の構内にある PG に接続された独自の ACD を使用して、独自のコンタクトセンターを運営します。 一方で PG は、サービス プロバイダーにある、割り当てられた CICM に接続されます。 このようにして、サービス プロバイダーは NAM とすべての CICM を所有してホストしますが、すべての ACD は個々の顧客が所有してホストします。 それらの ACD の PG は、所有者はサービス プロバイダーですが、顧客の構内の ACD の横に展開されます。 サービス プロバイダー自身は独自の ACD を稼働する必要はありませんが、稼働することは可能です。その PG は、サービス プロバイダーに割り当てられた CICM に接続するか、実際に NAM 自体に接続できます。
ICM スクリプティングに関しては、すべての着信コールによって、最初に、適切なターゲット顧客を識別する主要な責任を負う適切な NAM ルーティング スクリプトが起動されます。 次に、スクリプトによって、その顧客の CICM 上で実行されているルーティング スクリプトに制御が委任されます。 CICM ベースのルーティング スクリプトは、コールの配信先の適切な ACD を選択でき、必要なトランスレーション ルート ラベルを NAM に返すことができます。 NAM は、指定されたターゲット ACD にコールを配信するようにルーティング クライアントに命令できます。 CICM ルーティング スクリプトは、現在はコールを取得できる ACD がないか、コールを取得する ACD をまだ識別できないと判断した場合、コールをサービス制御 VRU のキューに展開するように NAM に要求できます。 CICM ルーティング スクリプトは、ルーティング決定が行われるまで、NAM 経由でその VRU にネットワーク VRU スクリプト要求を発行できます。
実際には NAM と CICM のアーキテクチャは柔軟であるため、その他にもさまざまな方法で使用できます。 ホスト型をご利用の多くのお客様は、単純に多くのコールまたは PG を ICM セットアップで取得するための方法として、このトポロジを使用しています。 カスタマー コンタクトセンターではなくアウトソーサーのために CICM を使用するお客様もあります。 そのような場合、おそらく NAM は CICM と同じ数のコールを処理し、CICM マシン自体は NAM から遠く離れて展開されます。 また、NAM と CICM のアーキテクチャは、すべてのコンタクトセンターが TDM ベースの ACD で実行されていたときに設計されました。 ダイレクト エージェント ルーティングを備えた Unified CM(つまり Unified CCE)に基づく VoIP ルーティングおよび ACD の追加により、状況は非常に複雑になりました。
Unified CVP が関係する場合、通常は、NAM に接続されてサービス プロバイダーのデータセンター内に物理的に展開された、セルフサービスまたはキューイング プラットフォームとして使用されます。 したがって、従来のサービス プロバイダーは、コールを適切な顧客所有の ACD にルーティングするだけでなく、それらの ACD に対してキューに格納されたコールの制御を保持し、基本的なプロンプト/コレクト機能または完全なセルフサービス アプリケーションを顧客に提供できます。 後者の場合は、通常、Unified CVP VXML Server がネットワークに組み込まれます。 顧客のニーズに応じて、Unified CVP VXML Server は、サービス プロバイダーがホストする場合もあれば、顧客がホストする場合もあります。 また、サービス プロバイダーがセルフサービス アプリケーションを作成して所有する場合もあれば、顧客が作成して所有する場合もあります。 顧客が Unified CVP VXML Server を所有またはホストできるようにすることは、セルフサービス アプリケーションでバックエンド サービスを参照する必要がある場合に便利なソリューションです。 顧客はその対話を自社ネットワーク内で制御しながら、VoiceXML over HTTP だけをサービス プロバイダーの VoiceXML ゲートウェイに送信できます。
多くのホスト型環境では、特にサービス プロバイダー自身が PSTN キャリアである場合、実際のコール ルーティングはすべて ICM NIC 経由で行われます。 その意味では、これらの展開はモデル #4b:NIC 制御プレルーティングのみを使用する VRUと非常に似ています。 同じ状況は、(通常は)ICM SS7 NIC を使用してコールをルーティングするために PGW が使用されている場合にも該当します。 ただし、サービス プロバイダーが NIC インターフェイスをまったく持たず、すべてのコールが T3 や E3 などの TDM インターフェイス経由で着信することが多くあります。 そのような場合、Unified CVP はスイッチ レッグおよび VRU レッグとして使用されます。 この状況は、モデル #3a:ICM Micro-Apps を使用する包括モデルまたはモデル #3b:Unified CVP VXML Server を使用する包括モデルと同様です。
前述したように、Unified CVP が従来の方法で純粋にネットワーク VRU として使用される場合は、NAM で接続されます。 ただし、さまざまな要件によって Unified CVP が、代わりに、または追加で、CICM レベルで展開される場合があります。 Unified CVP コンポーネントの展開場所を考慮する際には、次のガイドラインが適用されます。
Unified CM または ACD によって開始されたコールを追加すると、制約が追加されます。 これらのデバイスはどちらも ICM の観点からは ACD と見なされ、ほとんどの場合 CICM レベルで接続されます。 これらを(既存のコールの継続ではなく)新規コールと想定して、ルート要求が ACD から発生し、結果のラベルが ACD に返されます。 Unified CM も ACD も転送において相関 ID を送信できないため、トランスレーション ルート転送方式のみを使用できます。 この制限は、転送先(Unified CVP など)も NAM レベルではなく CICM レベルで接続する必要があることも意味します。
コールが新規ではなく既存のコールの継続である場合、コールはエージェントからエージェントへの既存の着信発信者の転送試行です。 お客様は、これらの転送をブラインド ネットワーク転送(つまり、最初のエージェントはドロップされ、発信者は別のエージェントに配信されるか別のエージェントのキューに格納される)またはウォーム コンサルタティブ転送(つまり、発信者が保留状態になっている間に、最初のエージェントは別のエージェントと会話するか別のエージェントのキューで待機し、発信者が 2 番目のエージェントと会話しているときに最初のエージェントが切断する)にする場合があります。 これらの転送には、次のガイドラインが適用されます。
(注) |
この場合には、NAM レベルの Unified CVP コール サーバを使用できないため、顧客は追加の専用 Unified CVP コール サーバを CICM レベルで展開する必要がある場合があります。 |
(注) |
この場合には、NAM レベルの Unified CVP コール サーバを使用できないため、顧客は追加の専用 Unified CVP コール サーバを CICM レベルで展開する必要がある場合があります。 |
ホスト型環境では、対象となる NAM と CICM という 2 つの ICM システムを常に考慮する必要があります。 ネットワーク VRU タイプは、NAM と CICM で別々に設定されます。
新しいコールは NIC または Unified CVP のいずれかから NAM に到達し、Unified CVP VRU レッグ デバイスを認識します。 NAM ネットワーク VRU タイプは、それらのデバイスとともに動作する独立した ICM であるかのように設定する必要があります。 ネットワーク VRU タイプを設定する場合、CICM から発信された転送ラベルは無視できます。
新しいコールは、インテリジェント ネットワークの Network Call Routing Protocol(INCRP)NIC から CICM に到達します。 NAM から着信できるすべての着信番号は、タイプ 7 ネットワーク VRU に関連付けられたカスタマー インスタンスに関連付ける必要があります。 そのネットワーク VRU をすべての VRU スクリプトに関連付け、NAM ネットワーク VRU 定義で必要となるラベルと同じラベルを指定しますが、INCRP NIC をそのルーティング クライアントとします。 それ以外は、ペリフェラルにはネットワーク VRU を設定しません。
この項の説明は、キューイングに Cisco IP IVR ではなく Unified CVP を使用するすべての ACD およびすべての Cisco Unified Communications Manager(Unified CM)統合に適用されます。 Unified CVP に関して、これらのデバイスは次の特性を共有します。
Unified CM ユーザまたは ACD ユーザは、次の理由のいずれかでルート要求を発行します。
また、Unified CM ユーザは、次の理由のいずれかでルート要求を発行します。
前述の各コールによって、Unified ICM ルーティング スクリプトが起動されます。 スクリプトは、使用可能な宛先エージェントまたはサービスを検索し、適切な宛先がある場合は、対応するラベルを ACD に返信します。または、既存のコールをブラインド転送する場合は、元の発信者のスイッチ レッグ デバイスに返信します。 コールをキューに格納する必要がある場合、または最終の宛先がエージェントまたはサービスではなくセルフサービス アプリケーションである場合、スクリプトは VRU トランスレーション ルート ラベルを ACD に返信するか、または既存のコールをブラインド転送する場合は元の発信者のスイッチ レッグ デバイスに送信します。
前述のシーケンスでコールが Unified CVP の VRU レッグ デバイスに転送された場合、コールを VoiceXML ゲートウェイに配信するために別の転送が行われます。 これらのイベントが発生するには、次の Unified ICM コンフィギュレーション要素が必要です。
Unified ICM は、コールのエージェントまたは ACD 宛先ラベルを選択するときに、そのラベルを受け入れることができるルーティング クライアントをリストしているものを見つけようとします。 既存のコールのブラインド転送ではない ACD または Unified CM により発生したコールの場合、使用可能な唯一のルーティング クライアントは ACD または Unified CM です。 コールが Unified CVP に転送されると、ハンドオフ動作のために、使用可能な唯一のルーティング クライアントは Unified CVP スイッチ レッグになります。 ただし、既存のコールのブラインド転送の場合、(1)元のコールを配信した Unified CVP コール サーバ スイッチ レッグまたは(2)ACD または Unified CM という 2 つのルーティング クライアントが使用可能です。 Unified CVP により発生するコールの場合、Unified CVP ペリフェラルの [Unified ICM Setup] 画面で [Network Transfer Preferred] ボックスをオンにすることによって、Unified CVP ラベルを ACD または Unified CM ラベルよりも優先させることができます。
Unified CVP を使用してネットワーク転送を行う場合、エージェントは、[Network Transfer Preferred] オプションを使用して新しい宛先に発信者をブラインド転送します。 このシナリオでは、エージェントは CTI エージェント デスクトップ(電話自体ではない)を使用して転送を起動します。 CTI エージェント デスクトップに加えて、エージェントは、Unified ICM ダイヤル番号計画を使用します。 CTI ルート ポイントと同じ DN で設定された場合、Unified ICM ダイヤル番号計画によって Unified ICM は転送を代行受信し、転送コマンドを JTAPI を介して Unified CM に送信しないで Unified ICM ルーティング スクリプトを実行します。 Unified ICM スクリプトがラベルを返すと、そのラベルはネットワーク ルーティング クライアント(Unified CVP)に使用され、発信者は新しい宛先に直接送信されます。 このコンフィギュレーションにより、エージェントが Unified CM CTI ルート ポイントを使用してネットワーク転送を開始する場合に発生する可能性があるタイミングの問題が回避されます。
サードパーティ製の TDM VRU は、次の方法のいずれかで使用できます。
最初の場合と 2 番めの場合、Cisco Unified Communications Manager と ACD のコールの導入モデルとサイジングの意味の項で説明されているように、VRU は ACD と同様に機能します。 ACD のように、VRU は別の送信元から着信するコールの宛先になることができます。 コール コンテキスト情報を保持するために、コールをそのようなデバイスにトランスレーション ルーティングすることもできます (この動作は、TranslationRouteToVRU ではなく従来のトランスレーション ルートと呼ばれます)。また、ACD のように、VRU は独自のルート要求を発行し、ルーティング スクリプトを起動してコールを後続の宛先やセルフサービス処理用の Unified CVP にも転送できます。 このような転送では、ほとんど常にトランスレーション ルート転送メカニズムが使用されます。
3 番めの場合、VRU は Unified CVP のスイッチ レッグまたは Unified CVP の VRU レッグの代わりとなるか、完全に Unified CVP の代わりとなることもできます。 そのような展開は、このマニュアルの対象範囲外です。
Unified CVP の Release 9.0(1) では、PSTN ゲートウェイ トランクおよび DS0 情報を着信 SIP コールから Unified ICM に渡す機能が追加されています。
ICM で受信された PSTN ゲートウェイ トランクおよび DS0 情報には 2 つの目的があります。
PSTN トランク グループ データは、次に示すように PSTN ゲートウェイから SIP INVITE メッセージで着信します。
Via: SIP/2.0/UDP 192.168.1.79:5060;x-route-tag="tgrp:2811-b-000";x-ds0num="ISDN 0/0/0:15 0/0/0:DS1 1:DS0";branch
Unified CVP では、PSTN トランク グループ情報を解析して Unified ICM に渡すために、次のロジックが使用されます。
トランク使用状況機能では、ゲートウェイは、リアルタイム Unified CVP ルーティングのためだけでなく、Unified ICM レポーティングおよびスクリプティングのために、メモリ、DS0、DSP、および CPU のステータスを Unified CVP にプッシュできます。
この機能では、リソース データを Unified CVP に送信するためにプッシュ方式が使用されるため、リソースはより詳細にモニタされ、デバイスのダウンやリソース不足の際にフェールオーバーがより迅速に行われます。
トランク使用状況ルーティングは、Unified CCE ルータのトランク グループ ステータスを更新するために使用することもできます。 (ICM スクリプトによる)PSTN コールは、SS7 NIC からのプレルートを使用してルータをクエリーして、Unified CVP へのポスト ルートに使用できる最適な入力ゲートウェイを確認できます。
(注) |
DS0 は、ゲートウェイ上の空きトランク数に関する使用状況情報を提供するデータ回線です。 |
サーバ グループ要素ポーリング機能を IOS ゲートウェイ トランク使用状況機能と組み合わせると、ハイアベイラビリティ コール シグナリングのための、より迅速なフェールオーバーがソリューションに備わります。 この組み合わせを推奨します。
ユーザツーユーザ情報(UUI)は、ISDN 補足サービスを使用してユーザツーユーザ サービスとして提供されるデータです。 UUI 機能により、メッセージごとに最大 128 オクテットのデータを使用して、コール セットアップおよびコール切断中の発信 ISDN 番号と着信 ISDN 番号間の情報転送が可能になります。
Unified CVP 転送および切断を伴うコールの場合、UUI 機能を使用して、PSTN から GTD で提供された ISDN データを Unified ICM ルータに渡し、Unified ICM からサードパーティ製の ACD に渡すことができます。
入力/出力ゲートウェイは、CTI アプリケーションで使用するために、およびサードパーティ製の ACD 統合の向上のために、UUI フィールド内のアプリケーション固有のデータを使用できます。
たとえば、外部システムからのデータ(サードパーティ製の IVR からの発信者が入力した番号など)をキャプチャし、そのデータを新規コールで Unified ICM に渡すことができます。
Unified CVP は、Unified CVP の発信方向でエージェントや IVR などに、UUI を 16 進数にエンコードした形式で送信できます。
UUI は ISDN データですが、Unified CVP およびゲートウェイは、VoIP 側での SIP メッセージ内の ISDN データのトンネリングをサポートしています。 データは、Generic Type Descriptor(GTD)コンテンツ タイプで SIP メッセージのコンテンツ本文にカプセル化できます。
RTP メディア ポートおよびコーデック情報は SDP 本文タイプとして定義されますが、ISDN データは IOS ゲートウェイによって Generic Type Descriptor 本文タイプにカプセル化されます。 RTP データと ISDN データの両方が TDM ゲートウェイを介して Unified CVP に送信される場合、両方の本文タイプが SDP 部分と GTD 部分の両方を含む multipart/mixed MIME タイプで送信されます。
拡張 UUI 機能をオンにするには、ゲートウェイで次の設定が必要です。
voice service voip signaling forward unconditional
UUI は、ICM スクリプトによって設定でき、Unified CVP によって抽出して SIP メッセージ内で再送信できます。
UUS,3,<converted Hex value of data from ICM>GTD パラメータ値の残りの部分は維持され、発信者 GTD から着信した値が保持されます。
(注) |
Unified ICM からの変更された UUI は user.microapp.uui ECC 変数または Call.UsertoUserInfo 変数を使用して渡されます。 |
(注) |
両方の変数が使用されている場合は、Call.UsertoUserInfo が優先されます。 |
変更された GTD は、IP からの発信者および TDM 発信者を含む CVP SIP B2BUA から発信 INVITE MIME 本文に設定されます。 接続済みのコールでアウトパルス転送の DTMF ラベルが受信された場合、UUI が Unified ICM によって渡される場合にのみ GTD とともに BYE が送信されます。 BYE は SIP INFO の直後に DTMF で送信されます。
IF ノードなどでコール ECC 変数 user.microapp.uui および Call.UserToUserInfo 変数を調べることにより、Unified ICM スクリプトで UUI を抽出します。 これらの変数のいずれかで SET ノードを使用することによって、コールの発信方向で変数を設定できます。
Call.UserToUserInfo の設定が ECC 変数の使用よりも優先されます。
(注) |
Unified CVP は、UUI を Unified ICM から受信した場合のみ、DTMF ラベルで BYE メッセージを送信します。 |
BYE メッセージが受信された場合、受信された BYE の GTD が使用され、他のレッグで送信されます。
次の例に示すように、入力ゲートウェイは、UUI/UUS を持つ GTD が VoIP 側で転送されるように、signaling forward unconditional を使用して設定してください。
voice service voip signaling forward unconditional
Unified CCE スクリプトで UUI が設定されている場合、および REFER コール フローが使用されている場合、UUI は MIME 本文に展開され、ATT IP フリーダイヤル NSS 形式に従って 16 進数にエンコードされます。 これは、302 リダイレクト応答にも適用されます。
REFER/302 メッセージ内の UUI の NSS MIME 本文形式の例:
VER,1.00 PRN,t1113,*,att**,1993 FAC, UUS,0,(hex encoded UUI string here)
カスタム SIP ヘッダー機能により、ICM スクリプト内の変更のために、Unified CVP は選択された SIP ヘッダー情報を Unified ICM と受け渡しできます。 この機能により、サードパーティ製の SIP トランクおよびゲートウェイとの SIP 相互運用における柔軟性が大幅に高まります。
Unified CVP では、ICM スクリプト内の操作のために 1 つ以上の SIP ヘッダーを Unified ICM に渡すことができます。 Unified CVP 管理者は、Unified CVP Operations Console Server のユーザ インターフェイス(Operations Console)を使用して、特定のヘッダーを選択するか、ヘッダーとそのヘッダー内の特定のパラメータを選択できます。 これらの SIP ヘッダーは、CVP ICM サブシステムから Unified ICM に送信される新規コールおよび要求命令メッセージの SIPHeader フィールドで Unified ICM に渡すことができます。
ICM スクリプト内の変数にアクセスするには、Call.SIPHeader フィールドにアクセスします。 このフィールドを設定すると、Unified CVP はそのデータを、IVR またはエージェント、あるいは REFER または 302 リダイレクト メッセージへの発信 SIP コール内で使用するようになります。
ヘッダー データを Unified ICM に送信するために使用できる容量は限られており、255 バイトで切り捨てられます。 SIP プロトコルの RFC によって、共通ヘッダー フィールド名を省略形で表すメカニズムが提供されています。 したがって、ヘッダーを Unified ICM に渡す前に、RFC 3261(および新しく定義されるヘッダー用のその他の RFC)で定義されている簡潔なヘッダー形式がヘッダー タイトルに対して使用されます。
(注) |
すべてのヘッダーに簡潔な形式があるわけではありません。 たとえば、P ヘッダーつまりプライベート ヘッダー(P-Asserted-Identity など)には簡潔な形式がない場合があり、そのため完全なヘッダー名が ICM に渡されます。 |
(注) |
簡潔なヘッダー省略形を定義している RFC3261 の表を参照してください。 |
次の例は、Operations Console SIP コンフィギュレーション画面の設定に基づいて Unified ICM に送信されるストリングの形式を示しています。
"User-to-User: 123456789" "f:Name <sip:from@127.0.0.1:6666>;param1;param2|v:SIP/2.0/UDP viaHost"
データは、この例のようなスクリプトのストリング操作構文で解析できます。
注意 |
構文チェックはありません。 Operations Console でのヘッダーの追加または変更中に構文チェックはありません。 ヘッダーが正しい SIP 構文となるように注意する必要があります。 Operations Console 入力で許可されない文字は、セミコロンとカンマだけです。これらはコンフィギュレーションを格納するために内部的に使用されるためです。 通常、ヘッダー構文に問題がある場合、SIP スタック解析例外のために INVITE が送信されないことが CVP ログに示され、コールは中止されます。 それ以外には、必須の SIP ヘッダーが誤って変更された場合にコール自体が予期しない宛先に送信されることや、メッセージが RFC に準拠していない場合に受信者がコールを処理できないことがあります。 |
この機能の目的は、発信 Unified CVP 転送の SIP ヘッダーを変更するためのスクリプト可能オプションを提供することです。 発信 SIP INVITES だけで SIP ヘッダー値を指定できます。 指定には、ヘッダー値の追加、変更、または削除を含めることができます。
(注) |
SIP ヘッダー変更機能は、必要に応じて SIP ヘッダーを調整できる強力なツールです。 SIP プロファイルを適用するときは注意して、問題の解決とは逆にプロファイルによって相互運用の問題を発生させないようにします。 Unified CVP には、INVITE メッセージだけの発信 SIP ヘッダーを追加、変更、または削除する柔軟性があります。 Unified CVP を数多くのシナリオで導入して、サードパーティ製のデバイスとの相互運用を促進できます。 |
発信 SIP ヘッダー機能では、必須 SIP ヘッダーは削除または追加できません。 基本的な必須ヘッダー(To、From、Via、CSeq、Call-Id、および Max-Forwards など)には変更オプションのみを使用できます。 ICM スクリプト エディタに変更のチェックはありません。変更のチェックは、実際は java SIP スタック レイヤにより DsSipParserException をスローすることによって実施されます。
通常、Unified ICM では、フィールドが 255 文字を超えた場合は切り捨てられます。 SIP サブシステムで、Unified ICM スクリプトから与えられたストリングを持つヘッダーの更新または追加に問題がある場合は、Unified CVP ログに WARN タイプのメッセージが表示されるか(DsSipParserException がある場合)、INVITE が送信されて受信者側で予期しない結果となります。
この機能は、発信 SIP INVITES だけ(再 INVITE ではなく初期の INVITE だけ)に適用できます。 INVITE に対する変更は、送信される直前に適用されます。 適用できる変更に制限はありません。
スクリプト エディタでは、SIPHeaderInfo のコール変数文字列を設定するには、Set ノードが使用されます。
Unified ICM スクリプトでは、ヘッダー、操作、および値をチルダ文字で区切り、パイプ文字を使用して操作を連結します。
CVP 9.0(1) のトラブルシューティング情報は、CVP 9.0 Doc-Wiki Troubleshooting ページ(http://docwiki-dev.cisco.com/wiki/Troubleshooting_Tips_for_Unified_CVP_9.0%281%29)にあります。
サービス コールバックによって、発信者が保留状態またはキューで待機する時間が短縮されます。 この機能により、基準を満たす発信者に対して、エージェントを電話で待機するのではなくシステムによってコールバックを受けるオプションを提供できます。 Unified CVP によってキューに格納されている発信者は、切断し、後でエージェントが使用可能になる少し前にコールバックを受けることができます(プリエンプティブ コールバック)。 この機能は、発信者が電話でエージェントを待機しなくても済むように、発信者へのサービスとして提供されています。
プリエンプティブ コールバックでは、顧客がエージェントへの接続を待機する時間は変わりませんが、発信者は切断でき、音楽を聴きながらキューに残っている必要がなくなります。 キューに残っている発信者とコールバック処理を受けている発信者は、コールに応答するエージェントには同じように表示されます。
(注) |
コールバックが指定の時間に行われるようにスケジュールすることは、この機能の一部ではありません。 |
発信者は、システムによるコールバックを受けることを決定した場合、名前と電話番号を残します。 要求はシステム内に残り、EWT の起動時に、発信者へのコールバックが行われます。 発信者がコールに応答して元の発信者であることを確認すると、発信者は短時間待機した後にエージェントに接続されます。
サービス コールバック機能の一般的な使用は、次のパターンに従います。
(注) |
データベースがアクセス不可の場合は、発信者にコールバックは提供されず、発信者はキューに入れられます。 |
発信者への到達試行を設定可能な最大回数および頻度だけ実行した後も発信者に到達できない場合、コールバックが中止され、それに応じてデータベース ステータスが更新されます。 ビジネス ルールに基づいて手動でのコールバックが必要かどうかを判断するために、レポートを実行できます。
『Configuration and Administration Guide for Cisco Unified Customer Voice Portal』(http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html)ガイドを参照してください。サービス コールバック機能を提供するスクリプトの機能に関するコール フローの説明があります。
次の情報は、コールバックの時間がどのように決定されるか、導入されている決定プロセスおよび計算方式の概要を提供します。
最初に、使用される主な用語の定義を示します。
コールバックが同意したサービス レベル内になるように設計された後の、キュー時間の平均コールバック。 ただし、両方のシナリオが望ましくないため、サービス コールバックは、発信者のコールバックが早すぎたり遅すぎたりしないようにも設計されています。 一方で、発信者のコールバックが早すぎる場合は、より長くキューで待つ可能性がありますが、コールバックが遅すぎる場合は、コール センター エージェントがアイドルであり、コールを待機している可能性が高くなります。
使用可能なエージェント数が増減したときや、平均処理時間が変わったときなど、コール センターの動的性が変化すると、残りの時間も変わります。 したがって、サービス コールバックでは、平均キュー解除時間は、キュー内のコール数、平均処理時間、準備中のエージェントとトーキング状態などのさまざまな要因に基づいて計算されます。
平均キュー解除時間は、コールがキューに入ったとき、およびキューから出たときに更新されます。 この情報は、キュー時間のコールバックを低減し、コールを待機しているコール センター エージェントのインスタンスを最小限に抑えるための計算に使用されます
ここでは、キューのコールのコールバックの時間を判断するために使用されるプロセスについて詳しく説明します。 また、平均キュー解除時間の計算に使用されるメソッド(または式)、またはキュー内のすべてのサービス コールバック コールの残り時間を更新するために使用されるメソッドを示します。
コールバック時間を判断するためのプロセスは次のとおりです。
サービス コールバック機能は Unified ICM スクリプトを使用して実装されます。 変更可能なサンプル スクリプトが、Unified CVP 9.0(1) インストール メディアの \CVP\Downloads and Samples\ フォルダで提供されています。 これらのスクリプトでは、前述した基準に応じて、発信者にコールバックを提供するかどうかを決定します。 提供されているファイルは次のとおりです。
サンプル Studio スクリプトに付随するサンプル オーディオ ファイルが、<CVP_HOME>\OPSConsoleServer\CCBDownloads\CCBAudioFiles.zip に、メディア ファイル インストール オプションの一部としてインストールされます。
サンプル スクリプトは、デフォルトの場所である「http://<server>:<port>/en-us/app」を使用するように設定されています。 サンプル オーディオ ファイルのデフォルトの場所を、ニーズに合わせてサンプル スクリプト内で変更する必要があります(つまり、<server> および <port> で、メディア サーバの IP アドレスとポートを代わりに使用します)。
サービス コールバック機能には、次の前提条件と注意事項が適用されます。
(注) |
サービス コールバックでは、発信コールは他の出力ゲートウェイを使用して行うことができません。 |
ポスト コール調査は、通常はコンタクトセンターによって、顧客がコール センター利用経験に満足したかどうかを判別するために使用されます(探していた回答をセルフサービスを使用して見つけたか、コール センター エージェントの対応はよかったか、など)。
Post Call Survey(PCS; ポスト コール調査)機能を使用すると、エージェントが切断した後で、発信者がポスト コール調査を要求する DNIS に転送されるように、コール フローを設定できます。
ポスト コール調査の要求に対して、発信者は次の 2 つの応答から選択できます。
レポートのために、ポスト コール調査コールは元の着信コールと同じ Call-ID およびコール コンテキストを持ちます。
通常は、コール中に発信者に対して調査に参加するかどうかの確認が行われます。 着信番号に基づくシステム コンフィギュレーションによって、エージェントとの会話の終了時にポスト コール調査が起動されるかどうかが決定される場合もあります。 顧客がエージェントとの会話を完了すると、顧客は自動的に調査にリダイレクトされます。 ポスト コール調査は、最後のエージェントからの切断イベントによって起動されます。
顧客は、プッシュホン電話機のキーパッドまたは ASR/TTS で音声を使用して、調査中の質問に応答できます。 Unified CCE の観点からは、ポスト コール調査コールは別の通常のコールと同じです。 ポスト コール調査中に、元の顧客コールからコール コンテキスト情報が取得されます。
ポスト コール調査機能を設計する際は、次の条件に従ってください。