翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Connect Customer でのシナリオとデプロイのアプローチ

Connect Customer はセルフサービス設定を提供し、さまざまな移行および統合オプションを使用して、あらゆる規模で動的、個人的、自然なカスタマーエンゲージメントを可能にします。このセクションでは、Connect Customer のワークロードを設計する際に考慮すべき以下のシナリオとデプロイアプローチについて説明します。

従来型コンタクトセンター

従来型のコンタクトセンターでは、複数のベンダーや各所のデータセンター間に配置されコンタクトに対応するための、テレフォニー、メディア、ネットワーキング、データベース、およびコンピューティングインフラストラクチャの、大規模なフットプリントを必要とします。個々のソリューションとベンダーには、そのバージョン管理、互換性、あるいはライセンスの競合を解決する際に対応すべき、ハードウェア、ソフトウェア、ネットワーキング、アーキテクチャ上の固有の要件が存在します。

ローカルおよびリモートのエージェントのハードウェアに対応するためには、異なるベンダーやインフラストラクチャーを使用するのが一般的です。またこれにより、VPN 接続、テキスト読み上げ (TTS)、Automatic Call Distribution (ACD)、Interactive Voice Response (IVR)、音声や音響ならびにデータ、物理的なデスクフォン、音声録音、音声の文字起こし、チャット、レポート作成、データベース、Computer Telephony Integration (CTI)、自動音声認識 (ASR)、自然言語理解 (NLP) にも対応できます。複数のステージにおよぶ開発、品質保証、テスト環境を考慮すると、コンタクトセンターのアーキテクチャとインフラストラクチャは、より複雑なものになります。

一般的な Connect Customer のデプロイでは、バージョニング、互換性、ライセンス、コンタクトセンターのテレフォニーインフラストラクチャ、メンテナンスに関連する多くの課題が解決または軽減されます。このサービスが提供する柔軟性により、新らたな場所でのインスタンスの作成は数分で完了できます。また、コンポーネントの移行を個別または並行して実行でき、個々のビジネス目標を最適に満たすことができます。IVR/ACD のフローを使用したり、サポート対象のウェブブラウザを介してエージェントのソフトフォンに音声とデータを配信したり、既存の電話番号を移植したりすることが可能です。さらに、ソフトフォンの通話を既存のデスクフォンにリダイレクトしたり、ASR と NLP のためにフロー内で Amazon Lex ボットをネイティブに呼び出したり、チャットと音声に対して共通のフローを適用したりできます。Connect Customer Contact Lens を使用すると、自動的な音声文字起こしの生成、キーワード識別や感情分析の実行、さらにコンタクトの分類などが行えます。エージェント CTI データおよびリアルタイム音声ストリーミングには、Connect Customer Agent Event Streams と Kinesis Video Streams を使用できます。また、開発、品質保証、テストのための環境を、複数のステージで追加コストなしで作成でき、料金体系も従量課金制でご利用いただけます。

インバウンド

インバウンドとは、コンタクトセンターがコンタクトを着信することで開始される、コミュニケーションに対する要求を表すためのコンタクトセンター用語です。問い合わせは、Connect Customer インスタンスにアクセスして、インバウンドセルフサービスを利用したり、音声やチャットなど、さまざまな方法でライブエージェントと話したりできます。音声コンタクトは PSTN を通過し、インスタンスに登録されている電話番号を介して Connect Customer Instance テレフォニーエントリポイントにルーティングされます。Connect Customer で電話番号を直接予約したり、既存の電話番号を移植したり、音声連絡先を Connect Customer に転送したりできます。Connect Customer は、サービスがサポートされているすべてのリージョンで、ローカル番号と通話料無料番号を提供できます。

Connect Customer インスタンスに登録された番号に通話が発信されるか、Connect Customer インスタンスに移植されると、呼び出した番号に関連付けられたフローが呼び出されます。フローは、コーディングの知識を必要とせずに設定が可能な、フローブロックを使用して定義されます。フローは、場合により対応経路の決定をアシストするための追加情報をコンタクトに要求しながら、コンタクトの処理と対応方法を決定し、その属性をコンタクトの詳細として保存します。また必要に応じて、そこまでの過程での詳細な通話内容とそのトランスクリプトのすべてとともに、コンタクトをエージェントにルーティングします。フローを通じて、 AWS Lambda 関数を呼び出して顧客情報をクエリしたり、Amazon Pinpoint などの他の AWS サービスを呼び出して SMS テキストメッセージを送信したり、Amazon Lex for NLU/NLP や Kinesis Video Streams などのネイティブ AWS サービス統合を使用して音声通話をリアルタイムでストリーミングしたりできます。

