テレフォニー

テレフォニーの場合、インバウンド音声通話の処理は、コールがコンタクト センターに入る方法 (下記の入力メカニズムを参照) と、エントリ ポイントに関連付けられている Webex CC フローによって決定されます。

通話に応答があり、以降のアクションは Webex CC フロー定義に従って実行されます。これは、エージェントをキューに入れてエージェントにルーティングする前の通話の処理中に実行されるアクションをプログラムで表したものであるか、フロー自体が通話を処理するかのいずれかです。エージェントに転送しないでください。

Webex CC の Flow Builder を使えば、開発者はフローを定義し、Webex CC で通話が着信する際に経由するエントリ ポイントに割り当てることができます。

これらの構成エンティティとその使用法については、 構成エンティティ。

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

メールとメッセージング

Webex CC の観点から、Webex Connect は、エンドユーザがコンタクトセンターに連絡するために使用できる、メール、メッセージング チャネルなど、すべてのデジタル チャネルの入力と出力の機能を提供します。

Webex 接続フロー

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

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

• キューに入る前の連絡を処理します。

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

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

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

• WhatsApp

• Facebook Messenger

• SMS

Webex CC でサポートされているメール チャネル:

• Gmail

• Office365

入力メカニズム

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

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

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

着信音声

音声通話の場合、一般的なシナリオでは、ユーザが PSTN 電話番号をダイヤルすると、それがコンタクトセンターに接続されます。 入力の観点から、これには PSTN から Webex CC にコールをルーティングするメカニズムが必要です。

図 1 は、Webex CC への音声通話の取り込みを示しています。

Webex CC の音声入力サービスは、SIP を使用してサードパーティの通話制御を実行し、着信通話に応答し、転送、電話会議、その他の通話制御操作を実行します。

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

これにより、電話番号への着信を検出し、通話を エントリポイントに関連付け、エントリポイントの他の構成パラメータを使用して、インタラクションでトリガーされる Webex CC フロー定義に従って通話を処理できます。

注：

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 を参照してください。

[LDAPシステム(IVR System)]

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

Webex CC Flow Builder は、アクティビティと呼ばれるプログラミング構成要素/演算子と機能ブロックを提供します。これにより、管理者や、IVR ロジックを設計および実装するユーザは、これらの構成要素を組み合わせて、フロー定義を作成できます。

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

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

  • Pebble 式で変数の値を設定する

• 条件チェック

• ループ – 条件分岐とジャンプを使用 (アクティビティを連結する機能)

• REST API の呼び出し

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

• アクティビティを作成する

フローが提供する代表的なアクティビティは以下の通りです。 メッセージを再生する ユーザデータの収集 通話を別の宛先/電話番号に転送する 通話をバーチャルエージェントに送信する エージェントが応答できるように通話をキューに入れます。

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

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

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

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 を参照してください。

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

フローは、対話を仮想エージェントにハンドオフするアクティビティを提供します。これは Webex Control Hub で事前設定されています。

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

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

インバウンド デジタル インタラクション

メール、および受信インタラクションのメッセージ チャネルについては、Webex Connect を利用してアセットをプロビジョニングし、フローで受信インタラクションを処理してから、そのインタラクションを Webex CC にルーティングします。エージェントが対応できます。

図 2 は、メールの取り込み、Webex CC でのメッセージングの対話を示しています。

仮想エージェント/ボットのインテグレーション

メールおよびメッセージング/ソーシャル チャネルの対話の場合、仮想エージェント/ボットの扱いは、Webex Connect フローで構成されます。

音声用仮想エージェントと同様に、ボットの処理が結果としてエスカレートして終了した場合、インタラクションはキューに入れられ、エージェントにルーティングされます。

エージェントの選択

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

• 対応可能な最長時間エージェント ルーティング

• 熟練ベースのルーティング

  • 最長対応エージェント (LAA)

  • 最適なエージェント (BAA)

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

キューには、通話分配グループがキューに追加されるのを待機するように設定された順番で、複数の通話分配グループを各グループに割り当てることができます。これにより、一致するエージェントの検索スペースが、追加のエージェントに拡大されます。時間の経過に応じて配信グループに発信します。

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

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

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

Webex CC フローは、アクティビティ QueueToAgent を使用して、エージェント ID に基づいて、選択されたエージェントにインタラクションを直接ルーティングできます。

エージェントがインタラクションを処理できない場合、インタラクションはエージェント専用のキューに保留され、エージェントが対応可能になるまで待機します

アドバンストキュー情報

Webex CC フローは、GetQueueInfo アクティビティを使用して、キュー内の位置 (PIQ)、推定待ち時間 (EWT)、キューで応答可能なエージェント数などのキューのリアルタイム情報を取得できます。連絡先をキューに入れるかどうかを指定します。

無料のコールバック

Webex CC フローは、アクティビティ コールバックを使用して、顧客がキュー内の位置を維持しながら通話を切断し、キュー内のバーチャル インタラクションがエージェントにルーティングされたときにコールバックを受信できるようにします。

オーバーフロー処理

Webex CC は Capacity Based Teams (CBT) を使用したオーバーフロー処理をサポートします。

CBT は定員を持つ通常のチームのようなもので、その定員に対応する外部 DN が関連付けられます。 これは、キュー コール分配サイクルで他のチームと共に構成できます。

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

IVR オペレーション

エージェントが Webex CC Agent Desktop にログインすると、エージェントへの着信コールを接続できる電話番号を指定します。 これには、PSTN 電話、携帯電話、またはエージェントが Cisco Webex Calling ユーザの場合は内線番号を指定できます。

この番号は、通話をルーティングできる有効な電話番号である必要があります。 存在しない場合、エージェントは着信コールを受けることができません。

エージェントが処理しているインタラクションのタイプに基づいて、エージェント デスクトップのウィジェットは、特定のメディア コントロール操作を実行する機能を提供します。

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

• 通話を保留にする

• コンサルト コールを開始し、

  • 別の電話番号 (たとえば、エージェントの電話番号) / エントリポイントに通話を転送する

  • コールする別のエージェントの電話会議

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

• 通話を終了する

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

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

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

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

Webex CC Agent Desktop は Cisco Common Identity (CI) でユーザを認証し、トークンは API のすべての呼び出しに渡されます。 カスタム ウィジェットについても、認証モデルに基づいて、カスタム ウィジェットの認証モデルが CI と統合されている場合、エージェントにシングル サインオンのエクスペリエンスを提供します。

エージェントがインタラクションの一部になると、そのインタラクション状態または関連するデータに対するすべての更新も、WebSocket 接続を介してデスクトップにプッシュされます。

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

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

図 2 に、Webex CC でのエージェント デスクトップ アーキテクチャを示します。

オンボーディングの顧客

