チケットライフサイクル
Support Ticket Lifecycle は、顧客が連絡してきた瞬間からループを閉じるまで、私たちがサポートチケットで行う作業を語るための共通言語です。
これは記憶すべき新しいプロセスでも、完璧に従うべきチェックリストでもありません。これは、私たちがすでに行っている作業の マップ です。これにより:
- 私たちはチケットについて同じように話せます（1on1、フィードバック、SWIR、Issue で）。
- 私たちは強い部分と苦戦している部分を見ることができます。
- 私たちはすべてを重くすることなく、ジャーニーの特定の部分を改善できます。
- 私たちは日々の作業を 知識創造 (KCS) と継続的改善につなげることができます。
このページは、オンボーディング、エネーブルメント、コラボレーションの会話、そして「チケットのライフサイクルを考えて」と言うときの 1on1 でリンクする 常緑のリファレンス です。
ライフサイクルの全体像
すべてのサポートチケットは6つのフェーズで理解できます:
- Logging（ログ） – リクエストとそのコンテキストを捉える。
- Triage/Routing（トリアージ／ルーティング） – 適切な優先度で適切な場所にチケットを届ける。
- Authorization（認可）（条件付き） – 行動する前に必要な承認や検証を取得する。
- Diagnosis（診断） – 実際に何が起きているか、なぜ起きているかを理解する。
- Resolution（解決） – 解決策または利用可能な最善のワークアラウンドを提供し、それが機能することを確認する。
- Closure（クローズ） – 明確なコミュニケーションと高品質なデータでチケットを締めくくる。
チケットは常に完璧な直線でこれらを進むわけではなく、シンプルなケースではいくつかのフェーズが非常に小さかったりスキップされたりすることがあります。それでかまいません。目標は 共通言語 であり、厳格なパイプラインではありません。
知識実践（Knowledge-Centered Service）は、これらのフェーズすべての下と周りに位置します。 すべてのフェーズは、共通の知識を使用し、それに貢献します。
目標状態: 共通のライフサイクル言語、チケット作業の各フェーズにおける卓越性、すべてのフェーズを可能にし進化させる知識実践。
なぜこのライフサイクルを使用するのか
私たちのデフォルトの本能は、Diagnosis と Resolution で卓越した仕事をすることです。顧客は技術的な助けを求めて私たちのところに来るからです。
しかし、顧客は ジャーニー全体 から恩恵を受けます。私たちが積極的にデバッグしている瞬間だけでなく:
- チケットを起票し、理解され、次に何が起こるかを知ることがどれほど簡単かを感じます。
- お客様のリクエストが実際に助けてくれる人にどれだけ早く届くかを感じます。
- 機密データやハイリスクな操作を扱うときに、私たちがどれほど安全で思慮深いかを感じます。
- ループをどれだけ明確に閉じるか、結果が理にかなっているかを感じます。
顧客は、顧客自身が直接見ない部分からも恩恵を受けます:
- 私たちがログとトリアージを上手く行えば、顧客に何が損害を与えているかについて、Product と Engineering に 明確でタイムリーなシグナル を提供できます。
- 一貫してクローズすると、トレンドを発見し、ロードマップ、UX、ドキュメント改善を推進しやすいデータが生まれます。
- 知識をすべてのフェーズの一部として扱うとき、将来の顧客はチケットを起票する必要が生じる前に より良いセルフサービスとよりスムーズなデジタル体験 を得ます。
ライフサイクルは私たちが次のことを行うのに役立ちます:
- 早期および後期のフェーズ（Logging、Triage、Closure）を、中盤と同じように意図的にする。
- 「良い／悪い」よりも精密に チケットについて話す。
- ワークフロー、ツール、トレーニングを変更するときに どこに 投資するかを決める。
- 一回限りの英雄的行為に頼らず、KCS と継続的改善を通じて、今日のチケットを明日の より良い製品、より良いドキュメント、より良い体験 に変える。
フェーズの詳細
以下の各フェーズの説明には次が含まれます:
- 短い定義。
- そこで何が起こるか。
- 実践における 卓越性 はどう見えるか。
Logging
目標: 顧客のリクエストの明確な初期記録と主要なメタデータを捉え、チケットが正しくルーティングされ、有意義な作業を始められるようにする。
ここで何が起こるか
- 顧客（または顧客に代わって GitLab チームメンバー）がチケットを送信する。
- 私たちはフォーム、フィールド、チケットの説明を使ってコアコンテキストを収集する。
- 最初の確認質問のラウンドを行う場合がある。
卓越性とはこういうもの
- 私たちのサポートポータルとフォームは、リクエストをログする方法を明確にしているので、顧客は適切なパス（たとえば L&R vs SaaS vs Self-Managed vs Dedicated）を簡単に選べる。
- ルーティングに必要な主要なメタデータ（環境、サブスクリプションタイプ、基本的な影響度など）は、自由テキストに隠されるのではなく、チケット作成時のフィールドを通じて捉えられる。
- GitLab チームメンバーが顧客に代わってチケットをログするときも、同じ標準に従う: 明確で具体的な件名と、ルーティングと作業を始めるのに十分な構造化されたコンテキスト。
- 私たちは新しくログされたチケットのサンプルを定期的にレビューし、フォーム、ヘルパーテキスト、選択肢を調整して、「ルーティングして作業を始められるくらい十分」がデフォルトの結果になるようにする。
Triage/Routing
目標: 各チケットがキュー内の正しい場所にあること（適切な weight、フォーム、severity、リージョンを伴って）を確認し、適切なサポートエンジニアが、開始するのに十分なコンテキストを持って、適切なタイミングで取り組めるようにする。
ここで何が起こるか
- 私たちは実際の顧客への影響に基づいて、severity と優先度を確認または調整する。
- 正しい フォーム が適用されていることを確認する。
- チケットの weight を自動的に設定し、キュー内で適切に並べる。
- 顧客の サポート希望リージョン（AMER、APAC、EMEA）を信頼し、それをキュー管理とオーナーシップで使う。
- 一部の L&R リクエストは最初に BPO に行く。必要に応じて Support Engineering キューにエスカレーションされる場合がある。
卓越性とはこういうもの
- severity と優先度は、ポータルからのデフォルト選択ではなく 実際の影響と緊急度 を反映する。
- チケットは 正しいフォーム にあり、それにより下流のフィールドとワークフローが期待通りに動作する。
- チケットの weight が設定され、適切な顧客と severity の高インパクトな作業が自然にキューの上位に近づく。
- サポート希望リージョンは可能な限り尊重され、逸脱する場合（たとえば緊急事態、リージョン間の引き継ぎ）は、理由を説明する短い内部ノートを残す。
- L&R チケットは想定されたパスに従う:
- BPO ができることを処理する。
- Support Engineering へのエスカレーションは明確で、私たちが素早く動けるだけのコンテキストがある。
- 繰り返されるトリアージの問題（たとえば、間違ったフォーム、設定ミスの severity、紛らわしいポータルオプション）が見られたら、それを永遠に黙って修正するのではなく、フォーム、ヘルパーテキスト、ワークフローの改善にフィードバックする。
Authorization（条件付き）
目標: セキュリティ、データ、契約上の義務に影響する変更を行う前に、必要な承認または検証を安全かつ正確に取得する。
ここで何が起こるか
- 機密性のある操作（たとえば 2FA リセット、アカウントまたはデータ変更）の身元と所有権を検証する。
- 必要に応じて Security、Legal、または他のステークホルダーから承認を得る。
- 必要な確認を待つ間、目に見える作業を一時停止する。
卓越性とはこういうもの
- 身元チェックと承認は、その場限りの判断ではなく、文書化されたワークフローに従う。
- 内部ノートは 何が どのポリシーの下で 承認されたかを明確に記載する。
- ここでなぜ余分な注意を払ったかが、チケット履歴から明らかになる。
- これらのワークフローの面倒または紛らわしい部分は、改善にフィードバックされる。
Diagnosis
目標: 実際に何が起きているか、なぜ起きているかを理解する。安全で効果的な推奨を行うのに十分な深さで。
ここで何が起こるか
- 顧客のゴールと制約を明確にする。
- ログ、構成、再現ステップを集める。
- 妥当な場合は再現し、runbook、KB、製品ドキュメントを参照する。
- 必要に応じて Pod、SME、他のチームと協業する。
卓越性とはこういうもの
- ノートは、何を試し、何を学び、何が考えを変えたかについて 首尾一貫したストーリー を語る。
- 毎回ゼロから始めるのではなく、既存の runbook/KB/ドキュメントを使用し更新する。
- 行き詰まったときは、「何かアイデアは？」ではなく、明確なコンテキスト で助けを求める。
- 別のエンジニアが途中からチケットを引き継いでも、次に何をすべきか分かる。
Resolution
目標: 顧客が適用できる解決策または利用可能な最善のワークアラウンドを提供し、それが顧客のニーズを満たすことを確認する。
ここで何が起こるか
- 具体的なステップ、構成変更、ワークフローを提供する。
- バグや制限事項のために製品 Issue を起票またはリンクする。
- トレードオフと、何ができて何ができないかを説明する。
卓越性とはこういうもの
- ガイダンスは テスト可能 で、修正 vs ワークアラウンド vs さらなる調査と明確にラベル付けされている。
- 結果が許容できるか（または次のステップに合意できるか）を顧客と検証する。
- 製品 Issue は明確で、リンクされていて、実際の顧客への影響を記述する。
- 残された制限を埋めるのではなく、誠実に名指しする。
Closure
目標: 顧客への明確なコミュニケーションと、将来の私たちのための高品質なデータとコンテキストを残す形でチケットを閉じる。
ここで何が起こるか
- 最終的な公開メッセージを送信する。
- 現行のガイダンスに従って closure フィールド（たとえば製品カテゴリ、解決コード、解決メモ）を埋める。
- さらなる作業が必要な場合、フォローアップチケットまたはタスクを作成する。
- 顧客にフィードバックを依頼する。
卓越性とはこういうもの
- closure フィールドは、クリックするのに最も速いものではなく、チケットがなぜ存在し、どのように 終わったかを正確に記述する。
- 解決メモ（内部）は、何ヶ月後でも意味の通る 1〜3 文。
- 最終公開メッセージは、結果と、可能な場合は次のステップを明確に述べる。
- 将来の作業が他で必要な場合（例: 製品、CSM、別の Support チケット）、それは存在しリンクされている。
知識はあらゆるところに（KCS とライフサイクル）
KCS はチケットの最後だけ、または特別な「ドキュメントタイム」だけでやることではありません。これは すべてのフェーズ に織り込まれています:
- Logging: 良い問題ステートメントと関連リンクは、将来のチケットと検索結果をより良くする。
- Triage/Routing: 正確なカテゴリとタグは、分析とドキュメントのためのより良いデータスライスを生む。
- Authorization: 何が承認されたか、なぜ承認されたかについての明確な内部ノートは、将来の機密操作のリファレンスポイントになる。
- Diagnosis: 明確な内部ノートは、ドキュメント、runbook、記事、トレーニングのソース素材としても機能する。
- Resolution: 強力な説明はしばしば KB 記事の最初のドラフトになる。
- Closure: 良い closure フィールドと要約は、文書化に値するパターンを見つけるのを可能にする。
「KCS をうまくやる」と話すとき、私たちは ライフサイクルをうまくやる ことについても話しています。すべてのチケットは 顧客のジャーニー であり データポイント でもあります。知識実践は、両方を尊重する方法です。
このページの使い方
サポートエンジニア
- チケットに取り組むときに、時々立ち止まって尋ねます:
- 「私は今どのフェーズにいる？」
- 「このチケットでこのフェーズの 卓越性 はどう見える？」
- 何かが面倒または紛らわしく感じたら、この言語を使ってみます:
- 「これはトリアージの問題です。」
- 「このチケットタイプの closure ガイダンスは不明確です。」
- 「これは良い KCS の機会になるでしょう。」
サポートマネージャーおよびリード
- フィードバックとコーチングでフェーズを使用します:
- 「あなたは Diagnosis では非常に強い。複雑な SaaS チケットの Closure 習慣を磨きましょう。」
- チケットレビューで、コメントにフェーズをラベル付けします:
[Logging]、[Triage]、[Diagnosis]など。
- 1on1 とタレントアセスメントでは、何枚チケットを閉じたかだけでなく、人々がライフサイクルを通じてどのように現れているかについて話します。
Support Readiness / Ops / Training
- ワークフロー、フォーム、トレーニングを更新するときに尋ねます:
- 「これは本当にどのフェーズについてですか？」
- 「そこで『素晴らしい』はどう見えるか、そしてそれはドキュメントで明確ですか？」
- 主要なワークフローページに軽い 「Lifecycle phases:」 インジケーター（例:
Lifecycle phases: Closure, KCS-heavy）を追加して、人々がフェーズでナビゲートしやすくすることを検討します。
このページが他のページやプロジェクトとどう繋がるか
このライフサイクルは、以下に対する レンズ であって、置き換えるものではありません:
- 既存の Support ワークフロー（チケットのトリアージ、チケット作業、緊急ワークフロー、Knowledge Base ワークフローなど）。
- closure 習慣、製品カテゴリ、解決コード に関する継続中の作業。
- 新しいサポートエンジニア向けの オンボーディングおよびトレーニング コンテンツ。
- ワークフローやツーリングを改善する Support Team Meta および Support Training プロジェクトの Issue とエピック。
Support ワークフローに関する Issue を開いたり作業したりするときは、このページを共通リファレンスとして使えます:
- どのフェーズ をターゲットにするかを名指しする。
- それらのフェーズで「より良い」がどう見えるかを記述する。
- 全員が同じマップを共有するために、ここにリンクバックする。
次に何をするか
私たちは引き続き次のことを行います:
- このライフサイクル言語を Issue、レビュー、SWIR で使う。
- このレンズを適用する「前後」のチケットを示す具体的な ケーススタディ を追加する。
- ワークフロー、トレーニング、メトリクスをイテレーション的に更新し、すべてのフェーズ での卓越性が例外ではなく通常になるようにする。
このページを改善する提案や例があれば、Support Team Meta プロジェクトでこのワークフローを参照する Issue またはマージリクエストを開いてください。
bfd74782)