• メッセージングの導入ガイド:はじめに
  • パート1:メッセージングによる会話サポートについて
  • パート2:会話メッセージングワークフローの設計
  • パート3:メッセージング必要な人員と運用要件の計画
  • パート4:メッセージングによる会話サポートの実装

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

メッセージングの本質は、カスタマーが直接エージェントと会話できるようにすることです。これは、会話サポートとして知られています。

サポートのニーズが高まるにつれて、カスタマーをエージェントに引き継ぐ前に簡単なメッセージを送ったり、問い合わせの数を減らすためにナレッジベースの記事を使用するなど、コミュニケーションの一部を自動化したくなるかもしれません。その後、より複雑なボットを設計することもできます。複雑なボットでは、会話の多くを自動化し、カスタマーに質問してサポート課題を明確に定義し、適切なエージェントに会話をルーティングし、カスタマーから有用なデータを収集し、カスタマーが問題を自己解決できるように選択肢を提示することができます。多くのアカウントにとって、一切自動化されていない状態と、非常に複雑に自動化された状態の中間あたりの構成が理想的です。

この記事では、次のトピックについて説明します。
  • 会話サポートの目標を特定する
  • メッセージングチャネルを選択する
  • オフラインのシナリオを考える
  • 会話のスタイルを選択する
  • ボットによる会話の自動化を検討する
  • 次のステップ

会話サポートの目標を特定する

カスタマーは、1回の対話で、複数のチャネルをまたいで、そして同じ話を繰り返すことなく、問題が迅速に解決することを期待しています。メッセージングを使用した会話サポートは、これ以上のことを実現します。

会話サポートを導入する理由はさまざまですが、それが自社の組織にとって適切である具体的な理由を理解することが重要です。目標と目的は、今後の会話サポートワークフローの設定と維持に関する意思決定に反映されます。

目標を明確にするには、次の質問について考えてみてください。

カスタマーを理解する
  • カスタマーが最も利用しそうなのはどのチャネルか?
  • カスタマーはどのようなコミュニケーションを好むか?
  • カスタマーがサポートを求めるときに使用するデバイスは?
  • 最も多くのメッセージを受け取るのはいつか? 時間帯は? 曜日は? 月や年の特定の時期ですか?
  • カスタマーが、エージェントと同時に別々の会話をする可能性はどのくらいあるか?
業務を理解する
  • エージェントがチケットに対応するのにどのくらい時間がかかるか?チケットの解決にどのくらい時間はがかかるか? 平均では? 最長時間と最短時間は?
  • カスタマーはキューの待ち時間や解決時間に満足しているか? カスタマー満足度を向上させたいか?
  • チケットの解決には通常、何人のエージェントが関与しているか?
  • 充実したレポート機能が必要か?
  • エージェントの作業のうち、繰り返し作業がどれだけあるか?ボットや自動化によって、この繰り返しをどの程度削減できるか?
    • ボットや自動化を使用して、チケットを削減することを計画している場合、具体的な削減目標は何か?セルフサービスオプションでチケットを大幅に削減できるか? チケットの一部は削減できても、大部分はまだエージェントに届くと予想されるか? エージェントが対応可能な場合に、カスタマーにより多くの情報を提供して会話をサポートするか?
  • 現在の組織で現実的にサポートできるチャネルはどれか?
    • 現在はどのチャネルを使っているか?
    • 使用率が低い、または提供する価値に対してコストが高すぎるなどの理由で削除できるチャネルがあるか?
    • エージェントやカスタマーのフィードバックに基づいて追加を検討している具体的なチャネルはあるか?
    • ソーシャルメッセージングチャネルを検討している場合、どのソーシャルチャネルが効果がありそうか?
    • よりスピード重視で、会話ベースのサポートが必要な特定の種類の問い合わせがあるか?
    • より多くのチャネルや異なるチャネルをサポートできるように、人員やスケジュールを調整できるか?
  • 営業時間外に届くカスタマーからのリクエストにどのように対応するか?
  • 効率性をどの程度重視しているか? 現在のエージェントはどの程度効率的か? 効率性の向上を検討しているか?
  • どのようにエージェントに業務をルーティングしているか? 組織内での業務の割り当てにプッシュモデルが必要か? それともプルモデルの方が効果的に機能するか?

メッセージングチャネルを選択する

メッセージングによる会話サポートを提供するための目標を特定したら、実装したいメッセージングチャネルについて明確な考えを持つ必要があります。これらはおそらく、会社にとって最も手頃な価格で提供できるものと、カスタマーが最も恩恵を受けられるものとの間の妥協点となるでしょう。以下の中から選ぶことができます。

  • Webサイトチャネル
  • Android用、iOS用、Unity SDK用の各モバイルチャネル
  • ソーシャルチャネル

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

メッセージングは、持続的で、しばしば非同期的なコミュニケーションスタイルを提供します。エージェントまたはカスタマーがメッセージにすぐに応答できない状況を想定しておくことが重要です。メッセージングワークフローを設計する際に考慮する必要がある一般的なシナリオを以下に示します。

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

