翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
基盤アーキテクチャを作成する
組織の目標を定義し、カスタマーコンタクトジャーニーの概要を示したら、その情報を使用して IVR システムの基本的なアーキテクチャを定義できます。これらのデータポイントは、モジュール式とスケーラブルの両方の IVR アーキテクチャを作成する上で重要です。優れた基本フレームワークを構築するための重要な原則は次のとおりです。
-
静的設計を排除する
-
繰り返し可能なプロセスを特定する
静的設計を排除する
開発者が IVR システムを設計するときによくある間違いは、フロー内に静的な情報またはハードコードされたロジックを導入することです。この静的情報には、プロンプトメッセージ、呼び出す次の通話フローの値、または通話をルーティングするスキルグループが含まれます。また、IVR から呼び出される API エンドポイントのアドレス、または返される変数で、IVR システム内の分岐ロジックに使用されます。
IVR システムで静的な値を使用すると、リアルタイムで追跡および変更することが困難になり、フローに冗長性が生じます。ベストプラクティスは、可能な限り動的な設計を行うことです。これをよりよく理解するために多言語 IVR システムを設計する例を見てみましょう。
静的アプローチ:
通常、多言語 IVR システムを設計している間、デベロッパーは顧客の優先言語を特定し、同じフローの 2 つのバージョンを作成します。次の図に示すように、最初のバージョンには言語 A でハードコードされたプロンプトメッセージがあり、2 番目のバージョンには言語 B でハードコードされたメッセージがある場合があります。
このアプローチは、デベロッパーが同じフローの異なるバージョンを維持する必要があるため、スケーリングが困難です。また、新しい言語を追加するたびに、フローの新しいバージョンを作成する必要があります。

さらに、あるフローでビジネスロジックに加えた変更は、他のバージョンに手動でレプリケートする必要があります。これにより、IVR 設計が煩雑で非モジュール的になり、イノベーションの市場投入までの時間が長くなります。
動的アプローチ:
この問題を解決するには、IVR デザイナーのプロンプトブロックで静的な値を使用する代わりに、変数にプロンプトメッセージを割り当てることをお勧めします。顧客が選択した言語に基づいて、外部データベースからプロンプトの値を呼び出し、次のフローチャートに示すように、それらのメッセージを再生する変数を入力します。このアプローチを使用すると、単一の IVR フローを維持し、n 個の言語に簡単にスケールできます。デベロッパーは、外部データベースに言語プロンプトを追加し、IVR システム内の顧客選択、または CRM クエリから返されたデータに基づいて (API を使用して) 言語プロンプトを呼び出します。これにより、ビジネスロジックの変更から IVR システムも保護されます。このモデルを使用する場合は、データベースまたはクエリの失敗時に使用できる最小限の静的メッセージのセットを持つデフォルトブランチがあることを確認してください。

繰り返し可能なプロセスの特定
カスタマーエクスペリエンスの繰り返し可能なパターンを特定すると、IVR システム内の冗長コンポーネントを排除できます。繰り返し使用するユースケースに対して再利用可能なロジックまたはモジュールを作成し、さまざまなコールフローで必要に応じて呼び出すことができます。例えば、営業チームとサポートチームの両方が IVR システム内で SMS 通知を送信する必要がある場合は、両方の事業部門で使用できる再利用可能な単一の Send SMS モジュールを作成できます。このアプローチを使用すると、単一のフローを維持でき、そのモジュールの更新はすべての LOBs に合理化された方法で反映されます。繰り返し可能なプロセスのその他の一般的な例は次のとおりです。
-
顧客の入力に基づいて IVR フローに言語選択を割り当てる。
-
IVR システムへの支払い処理の実装。
-
発信者認証ロジック。
-
CRM ルックアップを使用して顧客を識別する。CRM で顧客検索モジュールをモジュール化することで、独自の言語を頻繁に使用する専用接続を単純な IVR ブロックに変換できます。カスタマーエクスペリエンスを開発するユーザーは誰でも、これらの IVR ブロックにアクセスして使用できます。
-
緊急メッセージルーティングの実行。