Webex Control Hub は、パートナーや顧客が顧客のオンボーディングや機能の有効化や設定を行うために使用する主要なインターフェイスです。

組織とコンタクト センターの機能が Control Hub でプロビジョニングされると、Webex CC でワークフローがトリガーされます。このワークフローは、顧客が選択したサービスに応じて、コンタクト センターのすべての機能をプロビジョニングするための残りの手順を行います。

すべてのコンタクトセンターのプロビジョニングは、BPM ワークフローエンジンを使用して行われます。これにより、関連するステップを宣言的な方法で定義でき、プロビジョニングステップ全体で障害に対する復元力があり、データの整合性が保証されます。

図 1 は、Webex CC でのプロビジョニング ワークフローを示しています。

構成エンティティ

組織内を範囲とする、Webex CC の主な構成エンティティは次のとおりです。

サイト

サイトとは、1 つまたは複数のチーム、ユーザ (エージェント/スーパーバイザー) が配置されている場所を意味します。

すべてのユーザとチームは 1 つのサイトに属している必要があります。

チーム（Team）

ユーザのグループ。 チームは、キューを介してエージェントにインタラクションを配信するために使用されます。

すべてのチームは 1 つのサイトに属している必要があります。

エージェント

Agent Desktop にログインして、Webex CC で設定されたメディア タイプ全体のインタラクションを処理できるユーザ。

スーパーバイザ

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

キュー（Queue）

キューは、エージェントが利用可能になるのを待っている間に、対話を保留できる論理エンティティであり、エージェントにルーティングされます。

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

エントリポイント

エントリーポイントは、Webex CC へのインタラクションのイングレス ポイントを表す論理エンティティです。テレフォニーの場合、これは主に着信の電話番号にマッピングされます。メール/メッセージング チャネルの場合、エントリポイントは Webex Connect のアセット構成をポイントします。

フロー

インタラクションの処理に関連するステップを決定するエントリ ポイント (ルーティング戦略経由) に関連付けられたフロー。

テレフォニー以外のチャネル (メール、メッセージング/ソーシャル) の場合、フローは Webex Connect のアセット設定の一部として選択されます。

マルチサイトコンタクトセンターのアクセスコントロール

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

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

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

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

デスクトップ埋め込みコネクタ: プライマリ インターフェイスとしての CRM アプリケーション

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

Webex CC は埋め込みアプリケーション (埋め込みデスクトップアプリケーションまたは埋め込みソフトフォンとも呼ばれます) で、主にコンタクトセンターにログインし、Webex CC ルーティングされたコンタクトセンターでの対話を受信するために使用されます。

CRM 連携は、通話または会話リクエストを受信すると、CRM コンソール上で以下のアクションを実行します。

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

• 顧客レコード上の活動メモとしての通話後のメタデータ

• エージェントが CRM 内の連絡先をクリックし、顧客にアウトバウンド コールを発信することで、「クリック ツー コール」を許可する

• CRM のプライマリレポート用に、CRM レポートテーブルに通話記録を転記する。

• Agent Desktop の完全な機能と通話コントロール (デスクトップ アプリの埋め込みおよび縮小バージョン) を提供します

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

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

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

• Webex CC デスクトップ JavaScript SDK は、エージェントおよびコンタクト アクションのイベント リスナを登録するために、Webex CC が提供する JavaScript SDK です。

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

図 1 に、CRM 埋め込み型 Webex CC デスクトップおよびコネクタのアーキテクチャを示します

Webex CC は、上記のインテグレーションに対して、次の CRM ソリューションをサポートします。

• Salesforce

• ServiceNow

• Microsoft Dynamics 365

• Zendesk

• フレッシュデスク

詳細は 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 アプリケーションを使用し、CRM アプリケーションに埋め込まれた Webex CC デスクトップがブラウザ上で発生します。

セキュリティ

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 での通話記録のレポートがサポートされます。

HTTPs コネクタを介したフローの統合は、

Webex CC Flow ビルダーは、Webex コントロール ハブで構成され、Webex CC Flow で使用される HTTPs コネクタを使用した、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://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

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

音声エッジ コンポーネントは、顧客ネットワーク/PSTN キャリアからの SIP トランクが終端することを許可します。これは、エッジ コンポーネントへの接続が許可されるホワイトリストの IP に基づいて有効になります。

コンピューティング インフラストラクチャのセキュリティ

Webex CC コンピューティング インスタンスは AWS でプロビジョンされ、サービスは複数の Namespace を持ち、各 Namespace へのアクセスは個別の認証情報で制限される Kubernetes クラスターの Pod として実行されます。

すべてのインフラストラクチャのプロビジョニングはコードを使用して行われ、手動の手順は必要ありません。また、資格情報に手動でアクセスすることはできません。

特定のサービス/チームのセットに対して構成された特定のパスを持つ中央の資格情報ストアがあり、資格情報ストア自体へのアクセスは制限され、ビルドおよび展開システムのシークレットとして構成されます。

インフラストラクチャ コンポーネント/サービスは AWS VPC の外部に直接公開されておらず、公開されているインターフェースは API および api ゲートウェイを使用して制御および管理されるウェブソケットサーバのみです。

これとは別に、ログ、メトリクス、展開の詳細、ビルドステータス、テスト結果を表示するために使用される、開発者が使用する特定の内部システムとインターフェイスがあります。これらは、ロールとグループを使用して保護され、Cisco 内部認証システムと統合されます。

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

さまざまなコンタクト センター ユーザ (エージェント、スーパーバイザー、管理者、アナリスト) が使用するすべてのユーザ インターフェイスは、Cisco Common Identity ベースのベアラー トークン認証 (OAuth フロー) によって保護されています。

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

データ転送中

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

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

すべての発信対話は https / TLS (http 以外のプロトコルの場合) 経由で行われます。

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

保存データ

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

図 1 は、転送時と保存時のデータフローとセキュリティモデルを示しています。

エンドユーザの PII データ

インタラクションを処理するためのプログラムによるコントローラーである Webex CC フローを使用すると、「機密データを含む」として特別にタグ付けされたフロー変数に割り当てることができるユーザ データを収集できます。 そのようなデータの値は暗号化され、データのトランジット パスにあるサービスはこのデータにアクセスできません。

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

コンタクトセンターのエージェント/スーパーバイザーの PII データ

コンタクトセンターのユーザ関連のデータはログ内では編集されていますが、データ分析と視覚化には Webex CC データストアが利用できます。

スケールの要素

Webex CC で規模に影響を与える要素は次のとおりです。

• 同時ログインエージェント数

• 進行中の同時インタラクション数

  • これらのインタラクションで実行されたアクション

• スーパーバイザー/エージェントが処理したインタラクション以外のアクションの同時数

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

スケールを可能にするアーキテクチャ的側面

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

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

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

ステートレス サービス (または外部化された状態)

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

