サポートで最も高くつくひと言
「スクリーンショットを送っていただき、お使いのブラウザを教えていただけますか？」丁寧で筋の通った質問ですが、2 分で直るバグに 3 日かかる原因でもあります。顧客は忙しいので、返事は翌日です。スクリーンショットにはエラーメッセージは写っていても、その原因になったクリックは写っていません。スマートフォンで確認したので、ブラウザのバージョンも違います。エンジニアリングがチケットを見るころには、顧客本人も含めて、何が起きたのかを正確に覚えている人はいません。
解決策は、よりよいバグ報告フォームではありません。問題が起きたその瞬間に自分で取得できたはずの証拠を、顧客に求めるのをやめることです。
役に立つバグ報告に本当に必要なもの
エンジニアがバグを再現するには、5 つの情報が必要です。
- 顧客がしたこと：クリックと入力を順番どおりに。
- 顧客が期待したこと：たどり着こうとしていた結果。
- 実際に起きたこと：エラー、真っ白な画面、押しても反応しないボタン。
- 環境：ページ、ブラウザ、デバイス、画面サイズ、流入元。
- 技術的な痕跡：コンソールエラーと失敗したネットワークリクエスト。
顧客が確実に伝えられるのは、2 つ目と 3 つ目の一部だけです。残りの 3 つは、まさにセッションリプレイが記録するもの、つまり操作の順序、ページとブラウザ、コンソールログ、ネットワーク呼び出しです。それを記憶から再構成してもらうのは、相手が最も答えにくい部分を求めることにほかなりません。
セッションは頼むのではなく添付する
いちばん簡単な出発点は、報告そのものです。顧客がアプリ内のフィードバックウィジェットやバグ報告フォームを送信するとき、セッションはすぐそこにあります。いま開いているページ、直前に発生したエラー、1 秒前に失敗したリクエストです。報告と一緒にセッションを取得すれば、チケットはエンジニアリングに必要な情報をすでに備えた状態で届きます。
それだけで最初の返信が変わります。「スクリーンショットを送っていただけますか？」の代わりに、担当者はリプレイを開き、顧客がもう一度「支払う」を押す 2 秒前にコンソールに出ていた TypeError を確認し、同じ時間のうちに「原因がわかりました。回避策はこちらです」と返信できます。
メールはもっと難しくなります。メールにはセッションが添付されていないからです。役に立つ習慣が 2 つあります。分析ツールでログイン済みユーザーを識別し、既知のアドレスからのチケットをその人の最近のセッションと照合できるようにすること。そしてプロダクト内にフィードバックへのリンクを置き、次の報告が 1 日後の受信箱からではなく、問題が起きているページから届くようにすることです。
チケットではなくバグ単位で振り分ける
チケットにエラーが含まれていれば、エラーごとにまとめられます。多くのチームにとって最大の効果が出るのはここです。決済のバグはチケットを 1 件ではなく 30 件生み、その書き方はばらばらです。「支払いに失敗した」「購入できない」「ボタンが壊れている」。1 件ずつ読むと 30 個の問題に見えます。共通のエラーメッセージでまとめれば、影響を受けた顧客が 30 人いる 1 つのバグになり、その数字こそが優先度を引き上げます。
まとめることで、対応の締めくくり方も変わります。バグを Linear、GitHub、Jira の課題として一度だけエスカレーションし、該当するチケットをすべてそこに紐づけます。修正がリリースされたら、改めて連絡してきた 5 人だけでなく、影響を受けたすべての顧客に知らせることができます。
これがうまく機能するには、まとめ方がエンジニアリングの見ているものと一致している必要があります。サポートが「決済の問題」を数え、エンジニアリングが Cannot read properties of undefined (reading 'total') を数えていたら、2 つのリストは永遠に噛み合いません。エラートラッキングと同じ正規化されたエラーメッセージでチケットをまとめましょう。
プライバシーは先に手を打つ
チケットにセッションを添付すると、サポート担当者は顧客の行動をより多く目にすることになります。だからこそ、まずルールを決めましょう。
- フォーム入力は既定でマスクし、パスワードや決済情報の欄は決して記録しない。
- サポートが問い合わせに紐づくセッションを確認する場合があることを、プライバシーポリシーに明記する。
- リプレイへのアクセスは、ログインできる全員ではなく、チケットを扱う人に限る。
- 同意を尊重する。分析を拒否した訪問者には、添付するセッションがあってはならない。
このようにすれば、セッションの文脈は代替手段より侵襲的ではありません。代替手段とは、顧客に画面共有を頼んだり、アカウント画面のスクリーンショットをメールで送ってもらったりすることだからです。
今週から始められるワークフロー
- アプリ内にフィードバックまたはバグ報告のウィジェットを追加する。決済、オンボーディング、設定など、問題がいちばん起きやすいページに置きます。
- 送信のたびにセッションを取得する。すべてのチケットにリプレイ、コンソールログ、失敗したリクエストが付くようにします。
- ログイン済みユーザーを識別する。既知の顧客からのメールのチケットを、その人のセッションと照合できるようにします。
- チケットをエラーごとにまとめ、上位のグループを毎週エンジニアリングと一緒に確認する。
- バグごとに一度だけエスカレーションし、修正されたら紐づくすべての顧客に返信する。
何を測るか
うまくいっているかどうかは、4 つの数字でわかります。
- セッションが添付されたバグチケットの割合。先行指標なので、まずこれを引き上げます。
- 最初の役立つ返信までの時間。追加の情報を求めない返信のことです。
- バグあたりのチケット数。これが下がれば、サポート負荷をいちばん生んでいるバグを直せているということです。
- バグチケットの再オープン率。最初の回答が正しければ下がります。
PulsePanda のヘルプデスクは、まさにこの流れを軸に作られています。フィードバックはリプレイとエラー付きのチケットになり、チケットはエラーページと同じエラー単位でまとめられ、Linear、GitHub、Jira へのエスカレーションによって、課題がクローズされたときに影響を受けたすべての顧客へ返信できます。