ユースケースの例 - AWS 規範ガイダンス
組織の目標を特定するカスタマーコンタクトジャーニーのマッピング基盤アーキテクチャの作成

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

ユースケースの例

次に、これらの原則を適用し、モジュール式の基盤アーキテクチャを導き出す方法を示すユースケースを見てみましょう。架空のグローバル企業である Example Corp は、この例の焦点です。

Example Corp は、データセンターのメンテナンスを削減し、イノベーションに集中し、コストを削減するために、クラウドベースのコンタクトセンターに移行したいと考えています。主な優先事項はセルフサービスであり、移行の一環としてカスタマーエクスペリエンスを向上させることを目的としています。Example Corp は、国 (米国、カナダ、イタリア、オランダなど) と事業部門 (販売、サポート、新製品など) に基づいて、複数の通話料無料番号 (TFNs) と直通ダイヤル番号 (DIDs) を管理するグローバル組織です。つまり、複数の言語 (米国英語、カナダフランス語、イタリア語など) をサポートする必要があります。また、Example Corp は、ダイヤルした番号または発信元国に基づいて、パーソナライズされたカスタマイズされたエクスペリエンスを発信者に提供したいと考えています。これにより、メニューオプションが変更されたり、IVR システムで異なるプロンプトメッセージが表示される可能性があります。さらに、各国には、通話ルーティングのためにエージェントに割り当てる必要がある専用のスキルのセット (言語、事業部門などに基づく) があります。合計で 25 の国と 12 の言語をサポートしています。また、支払い処理を提供し、エージェントと話さずに製品やアドオンを購入する機能を提供する予定です。ベストプラクティスとして、Example Corp はコンタクトセンターの開発、ステージング、本番環境を維持します。

このセクションでは、このガイドで前述した IVR 設計原則を Example Corp ユースケースに適用する方法を示します。 AWS サービスを使用して、組織の目標を特定し、カスタマーコンタクトジャーニーを構築し、会社の要件を満たすアーキテクチャフレームワークを作成するプロセスについて説明します。

組織の目標を特定する

Example Corp の主な組織目標は次のとおりです。

  • コスト削減： クラウドベースのコンタクトセンターに移行して、メンテナンスコストを削減し、イノベーションを強化します。

  • パーソナライズされたセルフサービス： 言語オプションなど、発信元番号または国に基づいて、パーソナライズされたエクスペリエンスをお客様に提供します。

  • IVR の封じ込め率の向上: IVR システム内の支払い処理を合理化し、顧客がエージェントの介入なしに製品やアドオンを購入できるようにします。

  • 変更管理/イノベーションセンターの改善： IVR システムの個別の環境 (開発、ステージング、本番稼働) を維持し、効果的な変更管理と実験を行います。

  • 最初の通話の解決を改善: 言語、国、顧客の意図に基づいて効果的なルーティング戦略を実装します。

カスタマーコンタクトジャーニーのマッピング

Example Corp のカスタマーコンタクトジャーニーを作成するには、次の点を考慮する必要があります。

  • 発信元： 着信通話に関連する国と事業部門を特定し、カスタマイズされたエクスペリエンスを提供します。

  • 言語の選択： 発信者の発信国、プロファイル、Example Corp でサポートされている言語に基づいて、適切な言語メニューを提供します。

  • 顧客認証： アカウントの詳細、音声生体認証、またはその他の安全な方法を使用して、発信者を認証します。

  • パーソナライズ: 顧客データを収集して使用し、発信者に名前で挨拶したり、アカウント履歴に基づいてカスタマイズされたメニューオプションを提供したりするなど、IVR エクスペリエンスをパーソナライズします。

  • セルフサービスオプション： 残高照会、注文ステータスの更新、パスワードのリセットなど、顧客の一般的な問い合わせに対応するためのセルフサービスオプションを提供します。

  • 支払い処理： 顧客が IVR システム内で購入できるように、安全な支払いゲートウェイを統合します。

  • バックエンド統合： バックエンド API 統合を検討して、パーソナライズされた挨拶、注文の更新、支払いなどのセルフサービスプロセスを実装します。これらの APIs の可用性と準備状況を確認します。

  • セキュリティとコンプライアンス： ログのさらなる暗号化、マスキング、無効化が必要な情報 (カード情報や顧客 PII など) を決定します。

  • 反復可能なプロセス： ほとんどの国や事業部門で繰り返される支払いや発信者認証などのプロセスを特定します。

基盤アーキテクチャの作成

