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

# ユースケースの例
<a name="example"></a>

次に、前述の原則を適用してモジュール型の基盤アーキテクチャを構築する方法がわかるユースケースを見てみましょう。ここでは、架空のグローバル企業である Example Corp に焦点を当てて説明します。

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

このセクションでは、このガイドで取り上げた [IVR の設計原則](design-principles.md)をどのように Example Corp のユースケースに適用できるかを紹介します。 AWS サービスを使用して、組織の目標を特定し、カスタマーコンタクトジャーニーを構築し、会社の要件を満たすアーキテクチャフレームワークを作成するプロセスについて説明します。

## 組織目標を特定する
<a name="example-goals"></a>

Example Corp の主な組織目標には次のようなものがあります。
+ **コスト削減:** クラウドベースのコンタクトセンターに移行して、メンテナンスコストを削減し、イノベーションを促進します。
+ **セルフサービスのパーソナライズ:** 言語オプションなど、発信元の番号または国に基づいて、顧客にパーソナライズされたエクスペリエンスを提供します。
+ **IVR での解決率向上:** IVR システム内の支払い処理を合理化し、エージェントが介入しなくても顧客が製品やアドオンを購入できるようにします。
+ **変更管理/イノベーションセンターの改善:** IVR システムの個々の環境 (開発、ステージング、本番稼働) を維持し、変更管理と実験を効果的に行えるようにします。
+ **初回通話解決率を改善:** 言語、国、顧客の意図に基づいて有効なルーティング戦略をとります。

## カスタマーコンタクトのジャーニーをマッピングする
<a name="example-map"></a>

Example Corp のカスタマーコンタクトジャーニーを作成する際は、次の点を考慮する必要があります。
+ **発信元:** 着信通話に関連する国と事業部門を特定し、エクスペリエンスをカスタマイズします。
+ **言語の選択:** 発信者の発信国、プロファイル、Example Corp が対応している言語に基づいて、適切な言語メニューを提供します。
+ **顧客の認証:** アカウントの詳細、音声生体認証、またはその他の安全な方法を使用して発信者を認証します。
+ **パーソナライゼーション**: 顧客データを収集して、発信者に名前で挨拶したり、アカウントの履歴に基づいてカスタマイズされたメニューオプションを提供したりするなど、IVR エクスペリエンスをパーソナライズするのに使用します。
+ **セルフサービスオプション:** 残高照会、注文ステータスの更新情報、パスワードのリセットなど、顧客の一般的な問い合わせに対応するためのセルフサービスオプションを提供します。
+ **支払い処理:** 安全な支払いゲートウェイを統合して、顧客が IVR システム内で購入できるようにします。
+ **バックエンド統合:** パーソナライズされた挨拶、注文の更新、支払いなどのセルフサービスプロセスを実装できるように、バックエンド API の統合を検討します。それらの API の入手可能性と導入への準備状況を確認します。
+ **セキュリティとコンプライアンス:** ログのさらなる暗号化、マスキング、無効化が必要な情報 (カード情報や顧客 PII など) を特定します。
+ **反復可能なプロセス:** 支払いや発信者認証など、ほとんどの国や事業部門で繰り返し実行されるプロセスを特定します。

## 基盤となるアーキテクチャを作成する
<a name="example-architecture"></a>

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

**静的コンテンツを排除する**
+ 変数を使用して、各国に割り当てられた通話料無料番号 (TFN) に従ってプロンプトを動的に呼び出すことを検討してください。例えば、TFN1 がカナダに属している場合、外部データベースから適切なプロンプトを呼び出して、英語とカナダフランス語の言語オプションを顧客に提供します。顧客が選択したオプションに従い、外部データベースから英語 (またはカナダフランス語) のプロンプトを呼び出し、IVR コールのフロー全体で再生します。このアプローチでは TFN 全体で単一の IVR フローを使用し、冗長性をなくすことができます。
+ 発信者をルーティングする必要があるエージェントのキューとスキル、その通話を移動させる必要がある次の IVR ツリー、および API エンドポイントの値 (URL や Amazon リソースネーム (ARN) など) を外部データベースに保存することを検討します。これらは国または事業部門に割り当てられた TFN に基づいて呼び出すこともできます。
+ エクスペリエンスをさらに効率化するには、デプロイ環境の詳細を外部データベースに保存することもできます。例えば、TFN2 が開発環境にマッピングされている場合、その環境にのみ関連する言語プロンプト、API エンドポイント、エージェントキューやスキルを呼び出し、TFN3 がステージング環境にマッピングされている場合は、ステージングに割り当てられた通話の詳細を呼び出すなどです。このアプローチにより、コールフローの開発とメンテナンスを大幅に効率化できます。開発者がメンテナンスするコールフローが 1 つで済み、国、事業部門、環境に割り当てられた TFN などの主要なパラメータに基づいて、エクスペリエンスを簡単に変更できます。

**反復可能なプロセスを特定する**

Example Corp で国や事業部門を問わずに実行される反復可能なプロセスには、発信者の言語選択と支払い処理があります。こうしたプロセスをモジュールとして構築すると、あらゆるコールフロー全体で簡単に一元化、メンテナンス、呼び出しができます。

以下の図は、このガイドで説明する IVR の設計方法に従ったアーキテクチャの例です。このアーキテクチャでは、Connect Customer Flows とモジュールを以下の追加 AWS サービスと共に使用します。
+ ARN、動的属性、プロンプトを保存する Amazon DynamoDB テーブル。
+ AWS Lambda 関数は、DynamoDB テーブルから情報を取得します。
+ テキストを音声に変換する Amazon Polly。
+ Amazon Simple Storage Service (Amazon S3) は[、Connect Customer の問い合わせレコード](https://docs.aws.amazon.com/connect/latest/adminguide/ctr-data-model.html)を保存します。

![AWS サービスを使用した IVR アーキテクチャの例](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/ivr-design-on-connect/images/ivr-architecture.png)


IVR システムに実装されるステップは以下のとおりです。

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

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

1. 初期化フローは 3 つの Lambda 関数を呼び出し、それらは以下のように 3 つの DynamoDB テーブルからデータを取得します。
   + 最初の関数は、呼び出しが行われた環境 (本番稼働、ステージング、開発など) に基づいて [Connect Customer インスタンス ARNs](https://docs.aws.amazon.com/connect/latest/adminguide/find-instance-arn.html) を取得します。
   + 2 番目の関数はダイヤルされた番号に基づいて、国、言語、サポートキューなどの動的属性を取得します。
   + 3 番目の関数は顧客の言語選択に基づいて IVR のプロンプトメッセージを取得します。

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

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

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

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

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

この設計が実際のシナリオでどのように使用されたかについては、re:Invent 2020 プレゼンテーション[「How Best Western built a Modular and dynamic contact center using Connect Customer](https://youtu.be/qnIXMh203vc)」を参照してください。サンプルコードについては、GitHub で「[Dynamic Contact Center project](https://github.com/amazon-connect/amazon-connect-snippets/tree/master/projects/DynamicContactCenter)」を参照してください。