IP 電話

テレフォニーの場合、着信音声通話の処理は、通話がどのように Contact Center に入ったか（以下の入力メカニズムを参照）と、エントリポイントに関連付けられた Webex CC フローによって決定されます。

通話が応答されると、Webex CC フロー定義に従ってさらにアクションが実行されます。これは、エージェントへのキューイングとルーティングの前に通話を処理する際に実行されるアクションをプログラムで表現したものであるか、フロー自体がエージェントへの転送はありません。

Webex CC のフロービルダーを使用すると、開発者はフローを定義し、コールが Webex CC に着信するエントリポイントに割り当てることができます。

これらの構成エンティティとその使用法については、「構成エンティティ」で説明されています。

Flow Builder の詳細については、「IVR システム」に関する次のセクションで説明します。

電子メールとメッセージサービス

Webex CC の観点から、Webex Connect はすべてのデジタルチャンネル（エンドユーザーが Contact Center に連絡するために使用できる E メール、メッセージングチャンネル）のイングレスおよびエグレス機能を提供します。

Webex Connect フロー

• やりとりがキューに入れられてエージェントにルーティングされるまで、やりとりの処理を決定します。これには、あらゆる形式のメッセージングおよび E メールのやりとりに対する自動処理とボット処理が含まれます。

• 着信インタラクションにビジネスロジックを適用します。

• キューイングの前にコンタクトを処理します。

• フロー自体は、ライブエージェントへの転送なしでインタラクションを処理できます。

Webex CC でサポートされるメッセージングチャンネルは次のとおりです。

• Web アプリ / モバイルアプリチャット

• WhatsApp

• Facebook Messenger

• SMS

Webex CC でサポートされているメールチャンネルは次のとおりです。

• Gmail


• Office 365

イングレスメカニズム

このセクションでは、やりとりが Webex CC に入るメカニズムについて説明します。メディアタイプに基づいて、やりとりが Webex CC に到達するメカニズムは異なります。

たとえば、テレフォニーでは、PSTN 接続、電話番号の構成、および Webex CC への通話のルーティングを有効にするために必要な物理インフラストラクチャのプロビジョニングがあります。

E メール/メッセージングチャンネルの場合、イングレス構成は Webex Connect で行う必要があり、E メール/メッセージングアカウントのプロビジョニングと Webex Connect フロー構成が含まれます。

インバウンド音声

音声通話の場合、ユーザーが PSTN 電話番号をダイヤルしてから Contact Center に接続するのが一般的なシナリオです。イングレスの観点から、これには PSTN から Webex CC に通話をルーティングするメカニズムが必要です。

「着信音声のイングレスオプション」は、Webex CC への音声通話の取り込みを示しています。

Webex CC の音声イングレスサービスは、SIP を使用してサードパーティの呼制御を実行し、着信通話に応答するだけでなく、転送、会議、およびその他の呼制御操作を実行します。

Webex CC での通話の論理的なエントリポイントは、「エントリポイント」という名前の構成エンティティです。音声イングレスの場合、エントリポイントの主要構成は、それに関連付けられた電話番号です。これは、通常、選択した PSTN プロバイダーから取得した有効な PSTN 電話番号です。

これにより、電話番号での着信通話の検出が可能になり、通話をエントリポイントに関連付け、エントリポイントの他の構成パラメータを使用して、やりとりのためにトリガーされる Webex CC Flow 定義に従って通話を処理します。

注：

PSTN 接続オプションの詳細については、https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html を参照してください。

音声エッジインフラストラクチャの拡張性と可用性

Webex CC VPOP インフラストラクチャには、高可用性を保証する SIP SBC の冗長ペアが含まれており、サポートされる同時通話量を拡大するために、より多くの SBC を追加できます。

VPOP が処理できる最大同時呼び出しは、実行中の SBC の数と、呼び出しの送信先によって異なります。

地理的冗長性の場合、リージョン間の複数のペアにまたがるインターコネクトを備えた VPOP SBC のメッシュがサポートされています。

音声イングレス サービスの場合、Webex CC に取り込まれる同時音声通話の増加を処理するために、水平方向に拡張可能です。

音声エッジインフラストラクチャのセキュリティに関する考慮事項

次の表に、音声エッジインフラストラクチャへの接続オプションの詳細を示します。

詳細については、https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html を参照してください。

IVR システム

エントリポイントに関連付けられた電話番号に着信するすべての音声通話は、Webex CC が応答し、エントリポイントに関連付けられた Webex CC Flow の実行が開始されます。