エラスティック インフラストラクチャ

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

負荷予測と定期的な検証

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

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

テレフォニー

テレフォニーの場合、インバウンド音声通話の処理は、コールがコンタクト センターに入る方法 (下記の入力メカニズムを参照) と、エントリ ポイントに関連付けられている Webex CC フローによって決定されます。

通話に応答があり、以降のアクションは Webex CC フロー定義に従って実行されます。これは、エージェントをキューに入れてエージェントにルーティングする前の通話の処理中に実行されるアクションをプログラムで表したものであるか、フロー自体が通話を処理するかのいずれかです。エージェントに転送しないでください。

Webex CC の Flow Builder を使えば、開発者はフローを定義し、Webex CC で通話が着信する際に経由するエントリ ポイントに割り当てることができます。

これらの構成エンティティとその使用法については、 構成エンティティ。

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

メールとメッセージング

Webex CC の観点から、Webex Connect は、エンドユーザがコンタクトセンターに連絡するために使用できる、メール、メッセージング チャネルなど、すべてのデジタル チャネルの入力と出力の機能を提供します。

Webex 接続フロー

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

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

• キューに入る前の連絡を処理します。

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

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

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

• WhatsApp

• Facebook Messenger

• SMS

Webex CC でサポートされているメール チャネル:

• Gmail

• Office365

入力メカニズム

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

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

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

着信音声

音声通話の場合、一般的なシナリオでは、ユーザが PSTN 電話番号をダイヤルすると、それがコンタクトセンターに接続されます。 入力の観点から、これには PSTN から Webex CC にコールをルーティングするメカニズムが必要です。

図 1 は、Webex CC への音声通話の取り込みを示しています。

Webex CC の音声入力サービスは、SIP を使用してサードパーティの通話制御を実行し、着信通話に応答し、転送、電話会議、その他の通話制御操作を実行します。

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

これにより、電話番号への着信を検出し、通話を エントリポイントに関連付け、エントリポイントの他の構成パラメータを使用して、インタラクションでトリガーされる Webex CC フロー定義に従って通話を処理できます。

注：

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 を参照してください。

[LDAPシステム(IVR System)]

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

Webex CC Flow Builder は、アクティビティと呼ばれるプログラミング構成要素/演算子と機能ブロックを提供します。これにより、管理者や、IVR ロジックを設計および実装するユーザは、これらの構成要素を組み合わせて、フロー定義を作成できます。

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

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

  • Pebble 式で変数の値を設定する

• 条件チェック

• ループ – 条件分岐とジャンプを使用 (アクティビティを連結する機能)

• REST API の呼び出し

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

• アクティビティを作成する

フローが提供する代表的なアクティビティは以下の通りです。 メッセージを再生する ユーザデータの収集 通話を別の宛先/電話番号に転送する 通話をバーチャルエージェントに送信する エージェントが応答できるように通話をキューに入れます。

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

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

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

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 を参照してください。

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

フローは、対話を仮想エージェントにハンドオフするアクティビティを提供します。これは Webex Control Hub で事前設定されています。

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

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

インバウンド デジタル インタラクション

メール、および受信インタラクションのメッセージ チャネルについては、Webex Connect を利用してアセットをプロビジョニングし、フローで受信インタラクションを処理してから、そのインタラクションを Webex CC にルーティングします。エージェントが対応できます。

図 2 は、メールの取り込み、Webex CC でのメッセージングの対話を示しています。

仮想エージェント/ボットのインテグレーション

メールおよびメッセージング/ソーシャル チャネルの対話の場合、仮想エージェント/ボットの扱いは、Webex Connect フローで構成されます。

音声用仮想エージェントと同様に、ボットの処理が結果としてエスカレートして終了した場合、インタラクションはキューに入れられ、エージェントにルーティングされます。

エージェントの選択

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

• 対応可能な最長時間エージェント ルーティング

• 熟練ベースのルーティング

  • 最長対応エージェント (LAA)

  • 最適なエージェント (BAA)

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

キューには、通話分配グループがキューに追加されるのを待機するように設定された順番で、複数の通話分配グループを各グループに割り当てることができます。これにより、一致するエージェントの検索スペースが、追加のエージェントに拡大されます。時間の経過に応じて配信グループに発信します。

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

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

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

Webex CC フローは、アクティビティ QueueToAgent を使用して、エージェント ID に基づいて、選択されたエージェントにインタラクションを直接ルーティングできます。

エージェントがインタラクションを処理できない場合、インタラクションはエージェント専用のキューに保留され、エージェントが対応可能になるまで待機します

アドバンストキュー情報

Webex CC フローは、GetQueueInfo アクティビティを使用して、キュー内の位置 (PIQ)、推定待ち時間 (EWT)、キューで応答可能なエージェント数などのキューのリアルタイム情報を取得できます。連絡先をキューに入れるかどうかを指定します。

無料のコールバック

Webex CC フローは、アクティビティ コールバックを使用して、顧客がキュー内の位置を維持しながら通話を切断し、キュー内のバーチャル インタラクションがエージェントにルーティングされたときにコールバックを受信できるようにします。

オーバーフロー処理

Webex CC は Capacity Based Teams (CBT) を使用したオーバーフロー処理をサポートします。

CBT は定員を持つ通常のチームのようなもので、その定員に対応する外部 DN が関連付けられます。 これは、キュー コール分配サイクルで他のチームと共に構成できます。

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

IVR オペレーション

エージェントが Webex CC Agent Desktop にログインすると、エージェントへの着信コールを接続できる電話番号を指定します。 これには、PSTN 電話、携帯電話、またはエージェントが Cisco Webex Calling ユーザの場合は内線番号を指定できます。

この番号は、通話をルーティングできる有効な電話番号である必要があります。 存在しない場合、エージェントは着信コールを受けることができません。

エージェントが処理しているインタラクションのタイプに基づいて、エージェント デスクトップのウィジェットは、特定のメディア コントロール操作を実行する機能を提供します。

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

• 通話を保留にする

• コンサルト コールを開始し、

  • 別の電話番号 (たとえば、エージェントの電話番号) / エントリポイントに通話を転送する

  • コールする別のエージェントの電話会議

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

• 通話を終了する

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

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

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

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

Webex CC Agent Desktop は Cisco Common Identity (CI) でユーザを認証し、トークンは API のすべての呼び出しに渡されます。 カスタム ウィジェットについても、認証モデルに基づいて、カスタム ウィジェットの認証モデルが CI と統合されている場合、エージェントにシングル サインオンのエクスペリエンスを提供します。

エージェントがインタラクションの一部になると、そのインタラクション状態または関連するデータに対するすべての更新も、WebSocket 接続を介してデスクトップにプッシュされます。

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

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

図 2 に、Webex CC でのエージェント デスクトップ アーキテクチャを示します。