インバウンドコンタクトがエージェントとの対話を要求している場合、そのコンタクトはキューに格納された後、ルーティング設定に従い、ステータスが Available になったエージェントに対しルーティングされます。利用可能なエージェントの問い合わせが手動または自動承諾設定で承諾されると、Connect Customer は問い合わせをエージェントに接続します。

インバウンド問い合わせがチャットセッションのブラウザまたはモバイルアプリリクエストから送信されると、リクエストはウェブサービスまたは Amazon API Gateway エンドポイントにルーティングされ、Connect Customer Chat API を呼び出してリクエストで設定されたフローを呼び出します。チャットと音声では、同じフローを使用でき、このフローで定義されているロジックに基づいて、動的に管理されルーティングされたエクスペリエンスが提供されます。

アウトバウンド

Connect Customer を使用すると、ローカルエンドポイントと国際エンドポイントへのアウトバウンド問い合わせ試行をプログラムで実行し、問い合わせ間のエージェントセットアップ時間を短縮し、エージェントの生産性を向上させることができます。Connect Customer Streams API と StartOutboundVoiceContact を使用すると、独自のアウトバウンドソリューションを開発したり、CRM データを操作する既存のパートナー統合を活用して、問い合わせの動的でパーソナライズされたエクスペリエンスを作成し、問い合わせの処理に必要なツールとリソースをエージェントに付与したりできます。

アウトバウンドに対するキャンペーンは、通常、CRM からエクスポートされリストに分割された、コンタクトデータを使用して進められます。これらの問い合わせは優先され、プレビュー期間後にエージェントに配信されるか、Connect Customer Outbound API を使用してプログラムで連絡され、フローロジックによって駆動され、必要に応じてエージェントに接続されます。アウトバウンドコンタクトセンターの典型的なユースケースには、詐欺やサービスについてのアラート、回収、予約確認などがあります。

ハイブリッド

Connect Customer と従来のコンタクトセンターテクノロジーの間で問い合わせを転送する必要がある場合は、ハイブリッドモデルアーキテクチャを使用して、転送時に問い合わせデータを渡すことができます。たとえば、レガシーコンタクトセンタープラットフォームの営業ビジネスユニットは、Connect Customer に移行されたサービスビジネスユニットに通話を転送する必要がある場合があります。ハイブリッドアーキテクチャを使用しない場合、この通話の詳細が失われ、再び情報を得るためのコンタクトが必要となり得ます。これにより、処理時間が長くなる上に、同じ目的でのコンタクトが再度行われることもあります。

ハイブリッドアーキテクチャでは、予想される最大同時連絡先数と同じ数の電話番号と、Connect Customer とレガシーコンタクトセンタープラットフォームの両方がアクセスできる中間状態データベースを取得する必要があります。他のプラットフォームへの転送が必要な場合は、これらの電話番号の 1 つを一意の識別子として使用し、中間データベース内で使用中のフラグを付け、そのコンタクトの詳細を挿入します。転送の際には、その番号を ANI または DNIS として使用します。コンタクトが他のコンタクトセンタープラットフォームで受信されると、使用した固有の ANI または DNIS に基づいて、その詳細を中間データベースに照会します。ハイブリッドアーキテクチャは通常、関連して発生する追加のコストと複雑さのために、暫定的な移行ステップとして使用されます。

IVR のみ

Connect Customer を使用して、エージェントの母集団が従来のコンタクトセンタープラットフォームに留まっている間、問い合わせの IVR エクスペリエンスを向上させることができます。このアプローチでは、Connect Customer Flows を使用してセルフサービスとルーティングロジックを推進し、必要に応じて、レガシーコンタクトセンタープラットフォームのターゲットエージェントまたはエージェントキューに問い合わせを転送できます。

