組み込みブリッジ（BIB）を備えたIP フォンを使用するエージェントおよびスーパーバイザがエージェント グリーティングを利用することができます。上記エージェントは、通常、コンタクト センター内に位置します。エージェント グリーティングで使用される電話機は、以下の要件を満たす必要があります。

• 電話機には、BIB 機能が必要です。

  Note	BIBを無効にすると、システムはエージェント グリーティングのコール フローに会議ブリッジを使用しようとして、警告イベントが発生します。

• 電話機のファームウェアが最新であることを確認します。(通常、Unified CM のインストールをアップグレードすると、電話機のファームウェアは自動的にアップグレードされます)。

• Contact Center Enterprise でサポートされる電話機の一覧の詳細については、https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-device-support-tables-list.htmlの 互換性マトリクス を参照してください。

1. 着信コールは、 CUBE または CVP の TDM ゲートウェイから受信します。

2. CVP は着信コールを Unified CCE に送信します。

3. Unified CCE は、CVP にコールのキューに入るよう指定します。

4. CVP は コールを VRU 処理のために音声ブラウザに送信します。

5. エージェントが使用可能な場合、Unified CCE は、エージェント番号を CVP に送信します。

6. CVP は、着信コールを Unified CCE に送信します。

7. Unified CM によって、エージェント電話への接続が確立されます。

8. 発信者は、エージェントの電話機に接続し、ringback の可聴応答が停止します。

9. Unified CCE が、どの CVP が呼び出されるか決定し、Unified CM に指示をして、電話機 BIB が CVP へのストリームを開くように伝えます。

10. Unified CCE また、CVP は握手して、CVP のトリガーを設定し、どのグリーティングを再生するかを知らせます。

11. CVP では、音声のブラウザに対して、Media Server がグリーティングを再生するように指示します。

12. 電話機の BIB がグリーティングを合成します。グリーティングが再生されると、CVP が切断され、エージェントが発信者と話しをします。

CVA アプリケーションで取り扱う概念を次に示します。これらの概念の詳細については、https://cloud.google.com/dialogflow/docs/ に記載されている Google の Dialogflow のマニュアルを参照してください。

Note	CVA 機能は、VVB のみでサポートされます。VXML ゲートウェイではサポートされていません。

以下の要件に従って、Cisco アウトバウンド オプションを実装します。

• エージェント ベースのキャンペーンで VRU への破棄を設定します。テレマーケティング法では、こういった行為が必要になる場合があります。

• キャンペーン マネージャは Logger と同じシステム上で実行されているため、連絡先リストの大規模なインポートおよび着信拒否リストのスケジュールは業務時間外にスケジュールします。

• Cisco アウトバウンド オプション用に設定されたエージェントにCisco IP Communicator ソフト フォンは使用させないでください。IP Communicator は、エージェントへの顧客のコールの転送に不要の遅延をもたらす可能性があります。

• IPv6 クライアントは、アウトバウンド オプションにインポートすることはできません。

• Finesse IP フォン エージェント (IPPA) は、Cisco アウトバウンド オプションをサポートしていません。

• 冗長キャンペーンマネージャ、アウトバウンド オプションインポーター、およびデータベースを使用すると、データベースのサイズが大きくなります。

  • 受信不可レコードには、より多くのスペースが必要になります。比較のために、6 千万 DNC レコードには、約 1 GB のディスク容量が必要です。

多くのアウトバウンド オプション展開では、すべてのコンポーネントが集中化されているため、考慮すべき WAN ネットワーク トラフィックはありません。

アウトバウンド コール センターが 1 つの国（たとえばインド）にあり、顧客が別の国（たとえば米国）にある場合、以下の条件で WAN ネットワーク構造を検討すべき展開もあります。

• 分散型アウトバウンド オプション展開で、WAN によって音声ゲートウェイがアウトバウンド オプション ダイヤラ サーバから分離されている場合。

• VRU キャンペーンへの転送に Unified CVP 展開を使用して、Unified CVP サーバが WAN によってアウトバウンド オプション ダイヤラ サーバから分離されている場合。WAN トラフィックを減少するため、独自の Cisco Unified SIP プロキシ サーバをローカル クラスタに含む Unified CVP を提供します。

• VRU キャンペーンへの転送用に SIP ダイヤラ ソリューションを展開する場合、SIP ダイヤラ向け Cisco Unified SIP プロキシ サーバは WAN によってアウトバウンド オプション ダイヤラ サーバから分離されます。