Webex CC Flow Builder は、アクティビティと呼ばれるプログラミング構造/オペレータと機能ブロックを提供するため、管理者または IVR ロジックを設計および導入担当者は、これらのビルディングブロックを組み合わせて Flow 定義を作成できます。

Flow がサポートするプログラミング構造は次のとおりです。

• 宣言と変数の設定 – フロー実行に関連付けられた状態

  • 変数の値を設定するペブル式

• 条件付きチェック

• ループ – 条件分岐と移動（アクティビティを連鎖させる機能）を使用

• Invoke REST API

• データの解析 – 通常、API 応答の解析に使用される JSON、TOML、XML。

• 構成アクティビティ

（注）	Flow が提供する代表的なアクティビティは次のとおりです。 メッセージの再生 ユーザーデータの収集 別の接続先/電話番号に通話を転送 仮想エージェントに通話を送信 エージェントが応答できるように、通話をキューに入れる。

アクティブな通話ごとに、フロー実行のインスタンスも、通話が終了するまでアクティブになり、フローの同時実行が発生します。

フロー実行の各インスタンスは、フローに関連付けられたデータ/状態および通話によって隔離された環境を提供します。

通話のライフサイクル全体を通じて、フローは発生する特定のイベントに応答してそれらを処理することもできます。たとえば、エージェントが通話に応答した場合、イベントハンドラはエージェント デスクトップ インターフェイスでスクリーンポップをトリガーできます。

Webex CC フローの詳細については、https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/SetupandAdministrationGuide_2/b_mp-release-2/b_cc-release-2_chapter_0100.html#Cisco_Generic_Topic.dita_e338e055-64b0-4973-bd52-8a5581dcb0ee を参照してください。

仮想エージェントサポート

Flow は、Webex Control Hub で事前定義されている仮想エージェントにやりとりをハンドオフするアクティビティを提供します。

通話が仮想エージェントに接続されると、会話型の IVR エクスペリエンスがユーザーに提供され、アクティビティは通話終了またはエージェントへの通話エスカレーションで終了します。

エスカレーションの場合、エージェントが応答する通話をキューに入れるようにフローを設定できます。

着信デジタルインタラクション

E メールおよび着信でのやりとりのメッセージングチャンネルの場合、Webex CC は Webex Connect を使用してアセットのプロビジョニングし、フローで着信でのやりとりに対応し、Webex Connect Flow が明示的にやりとりをキューできるように Webex CC をルーティングします。これによりエージェントが対応できるようになります。

「E メールとメッセージングのイングレスオプション」は、Webex CC での E メールの取り込み、メッセージングでのやりとりを示しています。

仮想エージェント / ボットの統合

E メールおよびメッセージング/ソーシャルチャンネルでのやりとりの場合、仮想エージェント/ボット処理は Webex Connect Flow で構成されます。

Virtual Agents for Voice と同様に、ボット処理が結果としてエスカレートして終了した場合、やりとりはキューに入れられ、エージェントにルーティングされます。

エージェント選択

Webex CC のキューは、次のエージェント選択アルゴリズムをサポートしています。

• Longest Available Agent Routing

• Skilled Based Routing

  • Longest Available Agent（LAA）

  • Best Available Agent（BAA）

エージェントは、チームを介してキューに関連付けられます。

キューには、複数の通話配布グループ（各グループには 1 つまたは複数のチームがあります）を順番に割り当てることができ、通話配布グループがキューに追加されるまで待機するように構成されています。これにより、時間の経過と共に、一致するエージェントの検索スペースを、通話配布グループに追加するように拡張されます。

スキルベースのルーティングの場合、キューに関連付けられたエージェントに一致するスキル要件の中から、LAA または BAA 構成に基づいてエージェントが選択されます。

音声/テレフォニー固有の追加機能

エージェントベースのルーティング（音声/テレフォニーチャンネルのみ）

Webex CC Flow は、QueueToAgent アクティビティを使用して、エージェント ID に基づいて選択したエージェントにやりとりを直接ルーティングできます。

エージェントがやりとりに対応できない場合、やりとりはエージェント専用キューでパークされ、エージェントが対応可能になるのを待ちます。

詳細なキュー情報

Webex CC Flow は、GetQueueInfo アクティビティを使用して、Position in Queue（PIG）、Estimated Wait Time（EWT）、キューで対応可能なエージェント数などのキューのリアルタイム情報を取得でき、問い合わせをキューにいれるかどうかの判断に使用します。