オンボーディングの顧客

Webex Control Hub は、パートナーや顧客が顧客のオンボーディングや機能の有効化や設定を行うために使用する主要なインターフェイスです。

組織とコンタクト センターの機能が Control Hub でプロビジョニングされると、Webex CC でワークフローがトリガーされます。このワークフローは、顧客が選択したサービスに応じて、コンタクト センターのすべての機能をプロビジョニングするための残りの手順を行います。

すべてのコンタクトセンターのプロビジョニングは、BPM ワークフローエンジンを使用して行われます。これにより、関連するステップを宣言的な方法で定義でき、プロビジョニングステップ全体で障害に対する復元力があり、データの整合性が保証されます。

図 1 は、Webex CC でのプロビジョニング ワークフローを示しています。

構成エンティティ

組織内を範囲とする、Webex CC の主な構成エンティティは次のとおりです。

サイト

サイトとは、1 つまたは複数のチーム、ユーザ (エージェント/スーパーバイザー) が配置されている場所を意味します。

すべてのユーザとチームは 1 つのサイトに属している必要があります。

チーム（Team）

ユーザのグループ。 チームは、キューを介してエージェントにインタラクションを配信するために使用されます。

すべてのチームは 1 つのサイトに属している必要があります。

エージェント

Agent Desktop にログインして、Webex CC で設定されたメディア タイプ全体のインタラクションを処理できるユーザ。

スーパーバイザ

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

キュー（Queue）

キューは、エージェントが利用可能になるのを待っている間に、対話を保留できる論理エンティティであり、エージェントにルーティングされます。

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

エントリポイント

エントリーポイントは、Webex CC へのインタラクションのイングレス ポイントを表す論理エンティティです。テレフォニーの場合、これは主に着信の電話番号にマッピングされます。メール/メッセージング チャネルの場合、エントリポイントは Webex Connect のアセット構成をポイントします。

フロー

インタラクションの処理に関連するステップを決定するエントリ ポイント (ルーティング戦略経由) に関連付けられたフロー。

テレフォニー以外のチャネル (メール、メッセージング/ソーシャル) の場合、フローは Webex Connect のアセット設定の一部として選択されます。

マルチサイトコンタクトセンターのアクセスコントロール

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

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

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

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

デスクトップ埋め込みコネクタ: プライマリ インターフェイスとしての CRM アプリケーション

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

Webex CC は埋め込みアプリケーション (埋め込みデスクトップアプリケーションまたは埋め込みソフトフォンとも呼ばれます) で、主にコンタクトセンターにログインし、Webex CC ルーティングされたコンタクトセンターでの対話を受信するために使用されます。

CRM 連携は、通話または会話リクエストを受信すると、CRM コンソール上で以下のアクションを実行します。

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

• 顧客レコード上の活動メモとしての通話後のメタデータ

• エージェントが CRM 内の連絡先をクリックし、顧客にアウトバウンド コールを発信することで、「クリック ツー コール」を許可する

• CRM のプライマリレポート用に、CRM レポートテーブルに通話記録を転記する。

• Agent Desktop の完全な機能と通話コントロール (デスクトップ アプリの埋め込みおよび縮小バージョン) を提供します

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

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

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

• Webex CC デスクトップ JavaScript SDK は、エージェントおよびコンタクト アクションのイベント リスナを登録するために、Webex CC が提供する JavaScript SDK です。

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

図 1 に、CRM 埋め込み型 Webex CC デスクトップおよびコネクタのアーキテクチャを示します

Webex CC は、上記のインテグレーションに対して、次の CRM ソリューションをサポートします。

• Salesforce

• ServiceNow

• Microsoft Dynamics 365

• Zendesk

• フレッシュデスク

詳細は 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 アプリケーションを使用し、CRM アプリケーションに埋め込まれた Webex CC デスクトップがブラウザ上で発生します。

セキュリティ

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 での通話記録のレポートがサポートされます。

HTTPs コネクタを介したフローの統合は、

Webex CC Flow ビルダーは、Webex コントロール ハブで構成され、Webex CC Flow で使用される HTTPs コネクタを使用した、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://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

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

音声エッジ コンポーネントは、顧客ネットワーク/PSTN キャリアからの SIP トランクが終端することを許可します。これは、エッジ コンポーネントへの接続が許可されるホワイトリストの IP に基づいて有効になります。

コンピューティング インフラストラクチャのセキュリティ

Webex CC コンピューティング インスタンスは AWS でプロビジョンされ、サービスは複数の Namespace を持ち、各 Namespace へのアクセスは個別の認証情報で制限される Kubernetes クラスターの Pod として実行されます。

すべてのインフラストラクチャのプロビジョニングはコードを使用して行われ、手動の手順は必要ありません。また、資格情報に手動でアクセスすることはできません。

特定のサービス/チームのセットに対して構成された特定のパスを持つ中央の資格情報ストアがあり、資格情報ストア自体へのアクセスは制限され、ビルドおよび展開システムのシークレットとして構成されます。

インフラストラクチャ コンポーネント/サービスは AWS VPC の外部に直接公開されておらず、公開されているインターフェースは API および api ゲートウェイを使用して制御および管理されるウェブソケットサーバのみです。

これとは別に、ログ、メトリクス、展開の詳細、ビルドステータス、テスト結果を表示するために使用される、開発者が使用する特定の内部システムとインターフェイスがあります。これらは、ロールとグループを使用して保護され、Cisco 内部認証システムと統合されます。

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

さまざまなコンタクト センター ユーザ (エージェント、スーパーバイザー、管理者、アナリスト) が使用するすべてのユーザ インターフェイスは、Cisco Common Identity ベースのベアラー トークン認証 (OAuth フロー) によって保護されています。

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

データ転送中

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

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

すべての発信対話は https / TLS (http 以外のプロトコルの場合) 経由で行われます。

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

保存データ

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

図 1 は、転送時と保存時のデータフローとセキュリティモデルを示しています。

エンドユーザの PII データ

インタラクションを処理するためのプログラムによるコントローラーである Webex CC フローを使用すると、「機密データを含む」として特別にタグ付けされたフロー変数に割り当てることができるユーザ データを収集できます。 そのようなデータの値は暗号化され、データのトランジット パスにあるサービスはこのデータにアクセスできません。

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

コンタクトセンターのエージェント/スーパーバイザーの PII データ

コンタクトセンターのユーザ関連のデータはログ内では編集されていますが、データ分析と視覚化には Webex CC データストアが利用できます。

スケールの要素

Webex CC で規模に影響を与える要素は次のとおりです。

• 同時ログインエージェント数

• 進行中の同時インタラクション数

  • これらのインタラクションで実行されたアクション

• スーパーバイザー/エージェントが処理したインタラクション以外のアクションの同時数

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

