顧客問い合わせジャーニーをマッピングする

組織の目標が定義されたら、戻ってカスタマージャーニーマップを構築します。このマップは、一般的なエンゲージメントパターンと顧客のクエリの解決に必要なデータを特定するのに役立ちます。また、顧客に提示されたエクスペリエンス、予期しないイベントや緊急事態への対応、デプロイに必要な顧客からの問い合わせの量と規模を定義するのにも役立ちます。

このステップは、運用上の優秀性、セキュリティ、信頼性という 3 つの AWS Well-Architected フレームワークの柱を計画するために不可欠です。

カスタマーコンタクトジャーニーマップを作成する際に考慮すべき質問をいくつか紹介します。

• 顧客の問い合わせ理由は何ですか？

  この質問に対する回答は、残高の照会、注文ステータスの更新、パスワードのリセットなど、よくある質問を特定するのに役立ちます。

• 顧客の ID を検証するにはどうすればよいですか？

  セキュリティは最優先事項であり、顧客のアイデンティティを検証することは、問い合わせジャーニーの重要なステップです。認証オプションには、音声生体認証、ワンタイムパスワード、クレジットカード番号や生年月日などの個人情報が含まれます。また、この情報は、医療保険の相互運用性と説明責任に関する法律 (HIPAA)、Payment Card Industry Data Security Standard (PCI DSS)、System and Organization Controls (SOC) などのコンプライアンス要件を特定するのにも役立ちます。

• この顧客について既にどのような情報をお持ちですか？

  顧客が特定されると、関連する顧客データは、顧客のエクスペリエンスをパーソナライズし、問題をプロアクティブに解決するのに役立ちます。このデータには、顧客名、オープンケース、問い合わせ履歴と感情、購入動作が含まれます。

• 顧客のクエリを解決するにはどのような情報が必要ですか？

  顧客のクエリに対処するために必要な情報を決定することは、IVR システム内で収集する必要がある顧客データを定義するのに役立ちます。例えば、顧客が残高を確認する場合、アカウント番号とセキュリティ PIN が必要になり、IVR アプリケーションは銀行データを含むバックエンドデータストアと統合する必要があります。注文のステータスを確認するには、注文番号が必要です。 

• 顧客のリクエストを満たすために統合が必要ですか？

  通常、IVR でのセルフサービスリクエストでは、フルフィルメントを成功させるためにバックエンド統合が必要です。ユースケースに応じて、これらの統合は、組織内のデータベース、CRMs、またはチケット発行システムとすることができます。例えば、注文のステータスを伝えるには、注文管理システムから情報をクエリする必要がある場合があります。購入には、支払いゲートウェイとの統合が必要になる場合があります。関連する APIs の可用性を計画できるように、これらの依存関係を早期に特定することが重要です。

• 顧客のジャーニーやデータに関連するコンプライアンス要件は何ですか？

  コンプライアンス目標を定義し、IVR 設計に組み込むことが重要です。コンプライアンスプログラムは、通常、組織レベルで適用されます。これらのディスカッションと計画セッションには、情報セキュリティチームが関与することをお勧めします。

  例えば、IVR の支払い情報には、暗号化と PCI DSS コンプライアンスが必要になる場合があります。顧客から収集された個人を特定できる情報 (PII) には暗号化が必要です。IVR システムには、保護する必要がある追加情報が含まれる場合があります。

• 通話量が多い場合やエージェントが利用できなくなった場合、どのように対応すればよいですか？

  通話量が多いと待機時間が長くなるシナリオを特定することが不可欠です。このような状況では、IVR システムは顧客の問い合わせを効果的にリダイレクトするためのゲートウェイとして機能することがよくあります。一般的な回避戦略には、非常に長い待機時間中のコールバックの提供、ターゲットエージェントのプールを拡張するオーバーフローシナリオの設計、プロモーションメッセージの再生、顧客を別のチャネル (SMS またはチャット) にリダイレクトすることが含まれます。これらの戦略の詳細については、ブログ記事Amazon Connect で予期しない問い合わせの急増を処理する方法」を参照してください。

• 休日や緊急時のカスタマーエクスペリエンスはどのようにすべきですか？

  予期しない緊急事態や予期しないイベントは、組織による顧客へのサービス提供能力に影響を与える可能性があります。これらのイベント中にカスタマーエクスペリエンスを計画することは、信頼性のベストプラクティスです。さらに、休日は人員を制限する可能性があり、IVR システムは顧客に情報を提供し、期待を設定するのに最適な場所です。

  例えば、IVR システムで緊急プレースホルダーと祝祭日メッセージを設計し、更新して、必要に応じて関連する更新を再生できます。 

• 技術的な問題が発生した場合のカスタマーエクスペリエンスはどのようなものですか？

  アプリケーションまたはバックエンドの統合エラーが発生した場合でも、IVR フローに従っているとき、カスタマーエクスペリエンスは常に完全で意味のあるものでなければなりません。統合に障害が発生した場合の発信者エクスペリエンスを設計することをお勧めします。通常、再試行とループを実装したり、技術的な問題を伝えたり、お客様をエージェントに転送したりするメッセージを再生したりできます。どちらのシナリオでも、発信者エクスペリエンスが突然、原因不明のコミュニケーションにつながってはならないため、通常、より多くの通話が発生します。

カスタマーコンタクトジャーニーの概要を把握したら、反復可能なプロセスや一般的なパターンを探します。これらは、IVR アーキテクチャの基盤を設計する際の重要な焦点となります。