サービス コールバック

Webex CC Flow は、Callback アクティビティを使用して、キュー内の位置を維持しながら、お客様を通話から切断し、キューの仮想でのやりとりがエージェントにルーティングされた際に、コールバックを受信します。

オーバーフロー処理

Webex CC は、Capacity Based Teams（CBT）を使用したオーバーフロー処理をサポートしています。

CBT は、容量と、その容量を提供する外部の関連 DN を持つ通常のチームのようなものです。これは、Queue Call Distribution Cycles で他のチームと一緒に構成できます。

通常、これは最後のサイクルとして構成されます。これにより、構成されたすべて通話配布グループがやりとりに対応するために一致する応答可能なエージェントを見つけられなかった後でも、応答可能なエージェントがいない場合、オーバーフローとして機能します。

エージェントデスクトップ操作

エージェントが Webex CC エージェントデスクトップにログインしたら、エージェントは、自分への着信通話を接続する電話番号を指定します。エージェントが Cisco Webex Calling ユーザーの場合、これは PSTN 電話、携帯電話、または内線番号です。

この番号は、通話をルーティングできる有効な電話番号にしなければならないのでご注意ください。有効な番号でない場合、エージェントは、着信通話を受けることはできません。

エージェントが対応しているやりとりの種類に基づき、エージェントデスクトップのウィジェットは、特定のメディア制御操作を実行する機能を提供します。

たとえば、通話に応答したら、エージェントは、通話関連の次の操作を実行できます。

• 通話を保留にする

• 相談通話を開始する

  • 通話を他の電話番号（例：エージェンの電話番号）/エントリポイントに転送する

  • 別のエージェントに電話会議を行う

• 通話を別のキューに転送する

• 通話を終了する

エージェントデスクトップを使用すると、デスクトップ機能を拡張し、それをエージェントが作業を効率的に行うために必要なウィジェットのコレクションとして作成することで、そこにカスタムウィジェットを追加できます。

デスクトップ アーキテクチャ

エージェントデスクトップは、Web コンポーネント アーキテクチャに基づいて、ウィジェット構築をホストするマイクロ フロントエンド ベースの単一ページアプリケーションです。すべての標準/ストックウィジェットは、API または サーバー側のプッシュメカニズムが取得したデータを利用しています。

これらは通常、呼び出しの応答が WebSocket 接続を介してデスクトップに送信される非同期 API です。

Webex CC エージェントデスクトップはシスコの共通アイデンティティ（CI）を使用してユーザーを認証し、トークンは、すべての API 呼び出しに渡されます。カスタムウィジェットの場合も同様で、認証モデルに基づき、カスタムウィジェットの認証モデルが CI と統合されている場合は、エージェントにシングルサインオンを指定します。

エージェントがやりとりに関与すると、そのやりとりステージングまたは関連するデータに対するすべての更新も WebSocket 接続を介してデスクトップにプッシュされます。

接続と遅延に対するデスクトップの復元力

非同期 API とサーバー側のプッシュにより、拡張が可能になり、WebSocket インターフェイスへの接続の損失が検出され、デスクトップが再接続と再ログインを試行します。

「エージェント デスクトップ アーキテクチャ」は、Webex CC のエージェント デスクトップ アーキテクチャを示しています。

お客様の導入準備

Webex Control Hub は、パートナーとお客様が使用する主要なインターフェイスで、お客様の導入準備と機能の有効化と構成を行います。

組織と Contact Center の機能が Control Hub でプロビジョニングされると、Webex CC でワークフローがトリガーされ、お客様が選択したサービスに従って、すべての Contact Center 機能をプロビジョニングするための残りの手順が実行されます。

すべての Contact Center のプロビジョニングは、BPM ワークフローエンジンを使用して実行されます。BPM ワークフローエンジンは、関連する手順を宣言的な方法で定義し、プロビジョニング手順全体を障害に対して強くし、データの完全性を確保できるようにします。

「お客様の導入準備ワークフロー」は、Webex CC のプロビジョニング ワークフローを示しています。

構成エンティティ

組織内にスコープされた Webex CC の主要な構成エンティティは次のとおりです。

拠点

拠点とは、1 つ以上のチーム、ユーザー（エージェント/スーパーバイザ）が配置されている場所のことです。

すべてのユーザーとチームは拠点に属している必要があります。

チーム

ユーザーのグループ。チームは、キューを介してエージェントにやりとりを分散するために使用されます。