スケールを可能にするアーキテクチャ的側面

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

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

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

ステートレス サービス (または外部化された状態)

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

エラスティック インフラストラクチャ

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

負荷予測と定期的な検証

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

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

テレフォニー

テレフォニーの場合、インバウンドの音声通話の処理は、コールがコンタクト センターに入る方法 (下記の入力メカニズムを参照) と、エントリ ポイントに関連付けられている Webex CC フローによって決定されます。

通話に応答があり、以降のアクションは Webex CC フロー定義に従って実行されます。これは、エージェントをキューに入れてルーティングする前の通話の処理中に実行されるアクションをプログラムで表したものであるか、フロー自体が通話を処理することができます。エージェントに転送しないでください。

Webex CC の Flow Builder を使えば、開発者はフローを定義し、Webex CC で通話が着信する際に経由するエントリ ポイントに割り当てることができます。

これらの構成エンティティとその使用法については、 構成エンティティ。

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

メールとメッセージング

Webex CC の観点から、Webex Connect は、エンドユーザがコンタクトセンターとコンタクトするために使用できる、メール、メッセージング チャネルなど、すべてのデジタル チャネルの入力と出力の機能を提供します。

Webex Connect フロー

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

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

• キューに入る前の連絡を処理します。

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

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

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

• WhatsApp

• Facebook Messenger

• SMS

Webex CC でサポートされているメール チャネル:

• Gmail

• Office365

入力メカニズム

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

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

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

着信音声

音声通話の場合、一般的なシナリオでは、ユーザが PSTN 電話番号をダイヤルすると、それがコンタクトセンターに接続されます。 入力の観点から、これには PSTN から Webex CC にコールをルーティングするメカニズムが必要です。

次の図は、Webex CC への音声通話の取り込みを示しています。

Webex CC の音声入力サービスは、SIP を使用してサードパーティの通話制御を実行し、着信通話に応答し、転送、電話会議、その他の通話制御操作を実行します。

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

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

注：

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 を参照してください。

[LDAPシステム(IVR System)]

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

Webex CC Flow Builder は、アクティビティと呼ばれるプログラミング構成要素/演算子と機能ブロックを提供するため、管理者や、IVR ロジックを設計および実装するユーザは、これらの構成要素を組み合わせて、フロー定義を作成できます。

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

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

  • Pebble 式で変数の値を設定する

• 条件チェック

• ループ – 条件分岐とジャンプを使用 (アクティビティを連結する機能)

• REST API の呼び出し

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

• アクティビティを作成する

フローが提供する代表的なアクティビティは以下の通りです。 メッセージを再生する ユーザデータの収集 通話を別の宛先/電話番号に転送する 通話をバーチャルエージェントに送信する エージェントが応答できるように通話をキューに入れます。

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

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

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

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 を参照してください。

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

フローは、対話を仮想エージェントにハンドオフするアクティビティを提供します。これは Webex Control Hub で事前設定されています。

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

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

インバウンド デジタル インタラクション

メール、および受信インタラクションのメッセージング チャネルについては、Webex CC はアセットのプロビジョニングに Webex Connect を利用し、受信インタラクションを処理するためのフローをフローします。エージェントが対応できます。

次の図は、メールの取り込み、Webex CC でのメッセージングの対話を示しています。

仮想エージェント/ボットのインテグレーション

メールおよびメッセージング/ソーシャル チャネルの対話の場合、仮想エージェント/ボットの扱いは Webex Connect フローで構成されます。

音声用仮想エージェントと同様に、ボットの処理が結果としてエスカレートして終了した場合、インタラクションはキューに入れられ、エージェントにルーティングされます。

エージェントの選択

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

• 対応可能な最長時間エージェント ルーティング

• 熟練ベースのルーティング

  • 最長対応エージェント (LAA)

  • 最適なエージェント (BAA)

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

キューには、通話分配グループがキューに追加されるのを待機するように設定された順番で、複数の通話分配グループを各グループに割り当てることができます。これにより、一致するエージェントの検索スペースが、追加のエージェントに拡大されます。時間の経過に応じて配信グループに発信します。

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

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

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

Webex CC フローは、アクティビティ QueueToAgent を使用して、エージェント ID に基づいて、選択されたエージェントにインタラクションを直接ルーティングできます。

エージェントがインタラクションを処理できない場合、インタラクションはエージェント専用のキューに保留され、エージェントが対応可能になるまで待機します

アドバンストキュー情報

Webex CC フローは、GetQueueInfo アクティビティを使用して、キュー内の位置 (PIQ)、推定待ち時間 (EWT)、キューで応答可能なエージェント数などのキューのリアルタイム情報を取得できます。連絡先をキューに入れるかどうかを指定します。

無料のコールバック

Webex CC フローでは、アクティビティ コールバックを使用して、顧客がキュー内の位置を維持しながら通話を切断し、キュー内のバーチャル インタラクションがエージェントにルーティングされたときにコールバックを受信できるようにします。

オーバーフロー処理

Webex CC は Capacity Based Teams (CBT) を使用したオーバーフロー処理をサポートします。

CBT は定員を持つ通常のチームのようなもので、その定員に対応する外部 DN が関連付けられます。 これは、キュー コール分配サイクルで他のチームと共に構成できます。

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

IVR オペレーション

エージェントが Webex CC Agent Desktop にログインすると、エージェントへの着信コールを接続できる電話番号を指定します。 これには、PSTN 電話、携帯電話、またはエージェントが Cisco Webex Calling ユーザの場合は内線番号を指定できます。

この番号は、通話をルーティングできる有効な電話番号である必要があります。 存在しない場合、エージェントは着信コールを受けることができません。

エージェントが処理しているインタラクションのタイプに基づいて、エージェント デスクトップのウィジェットは、特定のメディア コントロール操作を実行する機能を提供します。

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

• 通話を保留にする

• コンサルト コールを開始し、

  • 別の電話番号 (たとえば、エージェントの電話番号) / エントリポイントに通話を転送する

  • コールする別のエージェントの電話会議

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

• 通話を終了する

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

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

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

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

Webex CC Agent Desktop は Cisco Common Identity (CI) でユーザを認証し、トークンはすべての API 呼び出しに渡されます。 カスタム ウィジェットについても、認証モデルに基づいて、カスタム ウィジェットの認証モデルが CI と統合されている場合、エージェントにシングル サインオンのエクスペリエンスを提供します。

エージェントがインタラクションの一部になると、そのインタラクション状態または関連するデータに対するすべての更新も、WebSocket 接続を介してデスクトップにプッシュされます。

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

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

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

オンボーディングの顧客

Webex Control Hub は、パートナーや顧客が顧客のオンボーディングや機能の有効化や設定を行うために使用する主要なインターフェイスです。