Example Corp IVR システムのモジュール式で動的なアーキテクチャフレームワークを作成するには、静的コンテンツの排除と反復可能なプロセスのモジュール化を検討してください。

静的コンテンツの削除

  • 変数を使用して、各国に割り当てられた通話料無料番号 (TFNs) に基づいてプロンプトを動的に呼び出すことを検討してください。たとえば、TFN1 がカナダに属している場合、外部データベースから適切なプロンプトを呼び出して、言語オプションとして英語とカナダフランス語を顧客に提供できます。お客様の選択に基づいて、外部データベースから英語 (またはカナダフランス語) プロンプトを呼び出し、IVR コールフロー全体で再生できます。このアプローチでは、単一の IVR フローを使用し、すべての TFNs。

  • 呼び出し元をルーティングする必要があるエージェントキューとスキル、呼び出しが通過する必要がある次の IVR ツリー、URLs や Amazon リソースネーム (ARNs) などの API エンドポイントの値を外部データベースに保存することを検討してください。また、国または事業部門に割り当てられた TFN に基づいてこれらを呼び出すこともできます。

  • エクスペリエンスをさらに効率化するために、デプロイ環境の詳細を外部データベースに保存することもできます。たとえば、TFN2 が開発環境にマッピングされている場合、その環境にのみ関連する言語プロンプト、API エンドポイント、エージェントキュー、およびスキルを呼び出すことができます。TFN3 がステージング環境にマッピングされている場合は、ステージングに割り当てられた呼び出しの詳細を呼び出すことができます。このアプローチにより、コールフローのメンテナンスと開発が大幅に効率化されます。開発者は 1 つのコールフローを維持でき、国、事業部門、環境に割り当てられた TFN などの主要なパラメータに基づいてエクスペリエンスを簡単に変更できます。

繰り返し可能なプロセスの特定

Example Corp では、国や事業部門間で識別される反復可能なプロセスには、発信者の言語選択と支払い処理があります。これらのプロセスをモジュールとして構築することで、すべてのコールフローで簡単に一元化、保守、呼び出しを行うことができます。

次の図は、このガイドで説明されている IVR 設計方法に基づくアーキテクチャの例を示しています。このアーキテクチャではAmazon Connect フローとモジュールを以下の追加 AWS サービスと共に使用します。

  • Amazon DynamoDB テーブルARNs、動的属性、プロンプトが保存されます。

  • AWS Lambda 関数は、DynamoDB テーブルから情報を取得します。

  • Amazon Polly はテキストプロンプトを音声に変換します。

  • Amazon Simple Storage Service (Amazon S3) はAmazon Connect の問い合わせレコードを保存します。

AWS サービスを使用した IVR アーキテクチャの例

IVR システムは以下のステップを実装します。

  1. 顧客が会社の国固有の DID または TFN を呼び出します。

  2. 呼び出しは Amazon Connect 初期化フロー () に入りますinitFlow。

  3. 初期化フローは、3 つの DynamoDB テーブルからデータを取得する 3 つの Lambda 関数を呼び出します。

    • 最初の関数は、呼び出しが行われた環境 (本番稼働、ステージング、開発など) に基づいて Amazon Connect インスタンス ARNs を取得します。

    • 2 番目の関数は、ダイヤルされた番号に基づいて、国、言語、サポートキューなどの動的属性を取得します。

    • 3 番目の関数は、顧客の言語選択に基づいて IVR プロンプトメッセージを取得します。

  4. Amazon Connect 言語モジュール (langModule) は、選択した言語に基づいて Amazon Polly 音声を設定します。

  5. その後、呼び出しは、3 番目の DynamoDB テーブルから取得されたウェルカムメッセージやコールセンターオプションなどの動的プロンプトを再生する次の問い合わせフロー (mainFlow) に移動します。

  6. Lambda 関数は DynamoDB API を呼び出して、サブコンタクトフロー、モジュール、キューを呼び出します。

  7. コールは、IVR システム内の顧客の選択に基づいてサポートセンターエージェントにルーティングされる場合があります。エージェントの画面には、顧客の国、アイデンティティ、通話の理由など、キャプチャされたデータが動的に入力されます。

  8. 顧客の問い合わせデータは Amazon Connect の問い合わせレコードの一部として S3 バケットにも保存され、QuickSight を使用してカスタムレポートを生成するために使用できます。

この設計が実際のシナリオでどのように使用されたかについては、re:Invent 2020 プレゼンテーション「How Best Western built a Modular and dynamic contact center using Amazon Connect」を参照してください。サンプルコードについては、GitHub の「Dynamic Contact Center project」を参照してください。