チケットへの応答方法
チケットへの応答方法
賢い人間が賢いサポートを提供する
私たちは賢い人々を採用し、その賢さを発揮してもらうことを目指しています。これは、役立つ理にかなったガイドラインを提供しようとする一方で、「スクリプト」や硬直性を避けることを意味します。カンファレンスで同僚に話すように、あなた自身の自然な声で話してください。当然、プロフェッショナルでない言葉遣いは避けますが、顧客のトーンに合わせたいものです。全員がロボットのようなトーンで話すことで「統一」したいという欲求がしばしばあります。
「サポートにお問い合わせいただきありがとうございます。この件についてお手伝いできます。パスワードのリセットに関するヘルプをお求めのようですね…」
これは私たちを非人間化し、私たちの最良の資産である人間によるサポートを失わせます。あなたがより自然に話すと、私たちもまた本物の人間であり、「サービスとしてのサポートマインド」ではないことを印象づけます。
「ああ、パスワードを紛失されたとのこと、お気の毒です。パスワードのリセットを行いましたので、もう問題なくお使いいただけます。今後は、こちらのリンクをご利用いただけます。
他にお手伝いできることがあればお知らせください。」
私たちは缶詰工場ではない（しかし、時には缶詰を使う）
GitLab では、応答の要素を慎重に検討します。定型応答を使いたくなったり、同じことを繰り返し言っていることに気づいたりした場合、それはおそらく私たちのプロセスを改善する機会です。つまり、ログを求めるテキストエキスパンダーを作成する代わりに、一歩下がってみましょう。サポートチケットを開く体験のもっと前の段階で、繰り返しのテキストの必要性を減らすためにできることがあるでしょうか。フォーマルな言葉遣いや定型応答が適切な場合もありますが、それはまれです。可能な限り、私たちは共感と人間味を推し進め、プロセスを自動化して事前に準備します。
次のスペクトラムを考えてみてください。
graph LR
A[Pure Process] ---|Request Requires| B[Higher Level Thinking]
C[Robotic Support] ---|Tone Is| D[Voice-Empathy and Humanity]権限を与えられてください。GitLab Support では、エージェント（代行者）ではなく、主体性を持つ人間を求めています。何かが壊れているように感じたら、尋ねてください。何かが非効率に感じたら、修正してください。誰もが貢献できる、そしてすべきなのです。
サンドイッチ法
実際にチケットに答えるとなると、サンドイッチメソッドは応答を高めるのに役立つ素晴らしい 3 つのガイドラインです。優れた顧客への返信には、以下の 3 つが含まれます。
- 相手から必要としているもの。
- 求めた項目がなぜ役立つかについてのあなたの考えを説明する前提または仮説の提示。
- 引き続き支援する旨の申し出。
たとえば、顧客が次のように尋ねるかもしれません。
「私の GitLab サーバーが遅くなっているようです。お手伝いいただけますか?」
まあまあの応答はこうです。
「本番ログをお送りいただければ、それを使ってさらにトラブルシューティングできます。」
私たちは必要なものを求め、お手伝いできることがわかります。サンドイッチメソッドを使って、これを素晴らしいものにしましょう。
「問題を切り分けるために、遅延中のログをできるだけ多く取得できると助かります。ログは /var/log/gitlab にあります（これが私たちの依頼です）
通常、遅延が見られる場合、それはアプリケーションの特定の部分に限定されています。どのようなときに遅くなるかを概説して、問題の絞り込みを手伝っていただけますか?（これは、私たちの専門性を補強してもらうための前提です。）
これらをお送りいただき、どのように遅い状態に至るかを理解できれば、喜んでさらに詳しく調べるお手伝いをします。」（これは私たちが支援する旨の安心を伝えるものです。）
私たちは必要なものを早い段階で求めました。依頼を早く強調することで、相手はそれについて考え始められますし、そこで読むのをやめてしまっても依頼を見逃すことはありません。私たちは、相手が咀嚼して私たちの視点を理解できる仮説を提示しました。私たちは顧客にサービスを提供するのではなく、顧客とパートナーになることを望んでいます。これは、相手が私たちを「サービスとしてのサポートマインド」ではなく対等な存在として見てもらう 1 つの方法です。
そして私たちは、私たちはまだここにいること、そして相手が戻ってきたときもここにいることを必ず伝えます。
もっと付け加えたり、何かについて謝罪したりする必要がある場合もありますが、このメソッドは大多数のチケットに適用でき、卓越性を提供するのに役立つはずです。
2 つの操作モード: 特性化モードと仮説テストモード
チケットへの取り組みは、2 つの操作モード、すなわち特性化モード（CM）と仮説テストモード（HT）を交互に行うものと考えることができます。
特性化モードでは、ユーザーが何をしようとしているのか、実際に何が起こっているのか、関連する可能性のあるコンテキストや状態に関する情報について、基本的な事実を確立する作業を行います。チケットをパズルとして捉えるのは有用なメタファーであり、その矛盾点を詳しく解明しようとします。これはまた、再現手順や潜在的なバグレポートのベースラインとしても役立ちます。
ユーザーの問題を特徴づける作業をしていることは、透明性を持って示すことができます。この操作モードにある場合、以下を尋ねることができます。
- ユーザーが何をしようとしているのか
- なぜユーザーがそれをしようとしているのか
- システムが実際にどのように振る舞っているのか
- システムがどのように振る舞うべきだとユーザーが考えているのか
- 私たちが目にしている振る舞いに影響を与えている可能性のある状態とコンテキストの情報
2 つ目の操作モードは仮説テストモードです。これは創造的なステップであり、科学者のように振る舞い、ユーザー側で何が起こっている可能性があるかを理論立てることができます。
仮説テストモードにあることも、透明性を持って示すことができます。その際、以下を明確にできます。
- 仮説が何であるか
- それがどのように振る舞いを説明するか
- それが既に確立された他の事実をどのように説明するか
- それがどのように一部の事実を説明しないか
- それをどのようにテストできるか
- そのテストにリスクが伴うかどうか
興味深いことに、仮説テストは特性化モードにフィードバックされます。テストによってユーザーのシナリオに関する新しい事実を確立するためです。
1 つの応答の中で複数の理論とそれに対応するテストを思いつくことができます。実際、そうすることで、上記の操作モードの構造を明示的にするのに役立つかもしれません。特性化ステップで確立された事実は、すべての理論に共通です。ただし、1 つの理論で説明される可能性は他の理論には当てはまらない場合があるため、それらを別々に保つことが重要です。
このアイデアは Jeff Anderson の講演 から得たものです。
チケット偏向によるカスタマーエクスペリエンスの改善
「チケットディフレクション」は、作業をうまく回避する方法のように聞こえるかもしれませんが、実際には顧客体験の向上に関するものです。 顧客はサポートに連絡したいわけではありません。そもそも問題を抱えたくないのです。 それが叶わなければ、自分で問題を解決したいと思います。それもできなければ、そのとき初めて、技術的に熟練した個人に問題解決を手伝ってほしいと思うのです。
チケットディフレクションには 4 つの主要なツールがあります。
- 優れたプロダクト
- サポートステートメント
- ドキュメント
- 技術的卓越性
要するに、すべてのチケットの最後には、ドキュメント、Issue、マージリクエスト、またはサポートステートメントへのリンクがあるべきです。
優れた製品
優れたプロダクトを持つことは、ディフレクションの第一の防衛線です。欠陥がなく、期待どおりに動作するプロダクトは、サポートケースの数を自然に減らします。
サポートは、ユーザーが GitLab を使用中に遭遇する問題を以下によって表面化させる重要な役割を果たします。
サポートステートメント
サポートステートメント は、サポートがカバーする領域と、カバーを約束できない領域を記載しています。これは、顧客に期待事項を設定するためのツールであると同時に、サポートチームが私たちの専門領域をサポートしていることを確認するのに役立ちます。その背景にある哲学については、サポートステートメントを紹介したブログ記事で詳しく読むことができます。
GitLab のサポートチームの一員として、あなたは以下であるべきです。
- サポートステートメントの内容に精通している
- 何かが範囲外である場合に顧客に説明することに抵抗がない
- 意図的に範囲外に出ているときにそれを認識し、「ご厚意として」行っていることを顧客に明確に伝えることを意識している
それは範囲内ですか?
Greg の razor（剃刀） は、何がサポートの範囲内かを判断するのに役立つシンプルな問いです。
それはドキュメントに載っていますか?
載っていれば、私たちはそれをサポートします。
ドキュメントに載っていない場合、顧客が本番環境でそれを使用する前の最初のステップは、それをドキュメントに載せることであるべきです。
ドキュメント
回答に docs-first のアプローチを取ることで、ドキュメントが非常に役立つ信頼できる唯一の情報源であり続けることを保証できます。実世界の問題に基づくドキュメントの集積を構築することで、GitLab 顧客がキューに入る前に必要な答えや解決策を見つけられるよう支援します。私たちの ナレッジベース は成長し、活況を呈しています。現在 300 を超えるナレッジ記事が公開され、一貫して高い閲覧数を維持しており、ドキュメント努力の実際の影響が見られています。これらの記事は、顧客とチームメンバーの双方にとって頼りになるリソースになりつつあります。
常にドキュメントまたは関連するナレッジ記事へのリンクを添えて応答してください。ドキュメントのコンテンツが欠けている場合は、それを作成し、顧客に MR へのリンクを提供してください。ナレッジ記事が一般的な質問に対応できる場合は、それを作成してください。SLA 違反が迫っているチケットに取り組んでいる場合は、応答によって違反を回避し、その後 MR またはナレッジ記事でフォローアップしてください。覚えておいてください: 急がば回れ。
技術的卓越性
顧客体験を向上させる最良の方法は、私たちのプロダクトについて知識を深めることです。 あなたは、自分の強みを伸ばす、または知識を広げる意図的な学習計画を策定するために、マネージャーと連携すべきです。 また、自由に質問し、他者とペアリングし、他者が後に続きたくなるような弱さを見せる姿勢を示すべきです。
何を学んだとしても、それを絶えず湧き上がらせて広めるようにしてください。
- 学習時: ドキュメントを（再）執筆し、ナレッジ記事を作成する
- トラブルシューティング時: ドキュメントや既存のナレッジ記事を使用する
- 何かが欠けている場合: ドキュメントを更新し、ナレッジ記事を執筆または修正する
- パターンを見つけた場合: 他者が恩恵を受けられるよう、それをナレッジ記事として文書化する
メリット: ドキュメントに加えてナレッジを追加することで、ドキュメントとナレッジの両方が GitLab の重要な成功要因であることへの認識を高めます。
サポートポータルでのドキュメントとハンドブックリンクのハイライト
時には、サポートポータルページで GitLab のドキュメントやハンドブックの記事を強調したい場合があります。私たちには、Zendesk でリダイレクト記事を作成し、特定のキーワードをこのリンクに関連付ける（同時に関連するドキュメントやハンドブックのリンクを指す）機能があります。サポートチケットの作成中、チケットの件名に上記のキーワードが使用されていると、この記事がポップアップ表示され、顧客がサポートチケットを送信する前に質問への答えを見ることができます。
現在、記事とリダイレクトのリストをキュレーションしているため、記事（のリスト）をイテレーションするには Support-Ops またはマネージャーに連絡する必要があります。
自分の間違いを率直に共有し、それから学ぶ
私たちは皆人間であり、顧客とのやり取りが 100% 正確であるよう努めている一方で、実際には時々間違いを犯すものです。たとえば、顧客に誤ったアドバイスを提供してしまった場合や、後で指摘されるまでチケットの特定の側面に気づいていなかった場合、これはストレスや不安を生む状況を作り出すことがあります。
状況がどうであれ、間違いを犯したら、それを自分のものとして引き受け、そこから学んでください。私たちの透明性のバリューを思い出してください。 目の前の状況は望ましくないかもしれませんが、状況を解決すると、それは非常に力を与えてくれるものになり得ます。状況をどう解決すればよいか分からない場合は、遠慮なく助けを求めてください。誰もが支援するためにここにいます。顧客にフォローアップする際は、誠実に、間違いを犯したことを説明し、正しい情報を提供してください。
状況が解決したら、自分の行動と、次回その状況の再発を緩和するためにできることを振り返る時間を取ってください。
それがより広いサポートチームが学べることだと感じたら、地域のサポートチームミーティングや Support Week in Review (SWIR) であなたの経験を共有してください。 適切な場合は、私たちのサポートドキュメントへのマージリクエストも忘れずに行ってください。 あなたの経験を共有することで、他者はあなたの状況にどう対処したかについて他の方法を提供して貢献でき、また彼らに認識をもたらすため、彼ら自身が同じ間違いを繰り返す可能性が低くなります。
bfd74782)