組織とコンタクト センターの機能が Control Hub でプロビジョニングされると、Webex CC でワークフローがトリガーされます。このワークフローは、顧客が選択したサービスに応じて、コンタクト センターのすべての機能をプロビジョニングするための残りの手順を行います。

すべてのコンタクトセンターのプロビジョニングは、BPM ワークフローエンジンを使用して行われます。これにより、関連するステップを宣言的な方法で定義でき、プロビジョニングステップ全体で障害に対する復元力があり、データの整合性が保証されます。

次の図は、Webex CC でのプロビジョニング ワークフローを示しています。

構成エンティティ

組織内を範囲とする、Webex CC の主な構成エンティティは次のとおりです。

サイト

サイトとは、1 つまたは複数のチーム、ユーザ (エージェント/スーパーバイザー) が配置されている場所を意味します。

すべてのユーザとチームは 1 つのサイトに属している必要があります。

チーム（Team）

ユーザのグループ。 チームは、キューを介してエージェントにインタラクションを配信するために使用されます。

すべてのチームは 1 つのサイトに属している必要があります。

エージェント

Agent Desktop にログインして、Webex CC で設定されたメディア タイプ全体のインタラクションを処理できるユーザ。

スーパーバイザ

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

キュー（Queue）

キューは、エージェントが利用可能になるのを待っている間に、対話を保留できる論理エンティティであり、エージェントにルーティングされます。

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

エントリポイント

エントリーポイントは、Webex CC へのインタラクションのイングレス ポイントを表す論理エンティティです。テレフォニーの場合、これは主に着信の電話番号にマッピングされ、メール/メッセージング チャネルの場合、エントリポイントは Webex Connect のアセット構成をポイントします。

フロー

インタラクションの処理に関連するステップを決定するエントリ ポイント (ルーティング戦略経由) に関連付けられたフロー。

テレフォニー以外のチャネル (メール、メッセージング/ソーシャル) の場合、フローは Webex Connect のアセット設定の一部として選択されます。

マルチサイトコンタクトセンターのアクセスコントロール

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

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

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

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

デスクトップ埋め込みコネクタ: プライマリ インターフェイスとしての CRM アプリケーション

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

Webex CC は埋め込みアプリケーション (埋め込みデスクトップアプリケーションまたは埋め込みソフトフォンとも呼ばれます) で、主にコンタクトセンターにログインし、Webex CC ルーティングされたコンタクトセンターでの対話を受信するために使用されます。

CRM 連携は、通話または会話リクエストを受信すると、CRM コンソール上で以下のアクションを実行します。

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

• 顧客レコード上の活動メモとしての通話後のメタデータ

• エージェントが CRM 内の連絡先をクリックし、顧客にアウトバウンド コールを発信することで、「クリック ツー コール」を許可する

• CRM のプライマリレポート用に、CRM レポートテーブルに通話記録を転記する。

• Agent Desktop の完全な機能と通話コントロール (デスクトップ アプリの埋め込みおよび縮小バージョン) を提供します

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

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

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

• Webex CC デスクトップ JavaScript SDK: これは、エージェントおよびコンタクト アクションのイベント リスナを登録するために、Webex CC により提供される JavaScript SDK です。

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

次の図は、CRM 埋め込み型 Webex CC デスクトップおよびコネクタ アーキテクチャを示しています。

Webex CC は上記のインテグレーションに対して、次の CRM ソリューションをサポートします。

• Salesforce

• ServiceNow

• Microsoft Dynamics 365

• Zendesk

• フレッシュデスク

詳細は 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-integrations を参照してください。

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

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

柔軟なスケールとパフォーマンス

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

すべての CRM 統合固有の計算は、エージェントが Webex CC デスクトップを CRM アプリケーションに埋め込んで 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 での通話記録のレポートがサポートされます。

HTTPs コネクタを介したフローの統合は、

Webex CC Flow Builder は、Webex コントロール ハブで構成され、Webex CC Flow で使用される HTTPs コネクタを使用した、Webex CC と CRM システム間の双方向のデータ フローをサポートします。

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

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

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://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

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

音声エッジ コンポーネントは、顧客ネットワーク/PSTN キャリアからの SIP トランクが終端することを許可します。これは、エッジ コンポーネントへの接続が許可されるホワイトリストの IP に基づいて有効になります。

コンピューティング インフラストラクチャのセキュリティ

Webex CC コンピューティング インスタンスは AWS でプロビジョニングされ、サービスは複数の Namespace を持ち、各 Namespace へのアクセスは個別の資格情報で制限される Kubernetes クラスターのポッドとして実行されます。

すべてのインフラストラクチャのプロビジョニングはコードを使用して行われ、手動の手順は必要ありません。また、資格情報に手動でアクセスすることはできません。

特定のサービス/チームのセットに対して構成された特定のパスを持つ中央の資格情報ストアがあり、資格情報ストア自体へのアクセスは制限され、ビルドおよび展開システムのシークレットとして構成されます。

インフラストラクチャ コンポーネント/サービスは AWS VPC の外部に直接公開されておらず、公開されているインターフェースは API および api ゲートウェイを使用して制御および管理されるウェブソケットサーバのみです。

これとは別に、ログ、メトリクス、展開の詳細、ビルドステータス、テスト結果を表示するために使用される、開発者が使用する特定の内部システムとインターフェイスがあります。これらは、ロールとグループを使用して保護され、Cisco 内部認証システムと統合されます。

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

さまざまなコンタクト センター ユーザ (エージェント、スーパーバイザー、管理者、アナリスト) が使用するすべてのユーザ インターフェイスは、Cisco Common Identity ベースのベアラー トークン認証 (OAuth フロー) によって保護されています。

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

データ転送中

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

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

すべての発信対話は https / TLS (http 以外のプロトコルの場合) 経由で行われます。

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

保存データ

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

次の図は、転送時と保存時のデータ フローとセキュリティ モデルを示しています。

エンドユーザの PII データ

インタラクションを処理するためのプログラムによるコントローラーである Webex CC フローを使用すると、「機密データを含む」として特別にタグ付けされたフロー変数に割り当てることができるユーザ データを収集できます。 そのようなデータの値は暗号化され、データのトランジット パスにあるサービスはこのデータにアクセスできません。

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

コンタクトセンターのエージェント/スーパーバイザーの PII データ

コンタクトセンターのユーザ関連のデータはログ内では編集されていますが、データ分析と視覚化には Webex CC データストアが利用できます。

スケールの要素

Webex CC で規模に影響を与える要素は次のとおりです。

• 同時ログインエージェント数

• 進行中の同時インタラクション数

  • これらのインタラクションで実行されたアクション

• スーパーバイザー/エージェントが処理したインタラクション以外のアクションの同時数

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

スケールを可能にするアーキテクチャ的側面

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

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

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

ステートレス サービス (または外部化された状態)

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