• サードパーティの録音サーバが WAN でアウトバウンド オプションダイヤラ サーバから分離されている場合は、録音サーバを音声ゲートウェイに対してローカルに設定します。

アウトバウンド オプション展開を適切に行うには、適切な帯域幅プロビジョニングを行うことが重要です。

コールバック スクリプトでは、発信者にサービス コールバックを提供する基準を確立することができます。確立できるコールバック基準の例は以下の通りです。

• 顧客ごとの平均コール処理時間に基づくと、キュー内の顧客の予想待機時間が最大数分を超過しています。

  Note	含まれているサンプル スクリプトは、この方式を使用してコールバックの適格性を判断しています。

• 顧客に割り当てられた状態。ゴールドの顧客に電話をかける代わりにコールバックする機会を提供することができます。

• 顧客が要求する特定のサービス。コールバックの基準として、セールス コールまたはシステム アップグレードを確立することができます。

発信者がコールバックを選択した場合、名前と電話番号を残します。顧客の要求はシステムで保持されます。予測される待機時間 (EWT) の値に達すると、システムは発信者にコールバックを発信します。発信者がコールに応答して元の発信者であることを確認すると、発信者は短時間待機した後にエージェントに接続されます。

Note	サービス コールバックは IP から発信されたコールでもサポートされます。

この機能の通常のコール フローは、以下のパターンをとります。

1. 発信者が Unified CVP に着信して、コールが通常の VRU 環境で処理されます。

2. Call Studio および Unified CCE サービス コールバック スクリプトは、発信者がルールに基づいてコールバックに相応しいかを判断します。

3. 発信者が資格がある場合、システムは EWT をアナウンスして、エージェントが応答可能になると、発信者にコールバックします。

4. 発信者は、以下の操作を選択します。

   1. 発信者がコールバック機能を使用しない場合は、通常どおりキューイングが継続されます。

   2. 発信者がコールバックを受ける場合、名前の記録と電話番号のキー入力が発信者に要求されます。

5. コールバック情報をログに記録するデータベース レコードが書き込まれます。

   Note	データベースにアクセスできない場合には、システムは発信者にコールバックしません。

6. 発信者の通話が TDM サイドから切断されます。ただし、Unified CVP および Unified CCE のコールの IP 側は依然としてアクティブ状態です。このことにより、コールは同じキュー位置で保持されます。キュー音楽は再生されないため、この間に使用される音声ブラウザのリソースは、実際にキュー内にある発信者のリソースよりも少なくなります。

7. 適切なエージェントが対応可能に近づくと (コールバック スクリプトで判断)、システムが該当顧客にコールバックします。コールバックの際には、正しいユーザがコールを受け入れるようにするために、記録された名前が通知されます。

8. VRU セッションは、発信者に正しい相手であること、また、コールバックの準備ができていることを確認するように依頼します。

   システムがコールバック番号に到達できない場合（ビジー回線、RNA、ネットワークの問題等）、コールはエージェントに送信されません。また、発信者が正しいユーザであるかどうかが確認されない場合も、コールはエージェントに送信されません。エージェントが電話にでるのは必ず相手が待機している時です。システムでは、エージェントが電話に出るまでに発信者がすでに電話に出ていることを想定しています。

   この機能はプリエンプティブ コールバックと呼ばれます。これは、システムが、エージェントが応答する際に発信者は回線上におり、発信者の待機時間が最小限であることを想定するためです。

9. 通常どおり、コール コンテキストがエージェント画面ポップに表示されます。

構成可能な再試行回数および頻度の後もシステムが発信者に到達できない場合、コールバックはキャンセルされ、データベース上の状態は適切に更新されます。ビジネス ルールに基づいて手動でのコールバックが必要かどうかを判断するために、レポートを実行できます。

サービス コールバック機能を提供するスクリプトの関数のコール フローの詳細については、https://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html の Configuration Guide for Cisco Unified Customer Voice Portal を参照してください。

サービス コールバック機能の設計に関しては、以下の影響を考慮します。

• サービス コールバック中に、コールバックは、コールが着信したのと同じイングレス ゲートウェイを使用して行われます。サービス コールバックでは、アウトバウンド コールは他のエグレス ゲートウェイを使用して行うことができません。

• Unified CVP VXML サーバでのコールバックを許可するキュー呼び出し。

• サービス コールバックには Unified CVP レポート サーバを必要とします。

