複雑なチケットを、チームが学べる参考回答に変える

回答の下書きを作成する前にケースを再構成する

顧客の目的、確認済みの症状、完了した調査、過去の約束、残る不確実性を短くまとめます。顧客が報告したことと、チームが検証したことを分けます。これらが一つのもっともらしい原因説明に混ざると、複雑な問い合わせへの対応が難しくなります。

共有が許可されている匿名化されたバージョンを使用してください。完全なプライベートな会話ではなく、関連する承認済みの手順とエスカレーション ルールを含めます。 macOS では、⌘⇧K はデフォルトで Colay のオーバーレイを開きます。これは設定で変更できます。下書き用ワークスペースが表示されます。引き続きコンテキストを提供し、結果を確認します。

有用な応答を含む架空の未解決チケット

架空のレポート サービスを想像してください。大規模なエクスポートは失敗し、小規模なエクスポートは成功します。顧客はすでに大規模なエクスポートを 2 回繰り返しています。原因は解明されていない。割り当てられたスペシャリストがケースを受け入れ、チームは 16:00 UTC にアップデートすることを明示的に約束しました。これらは時間を含む、架空の入力です。これらは Colay からのサービスの約束ではありません。

適切な返信例は次のとおりです。小規模なエクスポートが機能することを確認していただきありがとうございます。 2 回の再試行後も大きなレポートがまだブロックされていることを理解しています。私たちの専門家がこの問題を調査中です。原因がまだ確認されていない場合でも、判明した内容を 16:00 UTC に更新します。すでに提供されている情報を確認している間、同じエクスポートを繰り返す必要はありません。

対照的なドラフトと注釈付きのサンプルを要求する

選択した対応可能なエージェントからの最初の回答については、Ask separatelyを使用してください。不確実性、繰り返される質問、次のアクションにどのように対処するかを比較します。 Consensus合成は代替案を整理するのに役立ちますが、最終的なテキストを文ごとにチェックできるように、ソースとなる事実を入手できるようにしてください。

この匿名化した問い合わせから、レビュー用の回答候補を作成してください：[目的、確認済み事実、報告された事実、完了した調査、過去の約束、不明点]。承認済み手順と引き継ぎ規則：[出典]。まず回答を変え得る不足情報を挙げてください。原因や解決策を作らず、簡潔な案と説明を加えた案を作成してください。重要な各文の根拠となる事実を説明してください。推奨する顧客向け返信、社内レビュー用メモ、別の担当者が再利用できる条件を返してください。社内メモを顧客向け文章に含めず、責任者の確認が必要な約束を明示してください。

事実とサービス行動に関する見本を承認する

既存のチケットからマクロを作成するための Zendesk の手順では、再利用できるようにコメントを調整することが推奨されています。そのアイデアを参照回答に明示的に適用します。どの詳細が元のケースに属し、どの推論が移行するかを示します。未解決のケースは、解決済みの問題として提示されなくても、有用な暫定対応を教えることができます。

1. サポートの責任者に、すべての事実記述と約束を、実際の問い合わせと規則に照らして確認してもらいます。
2. 回答がお客様の実際の目標に沿っているかどうかを確認します。技術的な説明が長くても、次に何が起こるかを説明できない場合があります。
3. 社内の仮定、個人データ、サポートされていない診断が顧客向けの文章に含まれていないことを確認します。
4. 承認された回答を、匿名化されたケース、注釈、所有者、バージョン、条件とともに再利用できるように既存のチーム ライブラリに保存します。

完璧な段落をコピーするのではなく、適応を教える

同僚に、条件が少し違う問い合わせへ回答例を適用してもらいます。専門担当がまだ引き受けていない、実施済みの確認が違う、更新時刻が承認されていない、といった違いです。どの文を変える必要があるか説明できるはずです。できなければ、文章をさらに整えるより、適用条件を明確にします。

サンプルのステータスを正直に保ちます。これは、基礎となるチケットがオープンなままである間に承認された暫定応答である可能性があります。調査によって事実が変更された場合は、回答例とその注釈を更新します。再利用可能な価値は、すべての顧客が同じ自信を持った回答を受け取ることではなく、別のケースに移行する推論にあります。

質問と回答