エラスティック インフラストラクチャ

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

負荷予測と定期的な検証

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

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

テレフォニー

テレフォニーの場合、インバウンドの音声通話の処理は、コールがコンタクト センターに入る方法 (下記の入力メカニズムを参照) と、エントリ ポイントに関連付けられている Webex CC フローによって決定されます。

通話に応答があり、以降のアクションは Webex CC フロー定義に従って実行されます。これは、エージェントをキューに入れてルーティングする前の通話の処理中に実行されるアクションをプログラムで表したものであるか、フロー自体が通話を処理することができます。エージェントに転送しないでください。

Webex CC の Flow Builder を使えば、開発者はフローを定義し、Webex CC で通話が着信する際に経由するエントリ ポイントに割り当てることができます。

これらの構成エンティティとその使用法については、 構成エンティティ。

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

メールとメッセージング

Webex CC の観点から、Webex Connect は、エンドユーザがコンタクトセンターとコンタクトするために使用できる、メール、メッセージング チャネルなど、すべてのデジタル チャネルの入力と出力の機能を提供します。

Webex Connect フロー

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

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

• キューに入る前の連絡を処理します。

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

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

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

• WhatsApp

• Facebook Messenger

• SMS

Webex CC でサポートされているメール チャネル:

• Gmail

• Office365

入力メカニズム

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

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

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

着信音声

音声通話の場合、一般的なシナリオでは、ユーザが PSTN 電話番号をダイヤルすると、それがコンタクトセンターに接続されます。 入力の観点から、これには PSTN から Webex CC にコールをルーティングするメカニズムが必要です。

次の図は、Webex CC への音声通話の取り込みを示しています。

Webex CC の音声入力サービスは、SIP を使用してサードパーティの通話制御を実行し、着信通話に応答し、転送、電話会議、その他の通話制御操作を実行します。

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

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

注：

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 を参照してください。

[LDAPシステム(IVR System)]

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

Webex CC Flow Builder は、アクティビティと呼ばれるプログラミング構成要素/演算子と機能ブロックを提供するため、管理者や、IVR ロジックを設計および実装するユーザは、これらの構成要素を組み合わせて、フロー定義を作成できます。

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

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

  • Pebble 式で変数の値を設定する

• 条件チェック

• ループ – 条件分岐とジャンプを使用 (アクティビティを連結する機能)

• REST API の呼び出し

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

• アクティビティを作成する

フローが提供する代表的なアクティビティは以下の通りです。 メッセージを再生する ユーザデータの収集 通話を別の宛先/電話番号に転送する 通話をバーチャルエージェントに送信する エージェントが応答できるように通話をキューに入れます。

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

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

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

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 を参照してください。

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

フローは、対話を仮想エージェントにハンドオフするアクティビティを提供します。これは Webex Control Hub で事前設定されています。

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

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

インバウンド デジタル インタラクション

メール、および受信インタラクションのメッセージング チャネルについては、Webex CC はアセットのプロビジョニングに Webex Connect を利用し、受信インタラクションを処理するためのフローをフローします。エージェントが対応できます。

次の図は、メールの取り込み、Webex CC でのメッセージングの対話を示しています。

仮想エージェント/ボットのインテグレーション

メールおよびメッセージング/ソーシャル チャネルの対話の場合、仮想エージェント/ボットの扱いは、Webex Connect フローで構成されます。

音声用仮想エージェントと同様に、ボットの処理が結果としてエスカレートして終了した場合、インタラクションはキューに入れられ、エージェントにルーティングされます。

エージェントの選択

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

• 対応可能な最長時間エージェント ルーティング

• 熟練ベースのルーティング

  • 最長対応エージェント (LAA)

  • 最適なエージェント (BAA)

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

キューには、通話分配グループがキューに追加されるのを待機するように設定された順番で、複数の通話分配グループを各グループに割り当てることができます。これにより、一致するエージェントの検索スペースが、追加のエージェントに拡大されます。時間の経過に応じて配信グループに発信します。

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

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

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

Webex CC フローは、アクティビティ QueueToAgent を使用して、エージェント ID に基づいて、選択されたエージェントにインタラクションを直接ルーティングできます。

エージェントがインタラクションを処理できない場合、インタラクションはエージェント専用のキューに保留され、エージェントが対応可能になるまで待機します

アドバンストキュー情報

Webex CC フローは、GetQueueInfo アクティビティを使用して、キュー内の位置 (PIQ)、推定待ち時間 (EWT)、キューで応答可能なエージェント数などのキューのリアルタイム情報を取得できます。連絡先をキューに入れるかどうかを指定します。

無料のコールバック

Webex CC フローでは、アクティビティ コールバックを使用して、顧客がキュー内の位置を維持しながら通話を切断し、キュー内のバーチャル インタラクションがエージェントにルーティングされたときにコールバックを受信できるようにします。

オーバーフロー処理

Webex CC は Capacity Based Teams (CBT) を使用したオーバーフロー処理をサポートします。

CBT は定員を持つ通常のチームのようなもので、その定員に対応する外部 DN が関連付けられます。 これは、キュー コール分配サイクルで他のチームと共に構成できます。

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

IVR オペレーション

エージェントが Webex CC Agent Desktop にログインすると、エージェントへの着信コールを接続できる電話番号を指定します。 これには、PSTN 電話、携帯電話、またはエージェントが Cisco Webex Calling ユーザの場合は内線番号を指定できます。

この番号は、通話をルーティングできる有効な電話番号である必要があります。 存在しない場合、エージェントは着信コールを受けることができません。

エージェントが処理しているインタラクションのタイプに基づいて、エージェント デスクトップのウィジェットは、特定のメディア コントロール操作を実行する機能を提供します。

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

• 通話を保留にする

• コンサルト コールを開始し、

  • 別の電話番号 (たとえば、エージェントの電話番号) / エントリポイントに通話を転送する

  • コールする別のエージェントの電話会議

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

• 通話を終了する

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

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

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

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

Webex CC Agent Desktop は Cisco Common Identity (CI) でユーザを認証し、トークンはすべての API 呼び出しに渡されます。 カスタム ウィジェットについても、認証モデルに基づいて、カスタム ウィジェットの認証モデルが CI と統合されている場合、エージェントにシングル サインオンのエクスペリエンスを提供します。

エージェントがインタラクションの一部になると、そのインタラクション状態または関連するデータに対するすべての更新も、WebSocket 接続を介してデスクトップにプッシュされます。

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

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

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

オンボーディングの顧客

Webex Control Hub は、パートナーや顧客が顧客のオンボーディングや機能の有効化や設定を行うために使用する主要なインターフェイスです。

組織とコンタクト センターの機能が Control Hub でプロビジョニングされると、Webex CC でワークフローがトリガーされます。このワークフローは、顧客が選択したサービスに応じて、コンタクト センターのすべての機能をプロビジョニングするための残りの手順を行います。