• この機能では応答マシン検出は使用できません。コールバック中に、発信者には短い VRU セッション メッセージでプロンプトが提示され、DTMF を使用して、コールを受ける準備ができたことを確認します。

• DTMF * 8、TBCT、またはフック フラッシュを使用してエージェントに転送されるコールは、サービス コールバックを使用できません。

• サービス コールバックは、コンピュータ テレフォニー インテグレーション（CTI）ルート ポイント経由の CCB キューへのエージェント コール転送をサポートしていません。

• コールバックはベストエフォート型の機能です。コールバック中に発信者への到達試行を制限された数だけ行った後、コールバックは終了し、失敗としてマークされます。

• Unified CVP Operations Console で、サービス コールバックが発信に使用する許可番号またはブロック番号を設定します。

• 音声ブラウザのメディアの非アクティブ検出機能は、コールバックのコール待機に影響する可能性があります。詳細については、Configuration Guide for Cisco Unified Customer Voice Portalを参照してください。

• サービス コールバックは、最適に動作するために正確な EWT 計算が必要です。

  サービス コールバックのプレシジョン キューを使用する場合、EWT を最適化するには以下の推奨事項を考慮します。

  • 単一のプレシジョン キューにコールを格納します。

  • 手順を設定するときに Consider If 式を追加しないでください。

  • 手順の間に待機時間を追加しない、またはプレシジョン キューに手順を 1 つだけ使用しないでください。

    Note	シンプルなプレシジョン キュー定義を使用します（たとえば、1 ステップおよび1 対 1 のエージェント マッピング）。プレシジョン キューは複雑なため、正確な EWT を計算することは困難です。

拡張コールコンテキスト (ECC) 変数を使用すると、ビジネス関連データをエージェント デスクトップに転送するように設定することができます。通話の変数と異なり、各 ECC 変数のサイズ、形式、名前を設定することができます。ECC ペイロード を使用して、ECC ペイロードの メンバー であるECC 変数の設定を渡すことができます。ECC ペイロードは 2,000 バイトを保持します。ルータは、各コールに対して約 6,000 バイトの ECC 変数を保存することができます。ECC 変数のコンテンツに関するシステム全体の制限を超えると、ソリューションは警告イベントを生成します。

このソリューションには、下位互換性のために「デフォルト」名を持つ ECC ペイロードが含まれています。ソリューションがより多くの ECC 変数スペースを必要としない場合は、デフォルトのペイロードのみが必要となります。ソリューションがデフォルトのペイロードのみを保持している場合、ソリューションは、2000 バイトの制限に達するまで、新しい ECC 変数をすべてデフォルトのペイロードに自動的に追加します。

Note	デフォルトのペイロードを削除することはできません。ただし、そのメンバーを変更することはできます。CVP、アウトバウンドオプション、マルチチャネル、および ECC 変数は、デフォルトペイロードのスペースの一部を消費します。

特定のインターフェイスの ECC 変数を保持するためには、ECC ペイロードを作成します。

Note	CTI クライアントへの ECC ペイロードの場合、サイズ制限は 2,000 バイトに ECC 変数名のための追加の 500 バイトを加えたものです。他のインターフェイスとは異なり、CTI メッセージには、ECC の変数名が含まれています。

コール中に有効範囲を持つことができる ECC ペイロードは 1 つのみです。有効範囲がスクリプト環境内にある ECC ペイロードを設定します。このソリューションは、上書きされない限り、デフォルトのペイロードを使用します。

会議と転送の場合は、通常、コール フローを介して同じ ECC ペイロードを使用します。異なる ECC ペイロードを使用して 2 つのコールをマージする場合は、変数のマージ動作がより複雑になります。詳細については、isco Unified ICM/Contact Center Enterprise スクリプティングおよびメディア ルーティング ガイを参照してください。

Unified CCE スクリプトで UUI を設定して、SIP メッセージで再送信するために Unified CVP で UUI を抽出することができます。

UUI 処理のシナリオ：