このシナリオに対処する方法はいくつかあります。
  • 24時間365日のオンラインサポート体制の場合、エージェントがオフラインの間にコミュニケーションのボトルネックが発生しないように、エージェントのシフトが終了する前にチケットを再割り当てするポリシーを導入することができます。これに伴い、未割り当てのメッセージングチケットのビューを作成します。
  • 24時間365日のオンラインサポート体制がない場合、エージェントがオフラインの間にエンドユーザーが未解決のチケットに応答すると、エージェントはそのメッセージの存在を次にZendeskにサインインした際に通知リストで確認できます。
  • エージェントが不在の時間が長い場合は、在席状況アプリの利用を検討してください。

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

10分以内にメッセージを受信しなかった場合、会話はアイドル状態と見なされます。同様に、10分間操作がないと、そのユーザーはアイドル状態と見なされます。エンドユーザーが会話の途中で応答しなくなった場合、次の2つの選択肢があります。
  • エージェントは、引き続き助けが必要かどうかエンドユーザーに尋ねます。その後、エンドユーザーがアイドル状態になってから10分以上経過したら、エージェントはエンドユーザーにチケットのステータスを「保留中」または「解決済み」に更新すると伝えます。
  • エンドユーザーがアイドル状態のしきい値である10分に達した後に、自動化を活用してチケットのステータスを「保留中」、「解決済み」、または「終了」に変更できます。

どちらの場合も、チケットのステータスを「解決済み」に変更するとトリガが発動し、ボットによってカスタマー満足度(CSAT)評価のアンケートが表示される可能性があることに留意してください。CSATトリガがある場合は、自動解決チケットをトリガから除外することをおすすめします。

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

カスタマーが解決済みチケットに応答した場合、会話は元のエージェントに通知され、チケットが「オープン」ステータスに変わります。カスタマーが終了済みチケットに応答した場合は、メッセージングワークフローをやり直すことになります。

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

メッセージングワークフローを構築する際、組織のニーズに応じて複雑度や簡潔さを調整することができます。「メッセージングワークフローを過度に設計しない」というゴールデンルールを採用することをお勧めします。

ボットや自動化を実装した後で元に戻すのは非常に困難です。したがって、現実的であることが重要です。シンプルさを優先してワークフローを設計します。そして、メッセージングと会話サポートに関する知識が深まるにつれて、より複雑な自動化を繰り返し、メッセージングワークフローを改善することができます。

次のような会話スタイルを検討してください。

  • 短くシンプルなスタイル

    効率化されたオンラインチャットのようなアプローチがエージェントとカスタマーにとって最適である場合、自動化をほとんどまたは全く取り入れずにワークフローを実装することができます。最小限の構成では、自動化されたメッセージを提供し、エージェントがスムーズにサポートできるように、カスタマーから基本的な情報を収集するシンプルなフォームを作成します。

  • 複雑で包括的なスタイル

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

  • 中間のスタイル

    多くのZendesk管理者がそうであるように、メッセージングワークフローはシンプルなものと複雑なものの中間に位置する設計にしたいとお考えでしょう。ボットを使用して、メッセージングワークフローを必要な範囲で自動化することができます。「メッセージングワークフローを過度に設計しない」というゴールデンルールを覚えておいてください。

ボットによる会話の自動化を検討する

会話スタイルを選んでいるうちに、ボットや自動化を取り入れることを検討したくなるかもしれません。すべての計画を始める前に、メッセージング会話の次の3つの基本的な要素を理解することが重要です。
  • メッセージ:カスタマーサポート組織のエージェントまたは自動ボットと、カスタマーとの最初の対話です。
  • セルフサービスオプション:簡単なチケットを減らすための次のステップとして使用できます。エージェントはより複雑なリクエストに集中するキャパシティを確保することができます。
  • 会話のワークフロー:エージェントまたはボットとカスタマーとのやりとり、ボットがライブエージェントに会話を渡す方法とタイミング、およびチケットが解決されるまでの経路が含まれます。

これらの各コンポーネントは自動化することができるので、構成を決める際には、実現したい会話スタイルとメッセージングワークフローの目標を思い出してください。次に、これらの各コンポーネントの構成オプションを検討します。

メッセージ

メッセージはメッセージング会話のトーンを設定します。Webまたはモバイル用のメッセージングウィジェットを設定すると、標準のメッセージング応答がアクティブになります。この標準の応答には、カスタマーがウィジェットを起動したときに表示される基本のあいさつのメッセージと、エージェントに接続中である旨を知らせるメッセージが含まれます。

標準のメッセージは、ニーズに合わせて変更することができます。同様に、ソーシャルメッセージに届いた新しいカスタマーリクエストへの自動応答も設定できます。

カスタマーとの最初の対話を設計する際には、次の点を考慮してください。
  • どのような第一印象を与えたいか。カジュアルでフレンドリーな印象か、それともフォーマルでプロフェッショナルな印象か?
  • カスタマーに真っ先に伝えたい情報は何か。自動メッセージを使用して、提供するサービス、エージェントの空き状況、待機時間の予測について、カスタマーに見通しや期待値を知らせます。
  • カスタマーへの最初のメッセージをどの程度パーソナライズなものにしたいか?

