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

基盤となるアーキテクチャを作成する

組織目標を定義し、カスタマーコンタクトジャーニーの概要が描けたら、その情報を使用して 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 を送信 モジュールを作成できます。このアプローチでは単一のフローを維持でき、モジュールの更新はすべての事業部門に効率的に反映されます。反復可能なプロセスのよくあるその他の例は次のとおりです。