• GTD の MIME ボディ形式の SIP INVITE メッセージの着信コール レッグには GTD (汎用タイプ記述子) データを含めることができます。この場合、Unified CVP によって、GTD データが着信 GTD として保存され、UUI 部分 (存在する場合) が Unified CCE に渡されます。

  Cisco IOS ゲートウェイは、SIPトランスポートを使用した発信 VoIP ダイヤル ピアでこの GTD 形式をサポートしています。

  Unified ICM がデータを変更する場合、変更した UUI を Unified CVP に返信します。Unified CVP は、Unified ICM から受信した UUI データを 16 進数に変換し、UUS（存在する場合）を変更して着信 GTD の値を上書きします。以下の形式を使用して、UUS 部分のみを変更します。

  UUS,3,<converted Hex value of data from Unified CCE>

  GTD パラメータ値の残りの部分は維持され、発信者 GTD から着信した値が保存されます。

• 着信コール レッグに GTD がない場合、Unified CVP はトレースに「GTD ボディが発信者ボディに存在しません」というメッセージを出力します。その後、そのコールは通常のコールとして処理されます。

Note	Unified CCE は変更された UUI を user.microapp.uui ECC 変数または Call.UsertoUserInfo 変数で渡します。 両方の変数を使用する場合、Call.UsertoUserInfo 変数が優先されます。

変更された GTD は、CVP SIP B2BUA からの発信 INVITE MIME ボディで設定され、ここには IP 発信者と TDM 発信者が含まれます。接続されたコールでアウトパルス転送用の DTMF ラベルが受信された場合、Unified CCE が UUI を通過させた場合にのみ BYE メッセージが GTD と共に送信されます。BYE メッセージは SIP INFO 直後に DTMF で送信されます。

Note	フックフラッシュまたは Two B Channel Transfer（TBCT）を使用すると、UUI データ転送機能を使用できません。

Unified CCE スクリプト内の UUI

Unified CCEスクリプトでUUIを抽出するには、user.microapp.uui ECC 変数および Call.UserToUserInfo 変数を確認します。上記変数のいずれかで SET ノードを使用すると、コールの発信方向の変数を設定することができます。

Call.UserToUserInfo 変数の設定が ECC 変数の使用よりも優先されます。

Note	Unified CVP は、Unified CCE が UUI に合格した場合にのみ、DTMF ラベルで BYE メッセージを送信します。

BYE メッセージが受信された場合、受信された BYE の GTD が使用され、他のレッグで送信されます。

UUI および UUS を使用した GTD が VoIP 側で転送されるように、無条件の信号転送でイングレス ゲートウェイを構成します。次に例を示します。

voice service voip
        signaling forward unconditional

VER,1.00
PRN,t1113,*,att**,1993
FAC,
UUS,0,(hex encoded UUI string here)

トランスコーダおよび DSP リソースを回避するには、混合コーデックを使用します。イングレスおよびエグレス ゲートウェイと Unified CM でデュアル コーデックを定義します。VRU は、コールを G.711 として自動的にネゴシエイトします。次に、そのコールを G.729 または G.711 として、発信者とエージェントの対話用に再接続します。

混合コーデックの設計上の影響は以下の通りです。

• G.729 のみをサポートする SIP トランクは、トランスコーダの使用を強制します。

• ウィスパー アナウンスメントなどの一部の機能では、G.729 から G.729 へのインターワーキングに汎用トランスコーダが必要となります。

• 単一の 729 コーデックによってトランスコーダが必要な場合は、Unified CM 制御トランスコーディング リソースを使用します。上記リソースは、コーデックが一致しない場合に自動的にトリガされます。

• コール フロー、補足サービス、および特定の統合機能に基づき、適切なトランスコーディング リソースおよび汎用トランスコーディング リソースのサイジングが必要です。

Unified Mobile Agent は、Cisco 音声ゲートウェイに転送される PSTN 電話機にログインして、Unified CCE にログインすることができます。モバイル エージェントには、エージェント デスクトップも必要となります。

Unified CCE がモバイル エージェント向けにサポートする任意の音声ゲートウェイを使用することができます。エージェント PG または別のクラスタと同じ Unified CM クラスタと共に音声ゲートウェイを登録することができます。発信者 (イングレス) およびモバイル エージェント (エグレス) 音声ゲートウェイは MGCP または SIP を使用することができます。

Note	サイレント モニタリングを有効にした場合は、イングレスとエグレスに異なる音声ゲートウェイを使用します。

Unified Mobile Agent では、SIP 用に設定されている Cisco IP フォンを使用することができます。モバイル エージェントへのコールは、SIP IP フォンから発信される場合もあります。

Unified CM のパフォーマンスを向上させるために、エージェント PG と同じクラスタの IP フォンを持つモバイル エージェントに対しては、Unified Mobile Agent ではなく Extension Mobility を使用します。IP フォン デバイスは JTAPI ユーザに関連付けられているため、Unified CM でこの関連付けを行うと、パフォーマンスがわずかに低下します。