セルフサービス

セルフサービスによるチケットの削減は、時間の節約とカスタマーの問題の迅速な解決に寄与し、カスタマーとエージェントの両方に利益をもたらします。メッセージングワークフロー内で自動セルフサービスオプションを実装するには、さまざまな方法があります。通常は、セルフサービスオプションは会話の冒頭に提示されますが、会話の途中など別の場面に導入しても役に立ちます。
  • ヘルプセンター記事を提案する。標準のオートリプライボットは、メールやWebフォームを通じて届いたカスタマーからの新規リクエストの主要な概念を評価し、ヘルプセンター内の関連コンテンツを特定して、カスタマーが問題を解決するために必要な情報が含まれている可能性が最も高い記事へのリンクを、カスタマーリクエストに自動返信します。
  • よくある質問に対してプリセットの回答を提供する。よくある質問を特定し、それに対する回答を自動化することで、カスタマーに即座に回答を提供できます。
  • 外部ソースからのデータを会話に取り込む。APIコールを使用して、カスタマーリクエストに応じてサードパーティのデータを自動的に取り込むことができます。これは、頻繁に更新される情報や個人向けの情報をカスタマーが必要とする場合に特に役立ちます。
  • 質問が解決したかどうかを尋ねる。上記のセルフサービスオプションを1つ以上提供した後で、セルフサービスオプションによって問題が解決したかどうかをカスタマーに確認することもできます。これにより、チケットをエージェントに転送することなくチケットを終了させることができます。

会話のワークフロー

メッセージングワークフローやボットの複雑さに関係なく、カスタマーサポートリクエストの中には、ライブエージェントへ転送しなければならないものがあります。メッセージングを構成する場合、自動化の度合いに関係なく、エージェントへの転送がいつどのように発生するかを検討し、転送後の会話の管理方法のルールを確立する必要があります。

ボットと自動化の設計

メッセージングワークフローに会話ボットを組み込む場合は、ボットの実装を開始する前に、時間をかけてボットのフローをマッピングしてください。段階的なアプローチを採用する場合、複数のバージョンを作成するのではなく、1つのバージョンを一度に実装する方が簡単です。

このプランの作成にはプロセスマッピングを使用することをおすすめしますが、役に立つと思われるツールなら何でも使用してかまいません。重要なのは、カスタマーが会話ボットとやりとりする際に取ることができる各アクションを視覚的に表現し、それらのアクションがどこに向かうか、そして何よりも重要なのは、これらのアクションに、アクションを実行可能にするボットのステップタイプ、機能、またはメッセージング機能をラベルとして付けることです。

プランを作成したら、後から参照できるように保存しておきましょう。

ボットからエージェントへの引き継ぎを検討する

エージェントへの引き継ぎは、会話が転送されることをカスタマーに知らせるシンプルなメッセージで始まり、その後、会話をエージェントのキューに追加することにより実行されます。引き継ぎ処理には、必要に応じて以下のいずれかを組み込むことができます。
  • フォーム:問題を解決するためにエージェントが必要とする追加情報をカスタマーから収集します。
  • 予想待機時間:カスタマーの期待値を適切に設定します。
  • 通知オプション:エージェントが対応できるようになったときに、どのような手段で連絡を受けたいかカスタマーに選択肢を提供します。

エージェントへの会話のルーティングと解決方法の決定

また、ボットがエージェントに会話を引き継いだ後に会話がどのように処理されるかについても計画する必要があります。たとえば、以下のシナリオを検討してみましょう。
  • エージェントはどのようにしてメッセージの会話を受け取るか?グループやエージェントに割り当てられているのか(プッシュモデル)、それともエージェントがビューから自分でピックアップする必要があるのか(プルモデル)。計算パターンは、次のオプションから選択することができます。
    • オムニチャネルルーティング:Zendeskの最も洗練されたルーティングロジックと、エージェントの空き状況とキャパシティに基づいて複数のチャネルからチケットをルーティングする機能を提供します。Professionalプラン以上では、スキルと優先度に基づいてチケットをルーティングすることもできます。メッセージングチケット用のオムニチャネルルーティングは、設定しなくても機能します。
    • 一斉送信:関連するすべての会話について、すべてのエージェントに通知を一斉送信します。エージェントは「リクエストに応対」をクリックして、メッセージの処理を開始できます。
    • 担当割り当て済みルーティング:オンラインエージェント間にメッセージング会話を均等に振り分けます。各受信メッセージに対して通知されるエージェントは、常に1人だけです。
  • エージェントが会話に入ったとき、カスタマーにどのように通知するか?
  • メッセージングによる会話によって生成されたチケットをどのように管理するか?

次のステップ

メッセージングの導入ガイドを参照する。シリーズの次の記事は、「メッセージングに必要な人員と運用要件の計画」で、会話型メッセージングに必要な人員を検討するのに役立ちます。

Powered by Zendesk