すべてのチームは拠点に属している必要があります。

エージェント

エージェントデスクトップにログインし、Webex CC で構成されているメディアタイプでのやりとりに対応するユーザーです。

スーパーバイザ

スーパーバイザはチームに割り当てられ、エージェントを監視/指導し、スーパーバイザが割り当てられているチームに属するチームレベルのステータスとエージェント統計情報にアクセスできます。

キュー

キューは、エージェントが対応可能になるのを待っている間にやりとりを保持できる論理構成体であり、エージェントにルーティングされます。

キューは、エージェントの検索スペースとしてチームにマッピングされ、他のチームを検索スペースに追加することにより、経過時間のしきい値に基づいて検索スペースを拡張する機能を備えています。

エントリポイント

エントリポイントは、Webex CC に着信するやりとりのイングレスポイントを表す論理構成体です。テレフォニーの場合、これは主に通話が到着する電話番号にマッピングされ、E メール/メッセージングチャンネルの場合、エントリポイントは Webex Connect のアセット構成を指します。

フロー

やりとりの処理に関連するステップを決定するエントリポイントに関連付けられたフロー（ルーティング戦略を介して）です。

テレフォニー以外のチャンネル（E メール/メッセージング/ソーシャル）の場合、フローは、Webex Connect のアセット構成の一環として選択されます。

複数の地理的 Contact Center のアクセス制御

Webex CC 管理者は、特定の拠点、チーム、キュー、およびエントリポイントへのアクセス権を持つユーザープロファイルを構成できます。さらに、拠点とチームの階層型性質により、特定の拠点へのアクセスが指定されると、それらの拠点またはそのようなチームに明示的に指定されたサブセットに属するチームまたはチームに関連する日付のみにユーザーがアクセスできます。

キューとエントリポイントの場合、それらは組織レベルで共通であるため、地理的な場所（特定のエージェントとチームが配置されている拠点）に対して個別のエントリポイントとキューを構成でき、スーパーバイザ/ユーザーは適用可能な特定の拠点のエンティティにアクセスできます。

「ユーザープロファイルにマップされた構成エンティティ」は、主要な構成エンティティと、これらのエンティティを参照するユーザープロファイルを示しています。

これらのエンティティへのアクセスを制限することとは別に、Webex CC 管理者は、ユーザーが管理インターフェイスでアクセスできる特定の機能/モジュールを制御できます。これにより、Webex CC 管理インターフェイスのセクション/機能だけでなく、特定のエンティティに対する管理/構成権限を持つユーザーも持つことができます。

デスクトップ組み込みコネクタ：主要なインターフェイスとしての CRM アプリケーション

この操作モードの場合、エージェントはプライマリアプリケーションとして CRM コンソールにログインします。

Webex CC は組み込みアプリケーション（組み込みデスクトップ アプリケーションまたは組み込みソフトフォンとも呼ばれます）で、主に Contact Center にログインし、Webex CC をルートする Contact Center でのやりとりを受信するために使用されます。

通話を受信すると、CRM 統合は CRM コンソールで次のアクションを実行します。

• ANI またはその他の通話関連データに関連付けられたお客様レコードをスクリーンポップします。

• お客様レコードのアクティビティメモとしての通話後のメタデータ

• CRM 内の問い合わせをクリックし、「クリックして通話」を許可すると、お客様に通話を発信できるようになります。

• CRM のプライマリレポート用に、CRM レポート テーブルにコール レコードを転記します。

• エージェントデスクトップと呼制御両方のフル機能を提供します（デスクトップアプリの組み込みバージョンと縮小バージョン）

CRM との統合のプライマリモードは、Webex CC デスクトップ アプリケーションを別の iFrame に埋め込むことです。

さらに、Webex CC デスクトップ アプリケーションは、カスタム ヘッドレスウィジェット（ユーザーインターフェイスなし）をバックグラウンドで実行し、基盤となる CRM システムと対話して、エージェントに代わって自動化されたアクションを実行します。

インタラクションは、ヘッドレスウィジェットが使用する 2 つの SDK によって実行されます。

• Webex CC Desktop JS SDK：これは、エージェントと問い合わせのアクションをイベントリスナーに登録するように Webex CC が提供する JavaScript SDK です。

• CRM JS SDK：これは、CRM での REST API コールを抽象化する、CRM ごとに適用可能な CRM クライアント SDK です。たとえば、Salesforce の場合、Salesforce が提供する CTI JS ライブラリを使用して、CRM 内でアクションを実行し、イベントをリッスンします。