この図では、連絡先は Connect Customer インスタンスに登録されている電話番号をダイヤルしてサービスを行います。レガシーコンタクトセンタープラットフォーム上のエージェントに転送する必要がある場合は、 AWS Lambda 関数が呼び出され、使用可能な一意の電話番号をクエリし、使用中としてフラグを立て、関連する連絡先の詳細を中間データベースに書き込みます。その後、Lambda 関数から返された電話番号を使用して、このコンタクトがレガシーコンタクトセンターのプラットフォームに転送されます。その後、レガシーコンタクトセンターは、中間データベースでコンタクトの詳細に関するクエリを実行し、それの結果に応じたルーティングを行います。その後、データベース内のコンタクトデータをリセットして、電話番号を再度使用できるようにします。

エージェントのみ

このアプローチでは、従来のコンタクトセンター IVR が問い合わせの IVR セルフサービスとルーティングロジックを駆動し、必要に応じて問い合わせを Connect Customer に転送してエージェント母集団にルーティングします。

この図では、問い合わせ通話者は、レガシーコンタクトセンターのプラットフォームで取得された電話番号をダイヤルしています。Connect Customer のエージェントに転送する必要がある場合、レガシーコンタクトセンタープラットフォームは利用可能な一意の電話番号をクエリし、使用中としてフラグを立て、関連する連絡先の詳細を中間データベースに書き込みます。その後、問い合わせは、従来のコンタクトセンターのクエリによって返された電話番号を使用して Connect Customer に転送されます。Connect Customer は、中間データベースの問い合わせデータを使用して中間データベースから問い合わせの詳細をクエリし AWS Lambda、それに応じてルーティングしてリセットし、電話番号を再度使用できるようにします。

混成

このシナリオでは、IVR とエージェントが Connect Customer とレガシーコンタクトセンタープラットフォームで並行して動作し、サイト、エージェントグループ、またはline-of-business業務移行を許可する場合があります。

レガシーコンタクトセンターからの移行

新規または既存のワークロードについて Connect Customer を評価する場合は、いくつかの戦略を検討できます。Connect Customer と従来のコンタクトセンターソリューション間で問い合わせを転送する際に、問い合わせの詳細を含める必要がある状況では、移行が完了するまでハイブリッドモデルアーキテクチャが必要です。このセクションで説明するアプローチにより、特定の事業部門を段階的に移行することができ、トレーニングとサポートを管理し、変更に伴うリスクを軽減できます。

新しいワークロード

Connect Customer でまったく新しいワークロードを採用することで、既存のビジネスユニットの変更に伴うリスクを軽減し、柔軟性とデジタルイノベーションの可能性を高めることができます。ハイブリッドモデルによるアーキテクチャを必要としない、完全に新しいこのワークロードでは、複雑さは軽減され、ビジネスプロセスやエージェントの定型作業の変更による影響を受けず、また、市場投入までの時間が短縮されます。新しいワークロードを採用することで、使用量に基づく従量課金制のシステムを利用できます。コンタクトセンターのリソースでは、エンドユーザーに新しいエクスペリエンスを提供しながら、そのプラットフォームを評価するためのテストや実装を行い信頼を獲得できます。さらに、スキルと運用メカニズムを構築し、既存のワークロード全体にわたる大規模な移行に備えることもできます。

IVR ファースト

Connect Customer を使用して、エージェントの母集団が従来のコンタクトセンタープラットフォームに留まっている間、問い合わせの IVR エクスペリエンスを向上させることができます。このアプローチでは、Connect Customer Flows を使用してセルフサービスとルーティングロジックを推進し、必要に応じて、レガシーコンタクトセンタープラットフォームのターゲットエージェントまたはエージェントキューに問い合わせを転送できます。

IVR ラスト

このアプローチでは、従来のコンタクトセンター IVR が問い合わせの IVR セルフサービスとルーティングロジックを駆動し、必要に応じて問い合わせを Connect Customer に転送してエージェント母集団にルーティングします。

事業部門のセグメンテーション

各業務部門が別々の IVR を持っている場合、またはレガシーコンタクトセンターのプラットフォームへの、問い合わせの転送を必要としない場合には、業務部門移行のためのアプローチを検討することもできます。例えば、移行する最初の業務部門として、社内サポート用のサービスデスクを選択します。サービスデスクの IVR とエージェント母集団を Connect Customer に移行したら、テストとビジネス検証の完了後にエンドポイントを移植して、既存の問い合わせを Connect Customer に転送できます。

サイトまたはエージェントグループのセグメンテーション

