概要

移行を成功に導くための柱

コンタクトセンターの移行を成功させるには、移行を単なる技術提供プロジェクトとして捉えるのではなく、多角的な視点からアプローチする必要があります。そうしなければ、スタッフトレーニングや運用モデルの変更といった重要な準備を見落としてしまう可能性があります。全体的な成功を導くためには、このようなテクノロジー以外の考慮事項が極めて重要です。

次の図に示す柱は、 AWS クラウド導入フレームワーク (AWS CAF) で説明されている視点と機能です。このフレームワークは、革新的な の使用を通じてビジネス成果をデジタルで変革し、加速するためのベストプラクティスガイダンスを提供します AWS。各視点では、コンタクトセンターの変革と移行プロセスにおいて、ステークホルダーが所有または管理する一連の機能を取り上げます。

ユーザー (お客様、エージェント、オペレーター) を新しいプラットフォームやツールセットに移行させるには、かなりの労力を要します。コンタクトセンターの移行には、既存のオンプレミスのコンタクトセンターをクラウドに移行する場合でも、お客様とエージェントのエクスペリエンス全体をリファクタリングする場合でも、綿密な計画が必要です。

以下のセクションでは、Amazon Connect への移行を計画、管理、完了するためのアプローチとベストプラクティスについて説明します。

主要なビジョン

コンタクトセンターの移行を成功させるには、最初にビジネス要件を確認し、次に人材、プロセス、テクノロジーに焦点を当てます。 

最初に主要なビジョンのステートメントを作成して、Amazon Connect への移行の計画を開始します。このステートメントが、意思決定の方向性を導く一般原則になります。これにより、この一般原則の範囲内で、特定の意思決定分野についてより具体的な指針を定義できます。

例えば、プロジェクトの主要なビジョンステートメントは、「成功とはどのようなものですか？」という質問に答えることができます。「サービスラインをペースで移行する際の最小限のユーザー中断 (重要度: 顧客、エージェント、システムオペレーター）」。

次のフレーズが強調されていることに注目してください。

• ユーザーの作業中断を最小限に抑える — コンタクトセンターの営業時間とバックエンドシステムによっては、移行中のダウンタイムを完全に回避できない場合があります。予想される混乱が、ダウンタイムなしで移行を完了するのに必要な時間と労力と比較して、許容範囲内かどうかを現実的に検討します。中断しないよりも最小限の中断を受け入れることで、プロジェクトのデリバリーの他の分野でのリスクを軽減したり、大幅なコスト削減を可能にしたりすることができます。例えば、既存のウェブアドレスを移行する代わりに、新しい Amazon Connect デスクトップにアクセスするための新しいウェブアドレスをユーザーに配布することができます。これにより、新しいドメイン証明書に署名したり、ウェブアドレスのカットオーバーを管理したりする手間や費用を省くことができます。

• ユーザーリスト (重要度の高い順) — 移行中は、お客様、エージェント、システムオペレーターの優先順位が異なります。一般的に、最優先事項は、エージェントやバックエンドシステムオペレーターに対してさらなる中断が発生した場合でも、お客様の中断を回避することです。

• ペース — 移行中に複数のコンタクトセンタープラットフォームを運用すると、財政的にもリソース的にもコストがかかります。デュアルシステムを導入する期間をできるだけ短くすることを目標にします。その期間が長いほど、コストがかさんで、オペレーターの負担も大きくなり、間違ったプラットフォームで変更を加えるといった人為的ミスのリスクも高まります。迅速な作業の必要性を念頭に置きつつ、厳密さと複雑さのバランスを取ってください。現実的なデリバリー計画を立て、それに従うように努めます。

ターゲットを絞ったビジネス成果

コンタクトセンターの移行を計画する際には、以下のビジネス成果を念頭に置いてください。

• ビジネスの俊敏性の向上 — 新しい機能を迅速かつ安全に本番環境に提供します。例えば、感情分析やビッグデータによる通話記録のクローリングは、お客様とのコミュニケーションに関するインサイトをほぼリアルタイムで収集し、お客様のニーズに基づいて製品やサービスを最適化するのに役立ちます。これらの機能を特定して実装したら、デベロッパーとオペレーター間のコラボレーションを促進する DevOps の原則を使用して機能を提供したり、Infrastructure as Code (IaC) ツールや継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを使用して構築を管理してテストを自動化したりすることができます。実装プロセスにバグを発生させる可能性のある人為的ミスを避けるため、手動でステップを繰り返すことはできるだけ避けてください。

• 総保有コスト (TCO)の改善 (特に初期段階) — リワークには時間と労力がかかります。初期段階で、重要な決定を適切に行うことができるように、移行の検出と設計のフェーズには十分な時間を割り当ててください。インフラストラクチャに関する決定を変更するには膨大なコストがかかるため、適切なステークホルダーに相談してください。例えば、通話録音の暗号化ポリシーを変更すると、追加のインフラストラクチャコンポーネントが必要になる場合があるため、実装を開始する前に、セキュリティコンプライアンスチームが暗号化ポリシーを承認していることを確認します。構築段階に進む前に、設計を承認します。

• アジャイルなカスタマーエクスペリエンス - アジャイルな方法論を使用して、迅速かつ反復的に発信者ジャーニーを開発します。インフラストラクチャコンポーネントとは異なり、コンタクトフローやユーザージャーニーは変更が容易であるため、基本的なフローから早期に開始して、ステークホルダーとの反復作業を繰り返し行い、目的の状態に到達するようにします。Amazon Connect では、メッセージプロンプトの追加やメニューオプションの変更を簡単に行うことができます。プログラミングの知識は必要ありません。目標は、適切なユーザージャーニーを提供することであって、当初設計したジャーニーに厳密に従うことではありません。反復作業を頻繁に行うことで、ステークホルダーは、ジャーニーが成熟し、フィードバックを受け取る過程で、ジャーニーを微調整することができます。

• スムーズでタイムリーなサービス導入 — ユーザートレーニング、プロセスの変更、サービスデスクの変更は、プロジェクトがほぼ完了するまで見過ごされがちです。新しいコンタクトセンターは、本番稼働開始日に間に合わせるだけではなく、組織の通常業務 (BAU) 業務として受け入れられる必要があります。プロジェクトチームからの適切な引き継ぎを行わなければ、BAU チームは新しいプラットフォームを使用する準備を整えることができません。プロジェクトを BAU オペレーションに統合することが、本番稼働の承認の入り口になります。本番稼働を開始する前に、プラットフォームの所有権について合意することが重要です。サービスの導入と運用モデルのステークホルダーをプロジェクトの初期段階から関与させ、プロジェクト全体を通じて関わってもらいます。

• 顧客満足度 (CSAT) スコアを向上させるために、差別化を図る新しい機能を導入する — Amazon Connect によってユーザーエクスペリエンスを簡素化または改善できるかどうかを検討します。現在のコールセンターをクラウドに移行することだけに限定しないようにします。Amazon Connect の機能を使用して、ユーザー (お客様とエージェント) のエクスペリエンスを向上させたり、プラットフォームの技術的実装を簡素化したりします。Amazon Connect の新機能を比較的少ない労力でコールセンターに組み込むことができるため、CSAT スコアが大幅に向上します。