「CRM コネクタ組み込みデスクトップ コネクタ アーキテクチャ」は、CRM 組み込み Webex CC デスクトップとコネクタアーキテクチャを示しています。

Webex CC は、上記の統合のために次の CRM ソリューションをサポートしています。

• Salesforce

• ServiceNow

• Microsoft Dynamics 365

• Zendesk

• Freshdesk

詳細については、https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10 を参照してください。

CRM コネクタ、機能セット、および変更ログを有効にするための Webex CC デスクトップレイアウトの構成の詳細については、https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations を参照してください。

CRM コネクタのグローバルな可用性

CRM コネクタは、Webex CC が運用されているすべての地域で利用できます。

柔軟な拡張とパフォーマンス

Webex CC は、CRM アプリケーションと AWS CloudFront CDN の Webex CC デスクトップ間の双方向通信を可能にするカスタムウィジェットをホストし、アベイラビリティゾーンとリージョン全体でウィジェット AWS の高可用性を確保します。

CRM 統合固有の計算はすべて、エージェントが CRM アプリケーションを使用し、Webex CC デスクトップが CRM アプリケーションに組み込まれているブラウザで実行されます。

セキュリティ

CRM コネクタは Webex CC エージェント デスクトップ レイアウトを介して呼び出され、オプションのパラメータはデスクトップレイアウトを介してウィジェットに渡され、機能のオンとオフを切り替えます。

たとえば、Salesforce アクションウィジェットを有効にするために、管理者はデスクトップ レイアウト パラメータ設定である sfdcWidgetEnabled を True にします。

パッケージのインストール

統合が双方向で機能させるには、CRM コンソールに組み込みアプリケーションがインストールされている必要があります。これは、iFrame 内でのデスクトップ アプリケーションのロードをサポートするためです。

すべてのデスクトップ埋め込みコネクタは、CRM マーケットプレイスで入手できます。

これらの数が多い場合―

ServiceNow: https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5?

Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

マーケットプレイス アプリケーションをインストールすることで、必要なプラグインがアクティブ化され、必要な XML ファイルが CRM コンソールにインポートされ、CRM での通話記録のレポートがサポートされます。

IVR の HTTP(S) コネクタを介したフロー統合

Webex CC Flow Builder は、HTTP(S) コネクタを使用して、Webex Control Hub で構成され、Webex CC Flow で使用される Webex CC と CRM システム間の双方向データフローをサポートします。

これらは主に、音声インタラクション内のパーソナライズと、IVR 内のカスタマイズされたルーティングに使用されます。

デフォルトでは、Webex CC は Control Hubで Salesforce HTTP コネクタをサポートします。他の CRM コネクタは、Webex Control Hub のカスタムコネクタとして追加できます。

HTTP コネクタの詳細については、https://github.com/CiscoDevNet/webex-contact-center-crm-integrations を参照してください。

IVR HTTP コネクタ：

• Salesforce IVR HTTP コネクタ（組み込み）：https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector

• Zendesk IVR HTTP コネクタ（カスタム）：https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector

• ServiceNow IVR HTTP コネクタ（カスタム）：https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector

Edge の音声インフラストラクチャ

Voice Edge コンポーネントにより、お客様のネットワーク/PSTN キャリアからの SIP トラックを終了できます。これは、Edge コンポーネントへの接続を許可するホワイトリスト登録された Ips に基づいて有効化されます。

インフラストラクチャ セキュリティの計算

Webex CC compute インスタンスは、AWS でプロビジョニングされ、サービスは、Kubernetes クラスタのポッドとして実行されます。これには、複数の名前空間があり、各中江空間へのアクセスは、個別のログイン情報によって制限されています。

すべてのインフラストラクチャのプロビジョニングは、手動ではなくコードを使用して実行されます。つまり、ログイン情報に手動でアクセスすることはできません。

特定のサービスやチームの特定のセットに対して構成された特定のパスをもつ中央ログイン情報ストアがあります。ログイン情報ストア自体へのアクセスは制限されており、ビルドやデプロイメントシステムのシークレットとして構成されています。

インフラストラクチャ コンポーネントやサービスは AWS VPC の外部では直接公開されていません。明示的に公開されているインターフェイスのみが API や WebSocket サーバーで、API ゲートウェイを使用して制限および管理されています。

