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

Amazon Connect では、さまざまな移行や統合オプションにより、セルフサービスによる設定が行えます。また、動的でパーソナルかつ自然なカスタマーエンゲージメントをあらゆる規模で実現できます。以下、このセクションでは、Amazon Connect のワークロードを設計する際に考慮すべきシナリオとデプロイアプローチについて説明します。

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

• インバウンド

• アウトバウンド

• ハイブリッドコンタクトセンター

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

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

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

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

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

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

インバウンド

インバウンドとは、コンタクトセンターが問い合わせを着信することで開始される、コミュニケーションに対する要求を表すためのコンタクトセンター用語です。各問い合わせは、Amazon Connect インスタンスに接続されます。ここで、音声やチャットなどさまざまな方法を通じて、インバウンド向けのセルフサービスや、人間のエージェントとの会話による対応が行われます。音声による問い合わせは、PSTN を経由し、Amazon Connect インスタンスが取得している電話番号を使用しながら、そのインスタンスのテレフォニーエントリポイントにルーティングされます。電話番号は、Amazon Connect から直接予約したり、既存の電話番号を移植したりできます。また、音声の問い合わせを Amazon Connect に転送することも可能です。Amazon Connect では、サービスがサポートされているすべてのリージョンで、ローカルの通話料無料番号を提供しています。

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

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

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

アウトバウンド

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

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

ハイブリッド

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

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

IVR のみ

Amazon Connect を使用することで、エージェントをレガシーコンタクトセンターのプラットフォーム上に留めたままで、問い合わせに対し IVR エクスペリエンスを展開することができます。このアプローチでは、Amazon Connect のフローを使用して、セルフサービスとルーティングのロジックを推進し、必要に応じて、レガシーコンタクトセンターのプラットフォーム上の対象エージェントまたはエージェントキューに対し、問い合わせ案件を転送します。

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

エージェントのみ

このアプローチでは、レガシーコンタクトセンター IVR が、問い合わせの自己解決を促しながら通話の転送ロジックとして機能します。必要な場合には、その問い合わせを Amazon Connect に転送し、エージェント部門に接続します。

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

混成

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

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

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

新しいワークロード

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

IVR ファースト

Amazon Connect を使用することで、エージェントをレガシーコンタクトセンターのプラットフォーム上に留めたままで、問い合わせに対し IVR エクスペリエンスを展開することができます。このアプローチでは、Amazon Connect フローを使用して、セルフサービスとルーティングのロジックを推進し、必要に応じて、レガシーコンタクトセンターのプラットフォーム上の対象エージェントまたはエージェントキューに対し、問い合わせ案件を転送します。

IVR ラスト

このアプローチでは、レガシーコンタクトセンター IVR が、問い合わせの自己解決を促しながら通話の転送ロジックとして機能します。必要な場合には、その問い合わせを Amazon Connect に転送し、エージェント部門に接続します。

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

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

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

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

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

仮想デスクトップインフラストラクチャ (VDI) 環境において、Amazon Connect の問い合わせコントロールパネル (CCP) を使用することも可能ですが、この場合は、異なる POC の作業とパフォーマンステストでの最適化を保証するための、別の複雑さがソリューションに加わります。設定/サポート/最適化は、VDI サポートチームによって最も適切に処理されます。以下が、その際に最も一般的に使用されるデプロイモデルです。

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

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

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

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

注記

このソリューションでは、VDI サーバーと Amazon Connect 間の WebRTC シグナリングトラフィック、またエージェントのデスクトップと Amazon Connect 間のメディア接続を許可する必要があります。詳細については、ネットワークをセットアップする ドキュメントを参照してください。

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

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