翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
パフォーマンス効率
パフォーマンス効率とは、コンピューティングリソースを効率的に使用してシステム要件を満たし、需要の変化や技術の進歩に合わせてこの効率性を維持する能力などのことを言います。このセクションでは、Amazon Connect ワークロードのパフォーマンス効率に関する設計原則、ベストプラクティス、および、よくある質問などを概説します。実装に関する規範的なガイダンスは、ホワイトペーパー、パフォーマンス効率の柱
アーキテクチャの設計
コンタクトセンターが提供するエクスペリエンスを設計する際には、次の 2 つの基本的なアーキテクチャ設計原則を考慮する必要があります。
-
還元主義とは哲学的理念の 1 つで、システムを究極的なコンポーネントの部分で分析することによって、より深いレベルでそれを解明しようとするものです。
-
対照的に、全体論では、全体像を 1 つとして捉えることによって、各コンポーネントを分析するよりも、状況をより深く完全に把握することを目指します。
還元主義のアプローチでは、個々のコンポーネント (IVR、ACD、音声認識) に個別に焦点を当てており、多くの場合、カスタマーエクスペリエンスは分割して捉えられ、その評価によりユースケースのパフォーマンス要件を満たしています。ただし、エンド・ツー・エンドで見た場合には、開発作業が担当ごとにサイロ化されているため、問い合わせのエクスペリエンスの品質低下をまねく可能性があります。このアプローチは、回帰テストを複雑にし、市場投入までの時間を長くし、さらにコンタクトセンターの成功に不可欠な分野横断的な運用リソースの開発を制限します。
次に、コンタクトセンターを全体論的に見た場合の図を示します。
全体論的なアプローチでは、顧客にとってより完全でまとまりのあるエクスペリエンスを創り出すことに焦点を当てており、あるエクスペリエンスの一部が、どのテクノロジにより提供されたのかは、さほど重要ではありません。
顧客と彼らが望むものをベースに、取るべき努力を定義し進むべき方向を把握します。問い合わせに提供するために作成するエクスペリエンスは、静的であったり完了形のものではなく、顧客からのフィードバックに基づいて行う継続的なま反復処理の、その出発点として機能するものです。この反復処理を促進するには、顧客が問い合わせの過程で行ったやり取りや、その中での移動に関する運用データ、およびその際に調整したデータなどを、定期的に収集しレビューします。目標とするべきなのは、自社が顧客から受ける問い合わせに提供するための、ダイナミックでパーソナライズされたエクスペリエンスでなければなりません。これは、問い合わせ対応のための動的でデータ駆動型の設計とルーティングによって実現できます。それにより、問い合わせ案件とその個々のニーズに合ったエクスペリエンスを実現します。
フローの構築は、デフォルトのエクスペリエンスを使用して開始できます。その後、1 つのフローを 2 つにリファクタリングすることで、将来のセグメント化を可能にします。
次の段階では、ルーティングを計画して構築する必要がある他のエクスペリエンスを割り出し、必要に応じてそれぞれのフローを特定します。例えば、支払い期限後の問い合わせや、同じ目的で複数回連絡を試みている問い合わせに対して、異なるプロンプトを再生できます。このアプローチでは、問い合わせやその理由に関連した、パーソナライズされ動的なエクスペリエンスを目指します。問い合わせのエクスペリエンスの質を向上させ、処理時間を短縮することに加えて、よりインテリジェントで柔軟なエクスペリエンスを提供することで、顧客によるセルフサービスでの解決を促します。次の段階は、下の図のようになります。
フロー設計
フローにより、最初から最後までのコンタクトセンターでのカスタマーエクスペリエンスが定義されます。フローの構成は、パフォーマンス、運用効率、およびメンテナンスの容易さに直接影響を与える可能性があります。
多くの大企業では、複数の電話番号、ビジネスユニット、プロンプト、キュー、その他の Amazon Connect リソースをサポートしています。電話番号と業務部門ごとに固有のフローを設定することができますが、これにより、電話番号とフローが、1 対 1 でマッピングされることになります。このことは、不要なサービスクォータ要求や、サポートおよび保守のための多数のフローを発生させます。次の図に、DNIS とフロー実装の間の、1 対 1 のマッピングを示します。
別の方法として、Amazon Connect フローが持つ動的な性質を利用して、1 つまたは少数の問い合わせフローを複数の DNIS で対応するアプローチを検討することもできます。この方法では、プロンプト、キュー、営業時間、ウィスパープロンプト/フロー、キューの扱い、保留メッセージなどの設定情報を、非 SQL のデータベースである DynamoDB に格納します。Amazon Connect では、複数の電話番号を同じフローに関連付けたり、Lambda 関数を使用してその電話番号の設定を検索したりできます。これにより、DynamoDB から返される属性に基づいて、問い合わせのエクスペリエンスを動的に定義できます。
例えば、プロンプトを再生したり、テキスト読み上げ (TTS) を使用しながら、DynamoDB での検索結果に基づいた挨拶を顧客に送ったりできます。また、フローブロックでサポートされている動的属性を使用してキューを関連付けることも可能です。このアプローチでは、構築、保守、およびサポートを効率的に行えるフローが実装されます。
負荷テスト
負荷テストまたはスケールテストを実行する必要がある場合は、サードパーティーまたはパートナーのソリューションを使用してそのテストを実行します。あるいは、Amazon Connect のStartOutboundVoiceContact API を使用する独自のカスタムソリューションを開発すれば、ブラウザの自動化スクリプトと組み合わせた呼び出しを生成し、エージェントの動作をシミュレートできます。テストを実行する前に、Amazon Connect 負荷テストポリシー
エージェントの有効化
Amazon Connect では、エージェントが顧客の問い合わせとやり取りするために構成された、ブラウザベースの問い合わせコントロールパネル (CCP) が提供されています。エージェントは、CCP を使用して、問い合わせの受け付けやチャットによる対応を行います。また、問い合わせを他のエージェントに転送したり、それらを保留にしたり、他の主要なタスクを実行したりします。Amazon Connect Streams
-
CRM 統合 – Streams APIを使用すると、CRM アプリケーションに CCP を埋め込むことができます。独自のインターフェースを作成したり、他の AWS サービスやパートナーソリューションを使用して、問い合わせの対応に必要なツールやリソースをエージェントに提供します。Amazon Connect や Salesforce との統合などのカスタムデスクトップを使用すると、エージェントは、複数の画面やインターフェイスを管理することなく単一のインターフェイスで、顧客と問い合わせに関する包括的なビューを取得できます。
-
認証 – Amazon Connect で ID 管理用の SAML を設定し、IAM Identity Center (SSO) を使用することで、エージェントは他のシステムにアクセスする際に使用するものと同じ認証情報を使用できるようになり、複数回入力する必要もなくなります。
-
エージェントの自動化 – エージェントの操作性の合理化に加えて、一般的で繰り返し行われるタスクを自動化できます。例えば、ケースを自動的に作成したり、ウェブフォームに事前入力したり、問い合わせ中の顧客に提案がある場合に、関連情報を含むポップアップを画面に表示したりできます。これにより、処理時間が短縮され、エージェントと問い合わせに対するエクスペリエンスの質が向上します。
-
拡張機能 – CCP 機能を強化/拡張して、文字起こし、翻訳、推奨アクション、ナレッジベースの統合
を、リアルタイムに行うこともできます。強化された機能をエージェントデスクトップと統合することで、熟練したエージェントは、問い合わせに対しより効率的なサービスを提供できるようになります。また、これらのエージェントが対応できない場合には、熟練していないエージェントも対応することが可能になります。このアプローチを使用する例としては、問い合わせのチャットで使用されている言語の知識がない、熟練していないエージェントのための自動翻訳などが挙げられます。エージェントからの応答テキストは、問い合わせの言語に自動的に翻訳されるため、二カ国語でのリアルタイムのコミュニケーションが可能になります。
他の AWS サービスの使用
このセクションでは、AWS サービスを使用してのパフォーマンスの向上、商談領域の特定、問い合わせのデータに関する有用なインサイトの取得について説明します。
AWS Lambda
Amazon Connect フローで AWS Lambda を使用すると、顧客情報のデータをディップしたり、SMS テキストメッセージを送信したり、Amazon S3 などの他のサービスを使用してスケジュールされたレポートを自動的に配信したりできます。詳細については、「AWS Lambda 関数を使用するためのベストプラクティス」を参照してください。
AWS Direct Connect
AWS Direct Connectは、ユーザーのプレミスから AWS への専用ネットワーク接続を、より効率的に確立できるようにするクラウドサービスです。このサービスにより、ISP に依存してリクエストを AWS リソースに動的にルーティングするのではない、耐久性と一貫性のある接続が提供されます。これにより、パブリック WAN 経由ではなく専用ファイバを経由して AWS トラフィックをリダイレクトするようにエッジルータを設定することができます。AWS とお客様のデータセンター、オフィス、またはコロケーション環境の間に、プライベート接続を確立します。多くの場合、これによりネットワークコストが削減され帯域幅のスループットが向上します。また、インターネットベースによる接続の場合よりも一貫性の高い、ネットワークエクスペリエンスを実現できます。
AWS Direct Connect では、プライベート LAN/WAN からエッジルーターへのトラバーサルに存在する、固有の問題は解決されませんが、エッジルーターと AWS リソース間に存在する、レイテンシーと接続に関する問題を解決する際の役に立ちます。また、エッジルーターと AWS リソース間のレイテンシーや通話品質の問題を解決するのにも役立ちます。
ご利用の VDI 環境によっては、AWS トラフィックがパブリック WAN ではなく専用ファイバー間でトラバースされるよう、エッジルータでリダイレクトを設定する必要があるため、AWS Direct Connect を活用できない可能性があります。VDI 環境が、ローカルの DXC 対応ネットワークの外部でホストされている場合、AWS Direct Connect が完全に活用できないこともあります。
AWS Direct Connect を、「QoS」 または 「increased security」には使用しないでください。AWS Direct Connect は、エージェントワークステーションからのレイテンシーが、ISP の Amazon Connect インスタンスへのパスよりも高い場合には、パフォーマンス低下の原因になる可能性があります。Amazon Connect の音声およびデータがすでに暗号化されているため、(ISP と比較して) AWS Direct Connect では追加的なセキュリティは提供されていません。
Amazon Polly
Amazon Connect は Amazon Polly とネイティブに統合されており、音声合成マークアップ言語 (SSML) を使用した、ダイナミックで自然なテキスト読み上げ (TTS) を提供します。これによりニューラルテキスト読み上げ (NTTS) を活用しながら、可能な限り最も自然で人間のようなテキスト読み上げ音声を実現しています。
Amazon Lex
問い合わせに対応する過程は、必ずしも顧客の期待に応えているとは言えないエクスペリエンスになることもあります。顧客を保留状態で待たせたり、同じ情報を繰り返し話させたり、転送が必要となることがあります。そして最終的には、必要なものを得るのに多くの時間を費やさせることになります。AI のチャットボットによる、インテリジェントで自然な言語の仮想アシスタントは、コールセンターでのカスタマーエクスペリエンスを向上させ、エンゲージメントを実現するための役割を果たします。これらのチャットボットは、特定のフレーズで話すことを通話者に要求せず、人間の音声を認識し、相手の意図を理解することができます。顧客は、エージェントと会話することなく、パスワードの変更、アカウントの残高の照会、アポイントのスケジュールなどの作業を実行できます。
Amazon Lex は、インテリジェントな会話チャットボットを作成できるサービスです。これにより、Amazon Connect コンタクトセンターのフローに自然な会話を導入し、問い合わせ中の顧客には、パーソナライズされたエクスペリエンスを提供します。Amazon Alexa の機能と同じ技術を使用している Amazon Lex チャットボットを、Amazon Connect フローにアタッチして、通話相手の意図を認識し、フォローアップの質問やその回答を行わせることが可能です。Amazon Lex は文脈を維持し、対話を管理し、会話に基づいて応答を動的に調整します。コンタクトセンターは複数の顧客に対し共通のタスクを実行できるようになるので、セルフサービスを利用した対応を通じて多くの問い合わせに対応できます。さらに、Amazon Lex チャットボットは、電話音声に最適なサンプリングレート(8 kHz) をサポートしているので、コンタクトセンターの音声対応における、音声認識の精度と忠実度を向上させます。
効果的な Amazon Lex ボットの構築には、シンプルでリアルな発話を、トレーニングセットとしてボットに提供する必要があります。ボットのパフォーマンスは定期的に見直して、発話セットの更新を行い、このレビューに基づいてボットを修正します。詳細については、以下のリソースを参照してください。
Amazon Kinesis
問い合わせに関するメトリクスや Amazon Connect のリアルタイムデータから、さらに詳しい情報を得る必要がある場合は、以下の操作を行います。
-
Amazon Kinesis を使用して Amazon Redshift に問い合わせレコードのデータをエクスポートします。
-
Amazon Kinesis Video Stream (KVS) と AWS Lambda を使用して、通話録音やリアルタイムの音声での問い合わせを Amazon Transcribe で転写し、その結果のテキストを Amazon Comprehend に送信して感情分析を行います。
-
Amazon Connect Agent Event Kinesis Stream を、リアルタイムエージェント CTI とスケジュール遵守データのために活用します。
Amazon OpenSearch Service と Kibana
Amazon OpenSearch Service と Kibana を使用して Amazon Connect のリアルタイムデータを処理することで、Amazon Connect のリアルタイムデータと履歴データにクエリを実行したり、それらのデータを可視化するための、ネイティブのレポート機能にはない柔軟な方法が提供されます。
Amazon Connect Contact Lens
Contact Lens for Amazon Connect は、Amazon Connect に統合された機械学習 (ML) 機能のセットです。これにより、コンタクトセンターのスーパーバイザは、顧客との対話内での感情、傾向、コンプライアンスリスクをより深く理解し、エージェントに効果的なトレーニングを行えます。成功した対応手法を複製し、また会社および製品にとって重要なフィードバックを特定します。Contact Lens for Amazon Connect は、コンタクトセンターでの着信を転写して、完全に検索可能なアーカイブを作成し、顧客についての有用なインサイトを明らかにします。
リソース
ドキュメント
ホワイトペーパー
動画