コンタクトセンターが国際的なフットプリントを持っていて、複数の国からの問い合わせに対応している場合、または、個別の地域または場所において独立して管理されている場合は、物理的なサイトまたはエージェントの所在地に基づき移行アプローチを検討します。エージェントのグループおよび (もしくは) 地域ごとに、グローバルには適用されない独自の要件や考慮事項を設定できます。この方法で移行にアプローチすることで、各サイトまたはエージェントグループは、独立して運用を継続するために必要なスキルを、次の段階に進む前に習得できるようになります。

仮想デスクトップインフラストラクチャ (VDI)

仮想デスクトップインフラストラクチャ (VDI) 環境内で Connect Customer Contact Control Panel (CCP) を使用できますが、ソリューションに別の複雑さが加わり、最適化のための個別の POC 作業とパフォーマンステストが必要になります。設定/サポート/最適化は、VDI サポートチームによって最も適切に処理されます。以下が、その際に最も一般的に使用されるデプロイモデルです。

ローカルブラウザにアクセスする VDI クライアント

Connect Customer Streams API を使用してカスタム CCP を構築するには、コールシグナリング用のメディアなしで CCP を作成します。このように、メディアは標準の CCP を使用してローカルデスクトップ上で処理され、シグナリングおよびコール制御はメディアなしで CCP とのリモート接続で処理されます。次の図に、このアプローチを示します。

Connect Customer での Citrix VDI のオーディオ最適化

Citrix Virtual Desktop Infrastructure (VDI) 環境を使用する場合は、Connect Customer RTC JavaScript ライブラリを使用してカスタム CCP を構築できます。このライブラリは Citrix United Communications SDK (ucsdk) と統合され、ローカルデスクトップから Connect Customer にメディアを自動的にリダイレクトします。これにより、エージェントは Citrix Workspaces などの Citrix VDI クライアントアプリケーションを使用して、カスタムエージェントアプリケーションやカスタム CCP に接続できます。これにより、Citrix 環境のオーディオメディアのリダイレクトのために、デュアル CCP などのエージェントアプリケーションを別個に開発して管理する必要がなくなります。次の図に、このアプローチを示します。

Connect Customer オーディオ最適化を使用した Amazon WorkSpaces VDI

仮想デスクトップインフラストラクチャ (VDI) 環境である Amazon WorkSpaces を使用すると、Connect Customer Real-Time Communications (RTC) JavaScript ライブラリを使用して、カスタマイズされた問い合わせコントロールパネル (CCP) を作成できます。このライブラリは Amazon WorkSpaces SDK とシームレスに統合され、ローカルデスクトップから Connect Customer への自動メディアリダイレクトを可能にします。これにより、特に WorkSpaces 環境内のオーディオメディアリダイレクトのために、デュアル CCP などの個別のエージェントアプリケーションを開発および管理する必要がなくなります。次の図は、このアプローチを示したものです。

Connect Customer オーディオ最適化を使用した Omnissa VDI

オムニッサ仮想デスクトップインフラストラクチャ (VDI) ソリューションを使用すると、カスタム問い合わせコントロールパネル (CCP) の実装を通じて、Connect Customer との効率的な統合が可能になります。

Connect Customer RTC JavaScript ライブラリを Omnissa の Horizon WebRTC SDK と組み合わせて使用することで、メディアストリームをエージェントのローカルエンドポイントから Connect Customer に直接リダイレクトすることで、オーディオ処理を最適化できます。このアーキテクチャにより、仮想デスクトップを介したオーディオルーティングの従来の課題が解消され、エージェントは Omnissa VDI 環境を使用しながら優れた音声エクスペリエンスを得ることができます。このソリューションにより、個別のオーディオリダイレクトアプリケーションの管理の複雑さが解消され、エージェントとのやり取りのための単一の統合インターフェイスが提供されます。次の図は、このアーキテクチャのアプローチを示したものです。

ローカルブラウザアクセスなしの VDI クライアント

VDI クライアントに、ローカルブラウザへのアクセス許可がない場合があります。このようなシナリオでは、VDI サーバから実行できるメディアを含む単一の CCP インスタンスを作成し、エンタープライズリソースへのアクセスを許可できます。このデプロイモデルでは、通常、UDP オーディオは VDI OS 上で有効化されます。このデプロイモデルでは、エクスペリエンスの質を最適化するために、さまざまな VDI サーバパラメータを調整するための広範なテストが必要です。