ユーザージャーニーのワークストリーム - AWS 規範ガイダンス
発見設計ビルドテストデプロイ本番稼働開始後のサポート (PGLS)

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

ユーザージャーニーのワークストリーム

ユーザージャーニーのワークストリームには、労力や影響を最小限に抑えて変更または取り消しを行うことできる決定事項も含まれます。ユーザージャーニーの基本的な構築から始めて、最終製品に到達するまで頻繁かつ迅速に反復することに重点が置かれています。最終的なユーザージャーニーが最初に提案されたものと全く同じになることは稀であるため、このワークストリームではアジャイルで反復的なアプローチが適しています。

ユーザージャーニーのワークストリームは、検出、設計、構築、テスト、デプロイ、本番稼働開始後のサポートの 5 つのフェーズで構成されています。

コンタクトセンターの移行におけるユーザージャーニーのワークストリーム

発見

このフェーズでは、既存のユーザージャーニーフローと設計を収集し、それらをコンタクトフロー構築チームに渡します。これらが存在しない場合や、新しいユーザージャーニーを設計する場合は、ワークショップにステークホルダーを集め、次のようなビジュアルキャプチャツールを使用してユーザージャーニーのフレームワークを共同で開発します。

  • ビジュアルキャンバスツール — Microsoft PowerPoint、Microsoft Visio、draw.io などのツールを使用します。ワークショップに参加しているすべてのステークホルダーとキャンバスを画面共有します。ブロックや決定ポイントを追加してエンドツーエンドのユーザージャーニーを構築し、後で確認する必要があるステップ (キューイングメッセージのオーディオファイルの正確な文言やインポートなど) のプレースホルダーを追加します。プレースホルダーを確認する必要がある所有者の名前を追加します。

  • コンタクトフローデザイナー — draw.io や Visio などの描画ツールを使用する代わりに、Amazon Connect に含まれているコンタクトフローデザイナーを使用して、ユーザージャーニーを画面共有を介して開発および文書化することを検討してください。後で確認する必要があるステップ (キューイングメッセージのオーディオファイルの正確な文言やインポートなど) には、プロンプトブロックプレースホルダーを使用します。シンプルなtext-to-speech (TTS) プロンプトブロックを使用して、ステップを確認する所有者を記録します (例：「John Smith から提供されるキュー A メッセージ .wav ファイル」）。これにより、ユーザージャーニーとルーティングロジックのエンドツーエンドのテストを並行して実行できます。

ワークショップの参加者: 

  • プロジェクト管理者

  • ビジネスアーキテクトとソリューションアーキテクト

  • ビジネスアナリスト

  • サービスラインの所有者とオペレーター

設計

設計ドキュメントはオプションです。ドキュメントは、コンタクトフローのサイズと複雑さによって異なります。直感的でわかりやすいフローチャートインターフェイスを備えたコンタクトフローデザイナーを使用すると、ジャーニーが自己文書化され、コンタクトフローの実際の構築を表すことができます。これにより、ユーザージャーニーの迅速かつアジャイルな開発における信頼できる単一の情報源が確保されます。それ以外の場合は、コンタクトフローのスタンドアロン設計ドキュメントが時間の経過とともに実際の構築から逸脱しないように、変更管理を徹底して行う必要があります。

ビルド

Amazon Connect の設定は、Infrastructure as Code (IaC) ツールの AWS CloudFormation テンプレートと API を使用して行うことができます。DevOps ツールを使用して、セキュリティプロファイルやコンタクトフローなどの Amazon Connect コンポーネントを構築および管理します。コンタクトフローデザイナーを使用してフローを設計する場合は、IaC DevOps ツールにフローを組み込み、JSON ファイルとして手動でエクスポートすることができます。

注記

また、他の AWS アカウントの作成中に開発環境で問い合わせフローの構築を開始し、Amazon Connect インスタンスの準備ができたら、フローをテスト環境と本番環境にエクスポートすることもできます。

テスト

テストフェーズは次の 2 つの連続したサブフェーズで構成されます。 

  • 機能テスト — Amazon Connect でコンタクトフローが作成されると、アジャイルスプリントで繰り返し実行されます。実施者: 機能テストチーム

  • ユーザー受入テスト (UAT) — コンタクトフローが機能テストに合格した後にのみ実施されます。実施者: クライアントのビジネスユーザー (専任チームまたはサービスラインビジネスユニットのユーザー)

デプロイ

このフェーズでは、エージェントとユーザーの認証情報が Amazon Connect の本番稼働インスタンスにアップロードされ、ユーザーがログインできるようになります。コンタクトフローは、前のフェーズの UAT テストに合格した後にのみアップロードしてください。Amazon Connect ダッシュボードで仮の電話番号を申請し、それをコンタクトフローに割り当てます。これらの電話番号はプロジェクトチームにのみ表示され、プロジェクトチームはその番号を使用してテストコールを行います。多くの場合、プロジェクトチームはこのプロセス中にいくつかの UAT スクリプトを実行します。このアプローチでは、システムが本番稼働し、実際のエージェントがワークフローにアクセスできるようになる前に、ユーザージャーニーの準備 (パイプクリーン) のテストを行います。本番稼働の予定時刻になると、この一時的な番号はお客様が使用するパブリックにルーティン可能な番号に置き換えられます。この時点で新しいシステムに切り替わります。必要に応じて、番号を従来のサービスラインに切り替えて、変更をロールバックすることができます。

本番稼働開始後のサポート (PGLS)

プロジェクトチームは、新しいコンタクトセンターが本番稼働してから最初の数週間は、サービスラインのステークホルダー、通常業務 (BAU) サポートチーム、エンドユーザーとの連携を続けます。プロジェクトチームは、ユーザーが新しいシステムを使い始める際のサポートを行い、BAU サポートチームと一緒に問題のトラブルシューティングに取り組み、お客様やエージェントのフィードバックに基づいてコンタクトフローを改善します。