オペレーショナルエクセレンス - Amazon Connect
準備 運用リソース

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

オペレーショナルエクセレンス

オペレーショナルエクセレンスとは、ビジネス価値をもたらし、サポートプロセスと手順の継続的な向上を実現するために、システムを実行およびモニタリングする能力などのことです。このセクションは、設計原則やベストプラクティス、および Amazon Connect ワークロードのオペレーショナルエクセレンスに関する質問で構成されています。

準備

Amazon Connect のワークロードを準備する際には、次の側面を検討してください。

AWS アカウント

AWS Organizations を使用すると、開発、ステージング、品質保証環境の各レベルに複数の AWS アカウントを設定できます。これにより、業務の成長に合わせて環境を一元的に管理し、 AWSでのワークロードをスケーリングすることができます。Organizations は、成長するスタートアップ企業でも大企業でも、請求の一元管理、アクセス、コンプライアンス、セキュリティの制御、 AWS アカウント間でのリソースの共有に役立ちます。これは、クラウド導入フレームワークとともに AWS サービスを消費するための出発点です。

リージョンの選択

Amazon Connect リージョンの選択は、データガバナンスの要件、ユースケース、各リージョンで利用可能なサービス、各リージョンでのテレフォニーコスト、エージェントに関連するレイテンシー、問い合わせの相手、外部転送エンドポイントがある地域によって影響を受けます。