Unified Mobile Agent ソリューションを設計する際は、以下の点を考慮します。

• SIP トランクを使用している場合は、メディア ターミネーション ポイント (MTP) を設定します。この要件は、TDM トランクを使用してサービス プロバイダーとインターフェイスする場合にも適用されます。詳細については、http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-feature-guides-list.htmlの Cisco Unified Contact Center Enterprise 機能ガイド を参照してください。

• トランクの使用を有効にすると、そのトランクを通過するすべてのコールに影響します。コンタクト センター以外のコールにも影響を与えます。使用可能な MTP の数がトランクを通過するコールの数をサポートすることを確認します。

マルチライン エージェント制御 (MLAC) は Cisco CCE エージェントの周辺機器設定であり、セカンダリ拡張でのコールについてレポート作成およびコール制御を可能にします。MLAC を使用すると、以下の通りの制限が課されることがあります。

• コール待機なし

• 各エージェントの電話機には 4 つの内線番号の制限があります

• エージェント間の共有回線はありません

• 有効にすると、特定の周辺機器のすべての電話機に適用されます

このソリューションは、監視されていないセカンダリ内線番号でのコール アクティビティは追跡されません。セカンダリ内線番号には、共有回線の使用など、通常はコンタクト センター アクションに関連付けられていない PBX 機能を含めることができます。

Unified CCE は E.164 ダイヤル プランをサポートしており、以下の通り「+」プレフィックスに部分的なサポートを提供します。

• エージェントの内線番号に「+」の文字を含めることはできません。

• エージェント周辺機器で「すべての行」エージェント制御が有効になっている場合、エージェントのセカンダリ回線に「+」文字を含めることはできません。

• VRU には、DN を CTI ルート ポイント経由で転送しない限り「+」プレフィックスを含めることはできません。

• ダイヤラがインポートした連絡先番号とキャンペーン プレフィックスに「+」プレフィックスを含めることはできません。

• エージェントは、Cisco Finesse デスクトップから E.164 番号を使用して「+」プレフィックスをダイヤルすることができます。

• エージェントは、電話から E.164 番号の「+」プレフィックスをダイヤルすることができます。

コンタクト センター外のエージェントの内線番号を通知するコンタクト センターでは、以下の事項が適用されます。

• 変換パターンを使用して、アウトバウンド コールのコール番号に「+」プリフィックスを追加します。電話機の設定には、発信者側の変換 CSS を使用することができます。

• 「+」プレフィックスを使用して着信コールを E メールで送信するには、変換パターンの「当事者変換」を使用して、コール先番号から 「+」プレフィックスを取り除きます。

• アテンダント コンソールに電話機のステータスを表示することはできません。

通常、発信者に対してコール中に調査に参加するかどうかの確認が行われます。使用するソリューションは、ダイヤルされた番号に基いて決定し、コール終了時にポスト コール調査を呼び出すことができます。顧客がエージェントとの会話を完了すると、顧客は自動的に調査にリダイレクトされます。ポスト コール調査は、最後のエージェントの切断イベントによってトリガされます。

顧客は、プッシュホン電話機のキーパッドと ASR/TTS で音声を使用して、調査中の質問に応答できます。ソリューションの観点からは、ポスト コール調査コールは通常のコールと同じです。ポスト コール調査中に、元の顧客コールからコール コンテキスト情報が取得されます。

ポスト コール調査機能を設計する際は、以下の条件に準拠します。

• ポスト コール調査は、最後のエージェントの切断イベントによってトリガされます。エージェントが電話を切ると、コール ルーティング スクリプトは、調査スクリプトを起動します。

• ポスト コール調査番号への着信番号パターンのマッピングによって、コールのポスト コール調査機能がイネーブルなります。

• 拡張コール変数 user.microapp.isPostCallSurvey の値は、コールがポスト コール調査番号に転送されるかどうかを制御します。

  • f user.microapp.isPostCallSurvey を y (暗黙のデフォルト) に設定した場合、コールはマッピングされたポスト コール調査番号に転送されます。

  • user.microapp.isPostCallSurvey を n に設定すると、コールは終了します。

  • 調査への着信番号パターンのすべてのコールをルーティングするには、スクリプトで user.microapp.isPostCallSurvey 変数を設定する必要はありません。変数は y にデフォルトで設定されます。