これとは別に、ログ、メトリクス、デプロイメント詳細、ぶり度ステップ、テスト結果の閲覧用にデベロッパーが使用する特定の内部システムとインターフェイスがあります。これらは、ロールやグループで保護されており、シスコ内部認証システムと統合されています。

ユーザーインターフェイスの認証と承認

さまざまな Contact Center ユーザー（エージェント、スーパーバイザ、管理者、アナリスト）が使用するすべてのユーザーインターフェイスは、シスコ共通アイデンティティベースの Bearer トークン認証（OAuth フロー）に基づいて保護されています。

承認は、トークンを取得したユーザーのロールとトークンに割り当てられたスコープを使用して実行されます。

移動中のデータ

展開されたサービス/インフラストラクチャ コンポーネントのインターフェイスはいずれも、外部の着信トラフィックに直接公開されません。

一部のサービスでは、http API を使用してこれらのインターフェイスをゲートウェイ経由で公開し、すべての着信 https（WebSocket のものを含む）は ALB で終了し、http 経由の内部トラフィックはサービスにルーティングされます。

すべての発信でのやりとりは https / TLS（http 以外のプロトコルの場合）を介して行われます。

VPC の内部では、http / カスタム TCP プロトコルを介したサービス間の内部通信は、プレーン TCP ソケットを介して行われます。

保管中のデータ

保管されるすべてのデータは、ストレージレイヤーで暗号化されます。さらに、VPC の外部にあるこれらのデータストアは保護されており、ログイン情報を使用したアクセス制御と認証は、シークレットストアに安全に保存および管理されます。

「転送時と静止時のデータセキュリティ」は、転送時と静止時のデータフローとセキュリティモデルを示しています。

エンドユーザーの PII データ

やりとりをプログラムで制御する Webex CC Flow を使用すると、ユーザーデータを収集できます。これは、特に「機密データを含む」とタグ付けされたフロー変数に割り当てることができます。このようなデータの値は、暗号化されており、転送パスにあるサービスは、このデータにアクセスできません。

さらに、そのようなデータは Webex CC レポートデータストアに保持されることはなく、ログ/メッセージング インフラストラクチャには暗号化されたデータが含まれ、クリアテキストデータは Webex CC 内のどこにも保管されません。

Contact Center エージェント/スーパーバイザの PII データ

Contact Center ユーザー関連のデータは、ログで編集され、Webex CC データストアでデータ分析用に利用され可視化されます。

拡張の要因

Webex CC の場合、拡張に影響を与える要因は次のとおりです。

• 現在ログオンしているエージェント数

• 進行中のやりとり数

  • それらのやりとりで実行されるアクション

• やりとりへの対応以外で、スーパーバイザ/エージェントが同時に実行するアクション数

• 生成および保持されたデータ量

拡張を有効にするアーキテクチャの側面

Webex CC のアーキテクチャおよび設計に基づく原則により、さまざまなサービスおよびプラットフォーム コンポーネント用にプロビジョニングされたインフラストラクチャによって適用される制限内で、必要に応じてソリューションを動的に拡張できます。

イベント駆動型アーキテクチャ

Webex CC のサービスはメッセージを使用して通信します。重要なメッセージ処理フローには IO 操作のブロックは含まれず、メッセージの処理に必要な状態は、メッセージを処理しているサービスのインスタンスにローカライズされます。

ステートレスサービス（外部化ステート）

ステートレスサービスは、サービスの追加インスタンスを簡単に追加/削除することにより、弾力性を実現します。本質的にステートフルな特定のサービスがあり、それらには外部化されたステートストアがあります。インフラストラクチャは、自動リバランス/状態転送/状態を必要とするインスタンスへの状態のローカライズによって、そのようなサービスのインスタンス数を動的に変更します。

柔軟なインフラストラクチャ

すべてのサービスは Kubernetes で実行され、インフラストラクチャ（別名 Kubernetes ノード）は使用状況に基づいて自動的に拡張されます。これにより、事前構成された最大高しきい値まで、さらにコンピューティングノードを動的に追加できます。

負荷予測と定期的検証

すべてのサービスはパフォーマンス特性についてベンチマークされ、拡張パターンはサービスレベルで検証されます。

さらなる継続的検証、ピーク負荷および耐久性テストは、拡張に影響を与える属性の予測される成長に合わせて調整されたテストパラメータを使用して実施されます。これにより、ボトルネックの特定、インフラストラクチャ リソース使用率の高しきい値の更新および実行日への準備が可能になります。