テレフォニー

  • 電話番号の移植 可能な限り、保留中の稼働開始日の前に移植リクエストをオープンします。

    重要なワークロード用の電話番号を移植する場合は、稼働日の数か月前に、取得もしくは移植しようとしている番号に関する、すべての要件とユースケース情報を含めながらリクエストを行います。これには、ライブカットオーバーでのサポート、カットオーバー前や、その最中、および以後のコミュニケーション、モニタリング、およびユースケースに固有の対応に関するリクエストが含まれます。

    電話番号の移植の詳細については、「現在の電話番号を Amazon Connect に移植する」を参照してください。

  • キャリアダイバーシティ 米国では、Amazon Connect テレフォニーサービスを、米国の通話料無料番号で使用する必要があります。これにより、複数のサプライヤー間で通話料無料トラフィックをアクティブ-アクティブ構成によりルーティングでき、追加料金は発生しません。インバウンドトラフィックを Amazon Connect の電話番号に転送する場合は、複数のテレフォニープロバイダー間で冗長番号DIDまたは通話料無料番号をリクエストする必要があります。米国以外で複数の番号または通話料無料番号を申請DIDまたは移植する場合は、障害耐性を高めるために、それらの番号をさまざまなテレフォニープロバイダーに申請または移植するようにリクエストする必要があります。

  • 国際通話料無料および高同時実行 DIDs 既存の通話料無料国内サービスを使用してインバウンドトラフィックを にリダイレクトする場合はDIDs、複数のテレフォニープロバイダー間でDID電話番号をリクエストする必要があります。この設定の一般的な推奨事項は 1 人DIDあたり 100 セッションで、 AWS ソリューションアーキテクトは容量の計算とセットアップに役立ちます。

  • テスト 可能な限り、エージェントや顧客と同じか類似の環境を使用しながら、すべてのユースケースのシナリオを徹底的にテストします。エクスペリエンスの品質や、発信者 ID の機能について、インバウンドとアウトバウンドでの複数のシナリオをテストし、レイテンシーを測定して、それがユースケースでの許容範囲内に収まることを確認します。ターゲットエージェントおよび顧客が使用する環境からの逸脱については、測定と検討を行う必要があります。ユースケーステストの手順と、その基準の詳細については、「問い合わせコントロールパネルを使用する際の問題のトラブルシューティング (CCP）」を参照してください。

エージェントワークステーション

Amazon Connect コールコントロールパネル (CCP) には、エージェントと問い合わせに対して最高のサービス品質を確保するために満たす必要がある特定のネットワークおよびハードウェア要件があります。

  • CCP 使用するネットワークを設定し、エージェントのハードウェアが最小要件を満たしていることを確認します。

  • エージェントと同じネットワークセグメントで Amazon Connect Check Amazon Connectivity Tool を使用して、ネットワークと環境がCCP使用できるように正しく設定されていることを確認します。

  • エージェントと問い合わせを地理的に離れた場所に配置する必要があるユースケースのPSTNレイテンシーを計算する

  • 問い合わせコントロールパネルを使用する際の問題のトラブルシューティング (CCP）セクションを確認しながら、エージェントとスーパーバイザが問題発生時にフォローするための、ランブックおよびプレイブックを作成します。

  • エージェントワークステーションに対するモニタリングをセットアップし、通話品質のモニタリングに使用できるパートナーソリューションを検討します。エージェントワークステーションのモニタリングは、潜在的なネットワークとリソースの競合の原因を特定することが目的です。例えば、一般的なエージェントのソフトフォンにおける、Amazon Connect へのネットワーク接続パスを考えてみましょう。

    エージェントワークステーションの監視。

    ローカル LAN/WAN、 へのパス AWS、およびエージェントワークステーションレベルでモニタリングを設定しないと、音声品質の問題がエージェントのワークステーション、プライベート LAN/、、または問い合わせ自体に起因するかどうかを判断することは難しくWANISP AWS、多くの場合不可能です。積極的なログ記録や警報のメカニズムをセットアップすることは、根本原因を特定し、音声品質のために環境を最適化する上で重要です。

既存のディレクトリを設定する

既に ディレクトリを使用してユーザー AWS Directory Service を管理している場合は、同じディレクトリを使用して Amazon Connect のユーザーアカウントを管理できます。この機能は、Amazon Connect インスタンスの作成時に使用するかどうかを判断し、設定する必要があります。選択した ID オプションをインスタンスの作成後に変更することはできません。例えば、選択したディレクトリを変更してインスタンスの Single Sign On (SSO) を有効にする場合は、インスタンスを削除して新しいインスタンスを作成できます。インスタンスを削除すると、関係するすべての設定とメトリクスデータが失われます。

Service Quotas

ワークロードに関係する各サービスのデフォルトのサービスクォータと、Amazon Connect のデフォルトのサービスクォータを確認し、必要に応じて引き上げをリクエストします。Amazon Connect に対し引き上げをリクエストする際には、変動を防止するため、予定の値をそのまま追加なしで使用してください。変動は、リクエスト時に自動的に考慮されます。

AWS エンタープライズサポート

AWS エンタープライズサポートは、 のビジネスやミッションクリティカルなワークロードに推奨されます AWS。Enterprise Support および Well-Architected レビューは、 AWS ソリューションアーキテクトとともに、Amazon Connect サービスレベルアグリーメントの認定を受ける必要があります。

AWS 適切に設計されたレビュー

Amazon Connect への移行または実装の前に、 AWS Well-Architected フレームワークであるオペレーショナルエクセレンスを使用してベストプラクティスに従ってください。このフレームワークでは、5 本の柱 (オペレーショナルエクセレンス、セキュリティ、信頼性、パフォーマンス効率、コスト最適化) に基づいて、時間経過とともに拡張するアーキテクチャと実装設計を評価するための、一貫性のあるアプローチを提供します。また、 のビジネスおよびミッションクリティカルなワークロードには、 AWS エンタープライズサポートを使用することをお勧めします AWS。Amazon Connect サービスレベルアグリーメントの認定を受けるには、エンタープライズサポートと AWS ソリューションアーキテクトによる Well-Architected Review の両方が必要です。

運用

Amazon Connect ワークロードのオペレーションについては、次の側面を考慮してください。

ログ記録とモニタリング

「を使用したインスタンスのモニタリング CloudWatch」および「を使用した Amazon Connect API呼び出しのログ記録 AWS CloudTrail」を参照してください。

問い合わせ属性

Amazon Connect では、フロー内の問い合わせ属性を動的に設定および参照して、問い合わせの動的でパーソナライズされたエクスペリエンスの作成、強力なセルフサービスアプリケーションの作成、データ駆動型 IVRs、他の AWS サービスとの統合、電話番号管理の簡素化、カスタムのリアルタイムおよび履歴レポートと分析が可能になります。以下は、複雑さを軽減し、データ損失を防止しながら、問い合わせのエクスペリエンスに一貫性のあるクオリティを与えるための、ベストプラクティスと考慮事項です。

以下の考慮事項に注意してください。

  • データサイズ – 切り捨てを防ぐため、問い合わせ属性の設定ブロックで設定できる属性には、使用する文字セット、エンコード、言語によって決まるサイズ制限があります。通常これは、問い合わせの短い会話を再生するのに十分なデータですが、この制限を超えた場合は、32 KB より大きな属性セットは切り捨てられます。

  • データの機密性 – 設定、照会、および参照される属性に機密性があるか、何らかの規制ガイドラインに該当している場合は、そのデータがユースケースに合わせて適切に処理されていることを確認します。

  • データ永続性 – 問い合わせ属性の設定 ブロックを使用して設定された属性は、問い合わせの問い合わせレコードに含まれ、ストリーム を使用してカスタムエージェントデスクトップにスクリーンポップできますAPI。属性がフロー内で参照され、フローのログ記録が有効になっているたびに、属性の名前と値が Amazon にログ記録されます CloudWatch。

ベストプラクティス

  • 使用状況のモニタリング – 新しい機能を実装し、新しい部署へのオンボーディングを行い、既存のフローを反復処理する際には、問い合わせの検索で現在の属性の使用状況を検索します。また、32 KB のサイズ制限を超えないようにするには、属性をテキストエディタにコピーした上で新しい属性を追加します。firstName lastName や などの可変長フィールドを考慮し、フィールドで最大スペースが使用されている場合でも、32KB の制限を下回っていることを確認してください。

  • クリーンアップ – データ永続性が必要ない場合は、同じ名前と空白の値を持つ属性を設定して、データが問い合わせレコードに保存されたり、Amazon Connect Streams を使用して画面ポップでエージェントに渡されたりしないようにAPIできます。同時に、問い合わせレコードでデータによって使用されたバイト数を解放します。

  • 機密データ – 顧客入力ブロックを保存を使用して連絡先から機密DTMF入力を収集し、エンベロープ暗号化を使用して raw データと暗号化に使用されるデータキーの両方を保護します。永続性が必須の別のデータベースに機密データを格納し、[Set logging behavior] (ログ記録動作の設定) のフローブロックを使用して、機密情報が参照されるたびにログを無効にします。また、[Set contact attributes] (問い合わせ属性の設定) ブロックで事前に定義したクリーンアップメソッドを使用して、機密データを削除、クリーンアップ、または不明瞭化します。詳細については、「Amazon Connect でのコンプライアンスの検証」を参照してください。

テレフォニー

米国では、可能な限り、無料電話番号を使用して複数の通信事業者間で負荷を分散し、接続経路を増やしながら通信事業者の冗長性を高めます。これは、単一の通信事業者が管理する必要があるDID電話番号と比較して、解決までの時間を短縮するのにも役立ちます。を使用する状況ではDIDs、信頼性を高めるために、可能であれば複数の通信事業者の番号間で負荷分散を行います。すべてのエラーパスが、フローにより適切に処理されていることを確認し、問い合わせコントロールパネルを使用する際の問題のトラブルシューティング (CCP） にあるベストプラクティス、要件、および推奨事項を実装します。

既存のテレフォニープロバイダーの電話番号を Amazon Connect に転送する場合は、転送先を別の DID/通話料無料番号に変更するか、転送を削除するプロセスが、運用チームによって定義され、十分に理解されていることを確認してください。実稼働に向けた準備の評価、電話番号の移植と転送のプロセス、および、既存のテレフォニープロバイダーから通話を転送する際に発生する可能性のある、音声の問題に関するトラブルシューティングのために、ランブックやプレイブックを用意しておく必要があります。また、これらの音声に関する問題の原因が Amazon Connect にあるのか、既存のテレフォニープロバイダーにあるのかを判断するために、オペレーションチームが繰り返し使用できるプロセスも必要です。

Amazon Connect APIs

Amazon Connect でのスロットリングのクォータは、インスタンスではなく、アカウントごとに設定されます。Amazon Connect を使用するときは、次のベストプラクティスを考慮する必要がありますAPIs。

キャッシュ/キューイング用ソリューションの実装

API データクエリのオーバーヘッドを減らし、スロットリングを回避するには、Amazon DynamoDB などの中間データベースを使用して、APIデータに関心のあるすべてのエンドポイントAPIから を呼び出すのではなく、API呼び出し結果を保存できます。例えば、次の図は、この情報を使用する必要がある複数のソースAPIからの Amazon Connect メトリクスの使用を示しています。

キャッシュ/キューイングソリューションの実装。

それぞれに独自のポーリング要件がある個別の AWS Lambda 関数を持つのではなく、1 つの AWS Lambda 関数ですべての興味深いデータを Amazon DynamoDB に書き込むことができます。次の図に示すように、各エンドポイントはデータを取得するために APIに直接移動するのではなく、DynamoDB を指します。

DynamoDB をポイントします。

このアーキテクチャでは、サービスクォータの超過を心配することなく、必要に応じてポーリング間隔を変更し、エンドポイントを追加できるため、データベースソリューションがサポートしている同時接続の数に合わせた拡張が可能です。Amazon Connect からのリアルタイムデータフィードに対するクエリにも、この同じ概念を使用できます。アウトバウンドAPIコールなどのAPIアクションを実行する必要がある場合は、Amazon Simple Queue Service と組み合わせてこの同じ概念を使用して、 AWS Lambda で を使用するAPIリクエストをキューに入れることができますSQS。

急増するバックオフと再試行の戦略

API スロットリング制限を超える状況が発生することがあります。これは、API呼び出しが失敗し、繰り返し再試行された場合や、キャッシュまたはキューイングソリューションを実装せずに複数の同時エンドポイントから直接行われた場合に発生する可能性があります。サービスクォータを超え、ダウンストリームプロセスに影響を与えることを避けるため、キャッシュとキューイングと組み合わせて AWS Lambda 関数内でエクスポネンシャルバックオフおよび再試行戦略を使用することを検討する必要があります。

変更管理

ワークロードを Amazon Connect に移植する主要な理由となるのは、柔軟性と市場投入のスピードの 2 点です。俊敏性を犠牲にすることなくオペレーショナルエクセレンスを達成するには、以下のベストプラクティスに従います。

  • モジュラー型のフロー: Amazon Connect フローは、モダンアプリケーションの構築に似ています。ここでは、モノリシックソリューションと比較して優れた柔軟性と制御性、そして管理の容易さを、小型の専用コンポーネントにより実現しています。フローを小さくして再利用できるようにし、モジュラーフローを フローブロックへの転送で end-to-end エクスペリエンスに組み合わせることができます。このアプローチにより、変更の実装にともなうリスクを軽減し、エクスペリエンス全体を回帰的にテストするのではなく単一の小さな変更をテストできます。また、フローに対するテスト中の問題の特定と対処が容易になります。

  • リポジトリ: 変更管理プロセスの中で、問い合わせフローの Import/Export を使用しながら、すべてのフローのすべてのバージョンを任意のリポジトリにバックアップします。

  • [Distribute by percentage] (分散の割合 (%)): 変更管理中に発生するリスクを軽減しながら、問い合わせのための新しいエクスペリエンスを試すには、[Distribute by percentage] (分散の割合 (%)) ブロックを使用します。トラフィックのサブセットを新しいフローにルーティングしながら、他のトラフィックは元のエクスペリエンスに残します。

  • 測定結果: データ駆動型の意思決定は、ビジネスにおいて有意義な変化を成功に導くための鍵となります。変更を測定するための主要なメトリクスは、ぜひ用意しておくべきです。すべての変更について、その成功度合を測る方法を計画しておきます。例えば、問い合わせに対応するセルフサービス機能を実装している場合には、ワークロードを成功させるために、問い合わせをどの程度の割合でセルフサービスする必要があるかや、成功を判断するために測定するその他のメトリクスは何かについて検討します。

  • ロールバック: 実行された変更を、以前の特定の状態に戻すための、明確で適切に定義され、よく理解されたプロセスを用意する必要があります。例えば、フローの新しいバージョンを公開する場合は、変更手順の中に、以前のフローのバージョンへのロールバック方法に関するドキュメントを含めるようにします。

ルーティングプロファイル

Amazon Connect 内での優先度、遅延、オーバーフロールーティングの仕組みを理解することは、エージェントの生産性の最大化や、問い合わせの待ち時間の短縮、そして最高品質のエクスペリエンスを提供するために不可欠です。

Amazon Connect でのルーティング

Amazon Connect における問い合わせのルーティングは、ルーティングプロファイルと呼ばれる、キューとルーティング設定のコレクションを介して実行されます。キューは、エージェントがそこでの問い合わせに対応するために必要とする、スキルまたは習熟度に相当します。ルーティングプロファイルは、その問い合わせのニーズを満たすためのスキルのセットと捉えることができます。

フロー内では、追加情報の入力を求めることができます。その通話をエージェントにつなげる必要がある場合は、フロー設定を使用することで適切なキューに配置できます。次の例では、貯蓄、小切手の使用、ローンは個別のキューまたはスキルであり、3 つのルーティングプロファイルは、一意のスキルセットまたはスキルグループとして示されています。

キューのグループによるルーティング。

各エージェントは、それぞれのスキルセットに基づいて 1 つのルーティングプロファイルにのみ割り当てられます。また、類似のスキルセットを持つ複数のエージェントが、同じルーティングプロファイルを共有できます。

スキルセットによるルーティング。

各電話番号またはチャットエンドポイントは、1 つのフローに関連付けられます。フローが、決められたロジックを実行します。そこでは、顧客に情報の入力を促し、その問い合わせのニーズを判断し、最終的に問い合わせは適切なキューにルーティングされます。次の図は、ルーティングプロファイル、キュー、およびフローが連携して、サービスを提供する仕組みを示しています。

ルーティング図。

さまざまなキュー、ルーティングプロファイル、およびルーティングプロファイルへのエージェントの割り当てを決定する方法については、次のテーブルを使用します。

キューのグループによるルーティング。

一番上の行で、スキルやキューを選択します。左の列にはエージェントのリストがあり、中央の列では、各エージェントがサポートするスキルをチェックします。エージェントのメンバー全体で、共通のスキル要件のセット別にグループ化されたマトリックスを並べ替えることができます。これにより、エージェントを割り当てることができる (2 つのキューから成る) 緑色のボックス内で、マークされたルーティングプロファイルを識別できます。この作業の結果、4 つのルーティングプロファイルを特定し、それぞれに応じて 13 人のエージェントが割り当てられます。

このテーブルに基づいて、問い合わせの (貯蓄に関するスキルを必要とする) 着信は、次の図に示すように、3 つのルーティングプロファイル 1、2、および 4 にある、3 つのエージェントグループによって処理されます。

キューのグループによるルーティング。

優先度と遅延

異なるルーティングプロファイルで優先度と遅延の組み合わせを使用して、柔軟なルーティング戦略を作成できます。

優先度と遅延。

前述のルーティングプロファイルの例では、一連のキューと、それらに対応した優先度と遅延を示しています。数値が小さいほど、優先度が高くなります。すべての優先度の高い通話は、優先順位の低い通話が処理される前に処理される必要があります。これが、重み係数に基づいて、最終的には低い優先度の着信も処理されるシステムとの違いです。

また、各ルーティングプロファイル内の各キューに遅延を設定することもできます。キューに入力される着信は、そのキューに割り当てられた一定の遅延期間だけ保管されます。対応可能なエージェントがいる場合でも、着信は遅延期間保留されます。これは、サービスレベルアグリーメント (SLAs) を満たすために予約されているが、他のタスクやキューに割り当てられるエージェントのグループがある場合に使用できます。着信に対する応答が指定された時間内に行われない場合、これらのエージェントは、指定されたキューから着信を受ける担当になります。例えば、次の図について考えます。

優先度と遅延。

この図は、30 秒SLAの を示しています。Savings キューに着信が届きます。Savings キューは、キューのプロファイルで遅延時間が 0 に設定されているため、ただちに「Savings」ルーティングプロファイルでエージェントを検索します。遅延を 15 に設定しているシニアエージェントには、15 秒の間は、Savings の問い合わせを受ける資格がありません。15 秒経過すると、この問い合わせに上級レベルのエージェントが割り当て可能になり、Amazon Connect は両方のルーティングプロファイルで、Longest Available となっているエージェントを探します。

サービスへのパス

Amazon Connect でカスタマーエクスペリエンスを設計する場合は、サービスへのパスの確立をめざしてください。Amazon Connect フローをたどってみると、カスタマーエクスペリエンスに影響を及ぼす可能性のある、予定された、あるいは予定外の多くのイベントの存在がわかります。次のカスタマーエクスペリエンスの例に、問い合わせに対し一貫した品質のエクスペリエンスを提供するために推奨された、いくつかのチェック項目を示しています。

サービスへのパス。

このカスタマーエクスペリエンス例では、祝日や営業時間などの予定されたイベントと、営業時間内に配置に就いていないエージェントの存在などの予定外のイベントを考慮に入れています。このロジックを使用すると、悪天候やサービスの中断によるコンタクトセンターの閉鎖など、緊急事態に対応することもできます。この図に従い、以下のような概念を考慮していきます。

  • セルフサービス : 一般的な ではIVR、通話録音のお知らせなど、挨拶や免責事項のメッセージを事前に含めることができます。その後にセルフサービスオプションが続きます。セルフサービスにより、コンタクトセンターのコストとパフォーマンスを最適化できます。組織は休日、営業時間、エージェントの対応体制にかかわらず、24 時間 365 日対応のサービスを顧客に提供できます。セルフサービスの提供ができず、人によるアシスタンスが必要な場合に備えて、常にサービスへのパスを用意しておきます。例えば、セルフサービスに Amazon Lex ボットを使用している場合であれば、フォールバックインテントを使用することで、人によるアシストに向け通話をエスカレートできます。

  • 祝日: 多くのエンタープライズのお客様は、中心的なリポジトリに、自社の休日を記録しています。 AWS Lambda 関数を使用して、そのリポジトリにデータをディップすれば、休日での取り扱いを顧客に知らせられます。さらに、各休日に向けたカスタムメッセージとともに DynamoDB に自社の休日を保存しておくこともできます。例えば、自社が 12 月 25 日をクリスマス休暇としている場合、祝日の表示またはテキスト読み上げに「現在、クリスマスのため休業中です。12 月 26 日に通常の営業時間が再開された後に、おかけ直しください。」と挿入できます。

    祝日。

  • 営業時間: 休日を確認した後、営業時間を確認したり、営業時間外の場合は、問い合わせ向けのエクスペリエンスを動的に変更したりできます。営業時間内に問い合わせがあった場合、その通話に関する顧客の意図を特定し、コンタクトセンターの特定のキューにマッピングします。これにより、適切なエージェントにつながる可能性を高め、その問い合わせにサービスが提供されるまでの時間を短縮できます。顧客の通話の理由がまだ把握できていない場合や、顧客が予想外の反応をする場合があり得るため、デフォルトのキューにマッピングすることを強くお勧めします。

  • 緊急メッセージ: 顧客からの問い合わせの意図を特定したら、緊急チェックでの対応を実施することをお勧めします。コンタクトセンターに影響を与える緊急事態が発生した場合、DynamoDB などの中間データベースに緊急の True/False フラグを保存できます。スーパーバイザーと管理者がコードなしでこのフラグを動的に設定できるようにするには、 ANIと内部使用のみのためのPIN番号検証に基づいて Amazon Connect 管理者を認証IVRする別の を構築できます。緊急の場合、スーパーバイザーは電話からその専用ラインを呼び出すことができます。認証後、コンタクトセンターの物理的な場所での天候やISP障害によるコンタクトセンターの閉鎖などのシナリオでは、緊急フラグを true に設定します。

  • 緊急メッセージ API: バックエンドに AWS Lambda 関数を使用してゲートウェイを構築し AWS API、データベース内で緊急フラグを true/false に安全に設定することを検討することもできます。スーパーバイザーは、ウェブAPI経由でこれに安全にアクセスして、ディザスタモードを切り替えたり、外部イベントに応じて動的に切り替えたりすることができます。Amazon Connect インスタンスでは、フローを通じて着信するすべての問い合わせが AWS Lambda を使用してその緊急フラグをチェックし、ディザスタモードの場合は、動的に通知を行い、お客様にサービスへのパスを提供できます。これにより、ビジネス継続性がさらに確保され、このような状況が顧客にもたらす影響を軽減することができます。

  • エージェントの配置の確認: 通話をフローのキューに転送する前に、エージェントの人員配置を確認して、エージェントがログイン済みで、問い合わせに対してサービスの提供が可能であることを確認できます。例えば、別の問い合わせに対応するためにエージェントがビジー状態になっており、その 5 分後に対応可能になりそうな場合や、システムにログインしているエージェントが 1 人もいない場合などが考えられます。このような状況では、エージェントが対応可能になるのを、顧客にキュー内で待たせるのではなく、別のカスタマーエクスペリエンスを提供するべきです。

  • サービスへのルーティング: 通話をキューに転送することで、Amazon Connect ルーティングプロファイルを使用しながら、キュー内にある折り返し通話や対応からあふれた通話、または階層型ルーティングを通じて、サービスレベル要件に適合した一貫性のある高品質のエクスペリエンスを顧客に対し提供できます。

リソース

ドキュメント

ブログ

動画