すべてのコンタクトセンターのプロビジョニングは、BPM ワークフローエンジンを使用して行われます。これにより、関連するステップを宣言的な方法で定義でき、プロビジョニングステップ全体で障害に対する復元力があり、データの整合性が保証されます。

次の図は、Webex CC でのプロビジョニング ワークフローを示しています。

構成エンティティ

組織内を範囲とする、Webex CC の主な構成エンティティは次のとおりです。

サイト

サイトとは、1 つまたは複数のチーム、ユーザ (エージェント/スーパーバイザー) が配置されている場所を意味します。

すべてのユーザとチームは 1 つのサイトに属している必要があります。

チーム（Team）

ユーザのグループ。 チームは、キューを介してエージェントにインタラクションを配信するために使用されます。

すべてのチームは 1 つのサイトに属している必要があります。

エージェント

Agent Desktop にログインして、Webex CC で設定されたメディア タイプ全体のインタラクションを処理できるユーザ。

スーパーバイザ

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

キュー（Queue）

キューは、エージェントが利用可能になるのを待っている間に、対話を保留できる論理エンティティであり、エージェントにルーティングされます。

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

エントリポイント

エントリーポイントは、Webex CC へのインタラクションのイングレス ポイントを表す論理エンティティです。テレフォニーの場合、これは主に着信の電話番号にマッピングされ、メール/メッセージング チャネルの場合、エントリポイントは Webex Connect のアセット構成をポイントします。

フロー

インタラクションの処理に関連するステップを決定するエントリ ポイント (ルーティング戦略経由) に関連付けられたフロー。

テレフォニー以外のチャネル (メール、メッセージング/ソーシャル) の場合、フローは Webex Connect のアセット設定の一部として選択されます。

マルチサイトコンタクトセンターのアクセスコントロール

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

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

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

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

デスクトップ埋め込みコネクタ: プライマリ インターフェイスとしての CRM アプリケーション

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

Webex CC は埋め込みアプリケーション (埋め込みデスクトップアプリケーションまたは埋め込みソフトフォンとも呼ばれます) で、主にコンタクトセンターにログインし、Webex CC ルーティングされたコンタクトセンターでの対話を受信するために使用されます。

CRM 連携は、通話または会話リクエストを受信すると、CRM コンソール上で以下のアクションを実行します。

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

• 顧客レコード上の活動メモとしての通話後のメタデータ

• エージェントが CRM 内の連絡先をクリックし、顧客にアウトバウンド コールを発信することで、「クリック ツー コール」を許可する

• CRM のプライマリレポート用に、CRM レポートテーブルに通話記録を転記する。

• Agent Desktop の完全な機能と通話コントロール (デスクトップ アプリの埋め込みおよび縮小バージョン) を提供します

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

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

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

• Webex CC デスクトップ JavaScript SDK: これは、エージェントおよびコンタクト アクションのイベント リスナを登録するために、Webex CC により提供される JavaScript SDK です。

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

次の図は、CRM 埋め込み型 Webex CC デスクトップおよびコネクタ アーキテクチャを示しています。

Webex CC は上記のインテグレーションに対して、次の CRM ソリューションをサポートします。

• Salesforce

• ServiceNow

• Microsoft Dynamics 365

• Zendesk

• フレッシュデスク

詳細は 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-integrations を参照してください。

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

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

柔軟なスケールとパフォーマンス

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

すべての CRM 統合固有の計算は、エージェントが Webex CC デスクトップを CRM アプリケーションに埋め込んで 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 での通話記録のレポートがサポートされます。

HTTPs コネクタを介したフローの統合は、

Webex CC Flow Builder は、Webex コントロール ハブで構成され、Webex CC Flow で使用される HTTPs コネクタを使用した、Webex CC と CRM システム間の双方向のデータ フローをサポートします。

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

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

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://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

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

音声エッジ コンポーネントは、顧客ネットワーク/PSTN キャリアからの SIP トランクが終端することを許可します。これは、エッジ コンポーネントへの接続が許可されるホワイトリストの IP に基づいて有効になります。

コンピューティング インフラストラクチャのセキュリティ

Webex CC コンピューティング インスタンスは AWS でプロビジョニングされ、サービスは複数の Namespace を持ち、各 Namespace へのアクセスは個別の資格情報で制限される Kubernetes クラスターのポッドとして実行されます。

すべてのインフラストラクチャのプロビジョニングはコードを使用して行われ、手動の手順は必要ありません。また、資格情報に手動でアクセスすることはできません。

特定のサービス/チームのセットに対して構成された特定のパスを持つ中央の資格情報ストアがあり、資格情報ストア自体へのアクセスは制限され、ビルドおよび展開システムのシークレットとして構成されます。

インフラストラクチャ コンポーネント/サービスは AWS VPC の外部に直接公開されておらず、公開されているインターフェースは API および api ゲートウェイを使用して制御および管理されるウェブソケットサーバのみです。

これとは別に、ログ、メトリクス、展開の詳細、ビルドステータス、テスト結果を表示するために使用される、開発者が使用する特定の内部システムとインターフェイスがあります。これらは、ロールとグループを使用して保護され、Cisco 内部認証システムと統合されます。

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

さまざまなコンタクト センター ユーザ (エージェント、スーパーバイザー、管理者、アナリスト) が使用するすべてのユーザ インターフェイスは、Cisco Common Identity ベースのベアラー トークン認証 (OAuth フロー) によって保護されています。

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

データ転送中

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

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

すべての発信対話は https / TLS (http 以外のプロトコルの場合) 経由で行われます。

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

保存データ

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

次の図は、転送時と保存時のデータ フローとセキュリティ モデルを示しています。

エンドユーザの PII データ

インタラクションを処理するためのプログラムによるコントローラーである Webex CC フローを使用すると、「機密データを含む」として特別にタグ付けされたフロー変数に割り当てることができるユーザ データを収集できます。 そのようなデータの値は暗号化され、データのトランジット パスにあるサービスはこのデータにアクセスできません。

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

コンタクトセンターのエージェント/スーパーバイザーの PII データ

コンタクトセンターのユーザ関連のデータはログ内では編集されていますが、データ分析と視覚化には Webex CC データストアが利用できます。

スケールの要素

Webex CC で規模に影響を与える要素は次のとおりです。

• 同時ログインエージェント数

• 進行中の同時インタラクション数

  • これらのインタラクションで実行されたアクション

• スーパーバイザー/エージェントが処理したインタラクション以外のアクションの同時数

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

スケールを可能にするアーキテクチャ的側面

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

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

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

ステートレス サービス (または外部化された状態)

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

エラスティック インフラストラクチャ

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

負荷予測と定期的な検証

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

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