翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 基盤となるアーキテクチャを作成する
組織目標を定義し、カスタマーコンタクトジャーニーの概要が描けたら、その情報を使用して IVR システムの基盤となるアーキテクチャを定義します。これらのデータポイントは、モジュール方式のスケーラブルな IVR アーキテクチャを作成する上で非常に重要です。優れた基盤フレームワークを構築する上での重要な原則は次のとおりです。
+ 静的設計の排除
+ 反復可能なプロセスを特定する
## 静的設計の排除
IVR システムを設計するときに開発者が行う一般的な間違いは、フローに静的情報またはハードコードされたロジックを導入することです。静的情報には、プロンプトメッセージ、次に呼び出す通話フローの値、または通話をルーティングするスキルグループなどがあります。また、IVR から呼び出される API エンドポイントのアドレス、または IVR システム内の分岐ロジックに使用される、返された変数の場合もあります。
IVR システムで静的な値を使用すると、リアルタイムでの追跡や変更が難しくなり、フローに冗長性が生じます。可能な限り動的な設計を行うことがベストプラクティスです。これについて理解を深めるために、多言語 IVR システムの設計例を見てみましょう。
**静的なアプローチ:**
通常、多言語 IVR システムを設計する開発者は、顧客の優先言語を特定し、同じフローの 2 つのバージョンを作成します。次の図に示すように、1 つ目のバージョンには言語 A でハードコードされたプロンプトメッセージ、2 つ目のバージョンには言語 B でハードコードされたメッセージがあります。
このアプローチでは、開発者が同じフローの異なるバージョンを維持する必要があるため、スケーリングが困難です。また、新しい言語を追加するたびに、新しいバージョンのフローを作成する必要があります。
さらに、1 つのフローでビジネスロジックを変更した場合、他のバージョンに手動でレプリケートする必要があります。このアプローチによる IVR 設計は煩雑でモジュール方式に反し、イノベーションを市場投入するまでの時間が長くなります。
**動的なアプローチ:**
この問題を解決するために推奨されるアプローチは、IVR デザイナーのプロンプトブロックに静的な値を使用する代わりに、プロンプトメッセージを変数に割り当てることです。次のフローチャートに示すように、顧客が選択した言語に基づいて外部データベースからプロンプトの値を呼び出し、変数を入力してそれらのメッセージを再生します。このアプローチを使用すると、IVR フローは 1 つのみで、*n* 個の言語に簡単にスケールできます。開発者は外部データベースに言語プロンプトを追加し、IVR システムでの顧客の選択または CRM クエリから返されたデータに基づき、(API を使用して) 呼び出します。こうすることで、ビジネスロジックを変更しても IVR システムは保護されます。このモデルを使用する場合は、最小限の静的メッセージを含むデフォルトのブランチを用意しておき、データベースまたはクエリの失敗時に使用できるようにしてください。
## 反復可能なプロセスを特定する
カスタマーエクスペリエンスに含まれる反復可能なパターンを特定すると、IVR システムの中の冗長なコンポーネントをなくすことができます。反復されるユースケースに対して再利用可能なロジックまたはモジュールを作成すると、さまざまな通話フローで必要に応じて呼び出すことができます。例えば、セールスチームとサポートチームの両方が IVR システム内で SMS 通知を送信する必要がある場合は、両方の事業部門で使用できる、再利用可能な *SMS を送信* モジュールを作成できます。このアプローチでは単一のフローを維持でき、モジュールの更新はすべての事業部門に効率的に反映されます。反復可能なプロセスのよくあるその他の例は次のとおりです。
+ 顧客の入力に基づいて IVR フローに言語選択を割り当てる。
+ IVR システムで支払い処理を行う。
+ 発信者認証ロジック。
+ CRM 検索を使用して顧客を特定する。CRM で顧客検索モジュールをモジュール化すると、専用接続 (多くの場合独自の言語を使用) をシンプルな IVR ブロックに変換できます。その後は、カスタマーエクスペリエンスを開発するユーザーは誰でも、これらの IVR ブロックにアクセスして使用できます。
+ 緊急メッセージのルーティングを実行する。