メッセージングのカスタマーエクスペリエンスの設計

このシリーズに含まれる記事

メッセージングの本質は、カスタマーが直接エージェントとコミュニケーションをとれるようにすることです。サポートのニーズが高まるにつれて、このコミュニケーションの一部を自動化することも考えられます。最初は、カスタマーをオンラインエージェントに引き渡す前に、簡単なあいさつメッセージを挿入してみましょう。その後、ナレッジベース記事の提供によるメッセージの削減や、リクエストを適切なエージェントにルーティングするためのトリアージに役立つカスタマー情報の取得、完全にパーソナライズされたエクスペリエンスを提供するためのサードパーティシステムの統合などのセルフサービスオプションを組み込むことができます。

この記事では、カスタマーエクスペリエンスの設計に役立つ基本事項について説明します。

この記事では、次のトピックについて説明します。

会話のスタイルを選択する
会話ボットの基本要素を設計する
オフラインのシナリオを考える

会話のスタイルを選択する

メッセージングボットを構築する際、組織のニーズに応じて複雑度や簡潔さを調整することができます。

短くシンプルなスタイル

オンラインチャットのような簡素なアプローチがエージェントとカスタマーの双方に最適である場合、エージェントに会話を引き継ぐ前に短いあいさつメッセージを自動挿入するボットを実装できます。最小限の構成で、簡単なフォームを追加してカスタマーから基本情報を収集して、サービスを提供する相手のプロフィールを把握したり、Guideのヘルプセンター記事を提案して、エージェントの手を借りずにカスタマーが問題を自己解決できるようにしたりすることができます。

複雑で包括的なスタイル

複雑なカスタマーサービスのシナリオにも対応し、同程度に複雑なメッセージングソリューションを提供することもできます。カスタマーのための選択肢をあらかじめボットに組み込んだり、APIコールを使用して外部ソースから情報を会話に取り込んだり、カスタマーの所在地やメッセージの送信時間帯に基づいた選択肢を提供したりすることができます。

中間のスタイル

上記の2つのスタイルの中間に位置する会話ボットを設計することもできます。メッセージングは簡単に拡張可能で無限にカスタマイズできるため、ほとんどの場合、カスタマーとのやりとりを希望どおりに自動化できます。

ただし、お勧めする特に重要な指針が1つあります。会話ワークフローを設計する際、過度な複雑さに陥らないように心掛けましょう。そのように設計してしまうと、元に戻すのが本当に難しくなります。メッセージングについて学習している間は、シンプルに現実的なワークフローを設計しましょう。サービス提供の経験を積むとともに、常に「理想的な経験」を改善し続けることが可能になります。

会話ボットの基本要素を設計する

カスタマーエクスペリエンスの計画全体を詳細に構築していく前に、メッセージング会話の基本を理解しておくことをお勧めします。

あいさつメッセージ：カスタマーと会話ボットとの最初のやりとり。
セルフサービスオプション：エージェントがより複雑なサポートリクエストに対応できるように活用されるチケット削減ツール。
会話とチケットのワークフロー：ボットが会話をライブエージェントに引き渡すタイミングと方法、メッセージングサポートチケットがたどるその後の経路、エージェントとカスタマー間を同期および非同期でやりとりする方法、など。

あいさつメッセージ

あいさつメッセージはメッセージング会話のトーンを設定します。カスタマーが初めて会話ボットを開くことを想像して、以下の質問を考えてみてください。

どのような第一印象を与えたいか。カジュアルでフレンドリーなスタイルにするか、それともビジネスライクなスタイルにするか、ボットのスタンスを決めます。
カスタマーにすぐに伝えたい情報は何か。提供するサービス、エージェントの空き状況、予想される待機時間について、カスタマーの事前期待を適正化するために、あいさつメッセージを使用できます（使用すべきです）。

セルフサービスオプション

カスタマーが問題を自己解決するためのオプションをボットに組み込むことにより、エージェントとカスタマーの双方の時間を節約することができます。会話ボットにこれらを組み込む方法はいくつかあります。