• ポスト コール調査では、REFER コール フローを使用できません。REFER コール フローは、コールから Unified CVP を削除します。ただし、そのエージェントはすでに切断されているため、コールによるアンケートには統合 CVP が必要です。

• Unified CCE レポートの目的で、ポーリング間隔コールは、初回コールのコールコンテキストを継承します。調査が開始されると、エージェントに転送されたカスタマー コールのコール コンテキストは、ポスト コール調査コールのコール コンテキストに複製されます。

この項では、デジタルチャネル調査のコールフロー情報を提供します。

• Cloud Connect および Finesse デスクトップブラウザは、エクスペリエンス管理クラウドサービスにアクセスできる必要があります。

• すべてのFinesseVMは、次の URL で（https://<finesse FQDN>:8445）でエクスペリエンス管理ポータルで許可されなければなりません。

Cloud Connect により Cisco Unified CCE カスタマーは、Customer Journey Analyzer の Business Metrics などのクラウド機能を使用できます。Customer Journey Analyzer により、複数のデータソースおよびシステムから履歴データが採掘され、データの特定のビジネスビューが生成されます。トレンドが表示されることでパターンを特定し、継続的な改善に向けたインサイトを得るのに役立ちます。これらのビジネスメトリックを生成するために、エージェントアクティビティと連絡先（電話、チャット、電子メール）アクティビティレコードは Customer Journey Analyzer に公開されます。Cloud Connect コンポーネントは、Customer Journey Analyzer にデータを公開します。

スキル グループとは異なり、プレシジョン キューは属性定義を分解し、属性レベルでエージェントのコレクションを形成します。プレシジョン キューの属性レベルに一致するエージェントは、そのプレシジョン キューに関連付けられます。

プレシジョン キューの場合、「English Sales」キューでは、「English」と「Sales」セールスの属性を定義し、これらの特徴を持つエージェントをこの属性に関連付けます。プレシジョン キュー「English Sales」は、この特徴を持つすべてのエージェントをプレシジョン キューにダイナミックにマップします。より複雑なスキル属性を定義して、エージェントに関連付けることもできます。これにより、英語の習熟度 = 10、営業の習熟度Sales Proficiency = 5など、複数の習熟度検索を単一のプレシジョン キューで作成することができます。

英語の販売キューをスキル グループと一致させるには、各属性に 1 つずつ、2 つの別々のスキル グループを設定します。プレシジョン キューを使用すると、エージェントを属性別に振り分けることができます。スキル グループでは、スキル グループを定義し、それにエージェントを割り当てます。

高レベルで、発信者がプレミアム メンバーであるかどうかを最初にチェックする 5 ステップの有効桁数のキューを想定してみましょう。

1. 属性：Skill > 8 - Consider If: Caller is Premium Member

2. 属性：Skill > 6

3. 属性：Skill > 4

4. 属性：Skill > 3

5. 属性：Skill > 1

プレミアム カスタマーではない発信者 John が、1-800-repairs にコールしたとします。システムは、このプレシジョン キューに John のコールを送信します。プレシジョン キューの動作は以下の通りです。

1. John はプレミアム カスタマーではないので、（手順 1 の Consider If により）ただちに手順 1 から手順 2 にルーティングされ、そこで応答を待ちます。

2. コールはステップ 2 に移動し、6 を超えるスキルを持つエージェントが、自分のコールに応答するまで John は待機します。

3. 手順 2 の待機時間が過ぎると、John のコールは手順 3 に移行してスキルが 4 以上のエージェントを待ちます。

4. 手順 3 の待機時間が過ぎると、John のコールは手順 4 に移行してスキルが 3 以上のエージェントを待ちます。

5. 手順 5 に到達すると、John のコールは対応可能なエージェントを無期限に待ちます。この手順以降のルーティング ロジックは存在しないため、この手順がすべてのコールに適用されます。

コールは、使用可能なエージェントのプールを拡張するために、後続の各ステップを実行します。最終的に、最後のステップに達すると、コールは潜在的なエージェントの最大プールを待ちます。追加の各手順では、コールに応答可能なエージェントが存在する可能性が高くなります。また、これにより、最も価値があり、スキルの高いエージェントを早めにプレシジョン キューの手順に入れることができます。後の手順でさほど適切でないエージェントに移動する前に、まずこういったエージェントにコールが届きます。

