チケットのトリアージ: 見落としなく対応キューの優先順位を付ける方法
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
午前11時47分。あなたは午前8時55分から席に着いています。パスワードリセットを3件処理し、フリーティアのユーザーから来た長い機能リクエストのメールに返信し、ドキュメントで見つけられたはずのチェックボックスを誰かに案内しました。充実した午前中だったと思っています。
そしてキューの上部までスクロールします。
午前9時02分のチケットがあります。件名は「緊急: 本番停止、チェックアウト機能が落ちている」。顧客はエンタープライズプランのFortune-500企業です。P0のSLAは2時間。あなたは1時間45分遅れています。
これがFIFOの罠です。受付順にキューを処理しました。公平に感じられたが、代償を払う羽目になりました。マネージャーがもうすぐpingを送ってきます。アカウント担当者はすでに顧客と電話中で、サポートについて謝罪しています。最悪なのは: あなたは辛い午前中を過ごしたわけではありません。楽な午前中でした。ただ間違ったチケットに使ってしまいました。
このガイドはその問題を修正するシステムです。感覚やフィーリングではなく、「判断を使え」でもありません。あらゆるスペシャリストが初日から実行でき、シニアスペシャリストが自動的に回すことができる、繰り返し可能なトリアージの方法です。これを2週間実践すれば、SLAの達成率が上がり、1日の終わりのキューが減り、マネージャーからFortune-500のチケットがどう見落とされたのかを聞かれることがなくなります。
なぜトリアージがサポートで最も高いレバレッジを持つスキルか
ほとんどのサポートスペシャリストは自分の仕事がチケットを解決することだと思っています。違います。仕事は「正しいチケットを」「正しい順番で」解決することです。解決は簡単な部分です。順番付けが、昇進するスペシャリストと停滞するスペシャリストを分ける部分です。
数字で見てみましょう。トリアージに費やす1分は後工程の5〜10分を節約します。関係のないチケット間のコンテキストスイッチがなくなります。似た作業をまとめられます。高インパクトのチケットがエスカレーションになる前に捕捉できます。40時間の週に掛け算すれば、ほぼ1日分の時間を生み出したことになります。
認識の層もあります。マネージャーがダッシュボードを見るとき、「このスペシャリストは頑張った」とは見えません。SLA達成率、平均解決時間、滞留チケット数が見えます。トリアージはその3つすべてを動かします。解決スキルが同等の2人のスペシャリストも、一方がトリアージを上手くやり、もう一方がFIFOで動くなら、指標上でまったく違って見えます。トリアージをやる人はシニアに見えます。FIFOのスペシャリストは散漫に見えます。
トリアージは仕事の中で偽れない、隠せない唯一の部分です。1週間以内に数字に現れます。
インパクト×エフォートマトリクス
これがメンタルモデルです。すべてのチケットには2つの軸があります: どれだけ重要か(インパクト)と解決にどれだけかかるか(エフォート)。これで2×2のグリッドができます:
高インパクト、低エフォート。 これを最初にやります。解決策が明らかな本番停止チケット。既知の回避策があるログインバグ。2クリックで修正できる課金エラー。小さな行動が大きな価値を生み、顧客があなたを記憶するものです。
高インパクト、高エフォート。 これを2番目にやりますが、まず最初に確認します。10ページにわたる連携のデバッグ、エンジニアリングのインプットが必要なデータ移行、午後の半分を使うエスカレーション。重要だが、プロジェクトです。開いてスコープを把握し、顧客の期待値を設定してから、素早く解決できるチケットをクリアした後で戻ります。
低インパクト、低エフォート。 バッチ処理します。パスワードリセット、「請求書はどこにある」、「エクスポートの方法は」。それぞれが2分の作業です。1日に散らすのではなく、一つのブロックでまとめて処理します。
低インパクト、高エフォート。 差し戻すか先送りします。プロダクトのインプットが必要な機能リクエスト、「ワークフロー全体を変えたらどうなるか」という質問、スコープ外のカスタムレポートのリクエスト。確認して適切にルーティングし、午前中を食い潰させないようにします。
ほとんどのスペシャリストは、生産的に感じるという理由でインパクトに関係なく低エフォートのチケットを先に処理するデフォルトになります。それが罠です。5件のパスワードリセットは進捗のように感じられ、ダッシュボードはそのいずれも評価しません。1件のP0修正が実際に重要な仕事です。
P0〜P3: 実例付きの明確な定義
ほとんどのサポートチームはヘルプデスクツールに優先度レベルを持っていますが、定義が曖昧でスペシャリストは感覚に頼ります。感覚はシステムではありません。ここに明確なバージョンを示します。
P0: 緊急。有料顧客の本番停止。 例: チェックアウトフローの停止、完全なアプリ障害、データ損失の進行、セキュリティインシデント、顧客の組織全体でログインが完全に失敗している。SLA: 15分以内に返信、2時間以内に修正または回避策。P0はキューの他のすべてに優先します。P3を対応中にP0が届いたら、止めてP0を確認し、優先順位を再設定します。P0はオンコールエンジニアへの社内アラートもトリガーします。一人で解決しようとするべきではありません。
P1: 高。ワークフロー停止、回避策なし。 例: 重要な連携が1顧客で失敗している、重要なレポートが生成できない、有料ユーザーが今日必要な機能にアクセスできない。SLA: 1時間以内に返信、同営業日内に解決。P1はスリープしてしまうとエスカレーションになるチケットです。顧客があなたに救ってもらったか待たされたかを記憶するチケットでもあります。
P2: 中。機能は低下しているが利用可能。 例: 機能が遅いが動作している、UIの要素が壊れているがワークフローは動作している、重要でないレポートが誤ったデータを表示している、ユーザーが混乱しているが操作できている。SLA: 4時間以内に返信、1〜2営業日以内に解決。P2はキューの大半を占めます。緊急ではありませんが、実際の問題であり、1週間放置するとP1になります。
P3: 低。質問、外観、機能リクエスト。 例: 「Xはどうやってやるか」、パスワードリセット、「この機能を追加してほしい」、ドキュメントのタイポ、FAQで答えられる課金の質問。SLA: 24時間以内に返信、3〜5営業日以内に解決。P3はバッチ処理してテンプレート返信するものです。より高い優先度のチケットを絶対にブロックするべきではありません。
トリアージするとき、私は他の何もする前に優先度を割り当てます。チケット全体を読んだ後ではなく、診断した後でもなく。約15秒後に。件名、アカウントティア、キーフレーズ、直感チェック。後で判明したより深刻または軽微だとわかれば調整できますが、今すぐ対応するか後でバッチ処理するかを告げるのが優先度なので、数秒以内に作業中の優先度が必要です。
3分の初回タッチルール
すべてのチケットは開封後3分以内に、読まれ、分類され、確認されます。解決されるのではありません。「確認」されます。
理由はシンプルです。顧客のタイマーは送信した瞬間に始まります。サポートチームの体験は、合計解決時間より初回応答時間によって形作られます。P2チケットが3分で丁寧な確認を受けて1日後に解決されれば、P2が5時間の沈黙の後に1行の修正で解決された場合よりCSATが高くなります。
初回タッチのスクリプトは短いです:
[名前]さん、こんにちは。
ご連絡いただきありがとうございます。チケットを確認しました。[問題の1文要約]ということですね。現在[調査中 / エンジニアリングにエスカレーション中 / 関連ログを確認中 / アカウントを確認中]です。[時間]までに更新情報をお送りします。
[あなたの名前]
3文です。読んだことを確認し、問題を要約し(読んだ証明)、次のステップを伝え、時間を設定します。それだけです。ジュニアスペシャリストが犯す間違いは、最初の返信で解決しようとすることです。しないでください。素早く確認し、答えが出たときに解決します。
このルールには新しいスペシャリストを驚かせる副作用があります: 残りの1日が楽になります。3分以内にすべてのチケットを確認すれば、顧客は「何か進捗は？」という追い返信を送りません。あなたがコミットした時間まで待ちます。キューが余分なノイズを生成しなくなります。
バッチ処理: 誰も話さない生産性の乗数
関係のないチケット間のコンテキストスイッチは、サポートスペシャリストの1日の最大の隠れコストです。課金の質問からデバッグセッションへ、パスワードリセットへと切り替えるたびに、脳が税金を支払います。コンテキストを再ロードします。タブを再び開きます。ユーザーの経緯を再度読みます。ここで20秒、あそこで40秒。50件のチケットにわたれば、1時間分の1日です。
改善策はバッチ処理です。キューをトリアージした後、似たチケットをグループ化してまとめて処理します。
バッチ処理のPlaybook:
- パスワードリセット、アカウントアクセス、MFAリカバリー。 1ブロック、管理パネルを1タブ開いて、まとめて処理します。貼り付けてパーソナライズできるサポートスクリプトを使います。
- 課金の質問、請求書の問題、プラン変更。 1ブロック、課金システムを1タブ。ほとんどにテンプレートの答えがあります。スクリプトを活用します。
- 連携設定チケット。 1ブロック。同じドキュメント、同じエラーパターン、同じ5つの質問を共有しているからです。
- 「どうやって使うか」の質問。 1ブロック。主に正しいドキュメントを指すテンプレート返信です。
- バグとデバッグ。 1ブロック。最も深い集中が必要で、途中でパスワードリセットに割り込まれたくないからです。
バッチ処理はそれぞれのチケットタイプを速くもします。ブロックの中で3件目のパスワードリセットをやるころには、すべてのエッジケースを思い出しています。3件目の課金の質問では、ワークフローを素早くこなしています。5件目は最初の3分の1の時間で済みます。
シニアスペシャリストは本能的にバッチ処理します。ジュニアスペシャリストは上にあるチケットをやります。ダッシュボード上での違いはそれです。
トリアージを破るタイミング
トリアージはデフォルトであり、法律ではありません。いくつかのシグナルはキューの順番を上書きします:
- P0が届いた。 今やっていることを止めます。P0は常に今すぐです。
- 解約リスクの顧客がチケットにいる。 アカウントチームがその顧客をリスクありとフラグを立てていれば、優先度に関係なくチケットを前に引き出します。P2で顧客を失うことは、P3のSLAを外すことより悪いです。
- CEO、創業者、またはエグゼクティブスポンサーがフラグを立てた。 上司が顧客チケットをエスカレーションするとき、それは特別扱いをしたいからではありません。顧客が優先度フィールドでは表現できない形でビジネスにとって重要だからです。
- チケットが24時間を超えようとしている。 キューで1日フルのタッチなしに座っているものは、P3でも信用の問題です。EODまでにスイープします。
- 1時間に3件の顧客から同じ問題が報告されている。 それは3件のチケットではありません。インシデントです。止まり、チームチャンネルに書き込み、インシデント対応モードに切り替えます。
ルール: デフォルトはトリアージ、シグナルがあれば上書き。週に2〜3回以上上書きしているなら、優先度の定義がおそらく誤っており、リードと一緒に見直す価値があります。
日次トリアージチェックリスト
1日3回のキュースキャン。それぞれ10〜15分かかります。省略しないでください。
午前10時、朝のスキャン。 キューを開きます。SLA残り時間の昇順でソートします。赤または赤になりそうなもの、今すぐ対応します。前夜からのチケットが持ち込んだ新しいものを再度優先順位付けします。その日のバッチを特定してピン留めします。午前10時15分までに、その日の計画が明確になっているべきです。
午後1時、昼の再トリアージ。 昼食時間にチケットが届いています。多くの地域でP0とP1は午前中のピークに届きます。キューを再スキャンし、新しい届きものを優先度順にスロットし、午後の計画を調整します。確認したが解決していないチケットも確認するタイミングです。午後2時までに更新するとコミットしたものは動いている必要があります。
午後4時、EODスイープ。 1日の最後のスキャンで、危険なほど古くなりかけているものをすべて捕捉します。まだ開いているP0またはP1は解決が終わっていなくてもログオフ前にステータス更新を送ります。EODの沈黙がP1を一夜のエスカレーションにします。24時間を超えたものはタッチします。終わりきらないものは次のシフトスペシャリストへの明確な引き継ぎメモをつけます。
これを2週間毎日行えば、EODのキューが減り始め、SLA達成率が90%台に上がり、「チケット#Xを見たか」というDMが来なくなります。
よくある落とし穴
「FIFOが公平だから」という理由で受付順に処理する。 公平ではありません。Fortune-500の障害をフリーティアの機能リクエストと同じように扱います。サポートにおける公平性とは、提出時間ではなくインパクトに比例した対応です。
難しいチケットでのヒーローモード。 スペシャリストが魅力的なP2のデバッグに引き込まれ、3件のP0が積み上がりながら2時間を費やします。修正策はエスカレーションのPlaybookです: 1件のチケットで午前中が丸々かかる場合、エスカレーションするかスコープを縮小します。あなたのキューはポートフォリオであり、1つのプロジェクトではありません。
バッチ処理なし。 数分ごとにチケットタイプを切り替えているなら、1日中コンテキスト税を払っています。似たものは似たものでまとめてください。
SLAタイマーを無視する。 タイマーは唯一の客観的なシグナルです。あなたの感情や判断を気にしません。赤になったら返信します。赤になりそうなら優先します。タイマーを任意とみなすスペシャリストはSLAを外します。ハードな制約とみなすスペシャリストは達成します。
確認と解決を混同する。 3分でチケットを解決する必要はありません。3分以内にタッチする必要があります。完全な答えが出るまで返信できないと感じるスペシャリストが、初回応答SLAを外す人です。
ジュニアスペシャリストが陥る落とし穴のより詳しいリストは、Support Specialistによくある落とし穴を参照してください。
トリアージが機能しているかの測定
4つの数字でシステムが機能しているかを確認します:
- 優先度別SLA達成率。 P0は99%以上。P1は95%以上。P2は90%前後。P3は80%以上。P0・P1がそれらのしきい値を下回る場合、キューの上位でトリアージが壊れています。
- 優先度別の平均解決時間、前月比トレンド。 P0が下降傾向にあることが、最も重要なことで速くなっているという先行指標です。
- EODまでのキュークリア率。 何割の日に、古いチケットなしにログオフできているか？目標は80%以上。
- 滞留チケット数。 24時間以上タッチなしで放置されているチケット。この数はほぼゼロであるべきです。そうでなければEODスイープを実施していません。
どの指標が重要でどれが見せかけかの完全な解説は、重要な指標: CSAT、FRT、その先を参照してください。
マインドセットの転換
トリアージはスキルであり、フィーリングではありません。毎朝、毎昼、毎EODと同じやり方で繰り返し可能なシステムとして実践するスペシャリストは、仲間より速く前に出ます。「判断を使え」として扱うスペシャリストは、必要以上に長くジュニアに留まります。
サポートにおいてキャリアを制限する最大の習慣は、受付順にチケットを処理することです。キャリアを加速させる最大の習慣は、初日の新入社員に教えられるトリアージシステムを持つことです。2つ目を選んでください。
関連リソース
Principal Product Marketing Strategist