ヘルプセンターの記事を提案する：製品の説明や会社の方針など、目当ての情報を提供できるGuideのコンテンツにカスタマーを誘導できます。
あらかじめ定義したメッセージを提示する：よくある質問に対する回答を即座にカスタマーに提供できます。
APIコールを使用して外部ソースのデータを会話に取り込む：特に、システムステータスや現在のサポートの待ち時間など、定期的に更新される情報や、カスタマーに関係する情報をリクエストする場合に便利です。
問題が解決されたかどうかを尋ねる：エンドユーザーは上記のボット回答の中に問題を解決できるものがあるかどうかを判断し、エージェントが対応する前にサポートチケットを終了することができます。

会話とチケットのワークフロー

会話ボットの設計がどれだけ緻密であろうとも、オンラインエージェントに転送して割り当てる必要があるカスタマーサポートリクエストが届くことはあります。転送が行われるタイミングと方法を検討し、転送後の会話を管理するルールを確立し、チケットの転送経路を検討する必要があります。

ボットが最初の会話中に収集した情報を使用して、ボットからエージェントに問題を転送する条件を考えます。この記事で説明した他の要素と同様に、エージェントへの会話の転送方法をシンプルにするか複雑にするかは調整可能です。

エージェントへの引き渡しは、会話が転送されることをカスタマーに知らせるシンプルなメッセージで始まり、その後、会話をエージェントのキューに追加することにより実行されます。引き渡し処理には、必要に応じて以下のいずれかを組み込むことができます。

フォーム：カスタマーからデータを収集します。
予想待機時間：エージェントにつながるまでの待機時間をカスタマーに知らせます。
通知オプション：エージェントの手が空いたときにカスタマーに連絡できるようにします。

エージェントに引き渡された後の会話の管理方法について検討する必要があります。

会話の割り当て：会話をエージェントまたはエージェントグループに割り当てられるようにするか、それともエージェントが手動で受け取るようにするのか。
会話のルーティング：会話をトリアージし、特定のグループやスキルにエスカレーションするか。
カスタマーへの通知：エージェントが会話に加わったことをカスタマーにどのように知らせるか。
また、メッセージング会話から生成されたチケットの管理方法についても決定する必要があります。チケットを「オープン」から「解決済み」に導く過程で、以下のツールが利用できます。
エージェントワークスペース：エージェントのチケットおよび会話の管理ハブです。
ビュー：チケットのワークフローを管理・整理するビューを作成できます。

オフラインのシナリオを考える

メッセージングは持続的で、しばしば非同期的な性質があるため、エージェントまたはカスタマーのいずれかがメッセージに即座に応答できない状況を想定して計画する必要があります。

メッセージングチケットは、他のすべてのチャネルと同様に、ビューで管理されます。以下のオフラインシナリオのいくつかでは、アクティブな会話と非アクティブな会話をフィルタリングするために新しいビューを設定する必要があります。

フローを設計する際に考慮すべき一般的なシナリオを以下に挙げます。

カスタマーが応答しなくなった

会話の途中でカスタマーが応答しなくなった場合、エージェントは次のように対処できます。

追加のヘルプが必要かどうか尋ねます。10分経ったら、エージェントはエンドユーザーに、チケットを「保留中」または「解決済み」に更新し、エンドユーザーが非同期で再接続（チケットは保留中となる）するか、フロービルダーでやり直す（チケットは解決済みになる）ことができると伝えます。
自動化を活用して、チケットのステータスを保留中、または解決済み/終了に変更します。解決済みのチケットは、カスタマー満足度（CSAT）アンケートを案内するトリガになる可能性があることに留意してください。この場合、CSATトリガを編集して、自動解決されたチケットが除外されるようにするのがベストプラクティスです。

エージェントのオフライン時/営業時間外にカスタマーが応答した

エージェントは、オフライン中のコミュニケーションにボトルネックが生じるのを防ぐために、シフト終了前にチケットを再割り当てする必要があります。未割り当てのメッセージングチケットを表示するビューを作成できます。
エージェントがオフライン中にカスタマーから未解決のチケットへの返信があった場合、エージェントが次回Zendeskにログインしたときに、通知リストにカスタマーからのメッセージが表示されます。
エージェントの離席時間が長い場合は、在席状況アプリの利用を検討します。

チケットが終了または解決された後にカスタマーから返信があった

チケットが解決済みの場合、会話は元のエージェントに戻され、「オープン」ステータスになります。
チケットが終了された場合、エンドユーザーはAnswer Botのフローに戻され、「エージェントへの転送」ステップで新しいチケットが作成されます。