SSO をサポートするコンタクト センターのソリューション コンポーネントは以下の通りです。

• Unified CCE: エージェントおよびスーパーバイザのインターフェイス

• Cisco Finesse: エージェントおよびスーパーバイザのインターフェイス

• Cisco Unified Intelligence Center: エージェントおよびスーパーバイザのインターフェイス

• Customer Collaboration Platform— タスク ルーティング インターフェイス

• ビジネス チャットおよび E メール: Cisco Finesse の ECE ガジェットを使用したエージェントおよびスーパーバイザのインターフェイス

• Unified Contact Center Management Portal（Unified CCMP）

SSO では、セキュリティ アサーション マークアップ言語（SAML）を使用して、エンタープライズ ID プロバイダー（IdP）と Cisco IdSとの間で認証および許可の詳細を交換します。

ユーザーが SSO 対応サービスの Web ページを参照すると、認証要求はCisco IdSにリダイレクトされます。 Cisco IdS は、SAML認証要求を生成し、それをアイデンティティ プロバイダーに向けます。IdP は、ユーザに対してブラウザにサインイン ページを表示し、ユーザのクレデンシャルを収集します。IdP はユーザを認証すると、Cisco IdS に SAML アサーションを発行します。アサーションには、ユーザに関する信頼できるステートメントが含まれています。

SAML アサーションを受信すると、Cisco IdS は Open Authorization (OAuth) プロトコルを使用して、要求されたサービスとの認証を完了します。サービスは、特定のリソースを有効にするために承認ページをユーザに提示することができます。

認証プロバイダーにユーザ クレデンシャルを提示している間にだけ、SAML と OAuth によるユーザの認証が可能になります。ユーザ名とパスワードは IdP にのみ提示されます。コンタクト センター ソリューションのアプリケーションとサービスはユーザ情報を確認しません。SAML アサーションと OAuth トークンのみが交換されます。

ウィスパー アナウンスメントの標準コール フローは以下の通りです。

1. 着信コールがキャリアから CVP に到着します。

2. CVP は、Unified CCE にコールを送信します。

3. Unified CCE は、CVP にコールのキューに入るよう指定します。

4. CVP は、音声ブラウザにコールを送信します。

5. Unified CCE は、ウィスパーアナウンスメント プロンプトと一緒にエージェントラベルを送信します。

6. CVP は、着信コールを Unified CCE に送信します。

7. Unified CM は、エージェントの電話にコールを送信します。

8. 発信者には呼び出し音が継続して聞こえます。エージェントはウィスパー アナウンスメントを聞きます。

9. ウィスパー アナウンスメントが終了すると、 発信者はエージェントにつながれます。

ウィスパー アナウンスメントには以下の制限があります。

• エージェントが行ったアウトバウンド コールのアナウンスは再生されません。アナウンスメントはインバウンド コールに対してのみ再生されます。

• ウィスパー アナウンスメントがエージェント間コールで機能するには、コールをエージェントに転送する前に SendToVRU ノードを使用します。別のエージェントにコールを転送する前に、Unified CVP にコールを転送します。次に、Unified CVP は、コールを Unified CVP に転送するノードに関わらず、コールを制御して、アナウンスを再生することができます。

• ルータがラベル ノードを介してエージェントを選択する際は、アナウンスは再生されません。

• CVP Refer 転送は、ウィスパー アナウンスメントをサポートしていません。

• ウィスパー アナウンスメントではサイレント モニタリングがサポートされます。ただし、Unified Communications Manager ベースのサイレント モニタリングの場合、スーパーバイザはアナウンス自体は聞くことができません。スーパーバイザのデスクトップは、アナウンスが再生される間、サイレント モニタ ボタンをグレー表示します。

• コール毎に再生できるアナウンスは 1 つだけです。アナウンスが再生されている間、コールを保留、転送、または会議、コールのリリース、または監督者の支援要求はできません。アナウンス終了後に上記の機能が利用できるようになります。

• ウィスパー アナウンスメントの録音とエージェントの電話機のコーデック設定は一致していなければなりません。たとえば、ウィスパー アナウンスメント が G.711 ALAW で録音されている場合、電話機も G.711 ALAW でなければなりません。ウィスパー アナウンスメントが G.729 で録音されている場合、電話機は、G.729 をサポートするか、使用していなければなりません。

• IPv6 対応の環境では、ウィスパー アナウンスメントには追加のメディア ターミネーション ポイント（MTP）が必要です。