## Ticket Lifecycle {width=864 height=316} ## A short origin story From the beginning, this team has been defined by its ability to untangle hard problems. That shows up most clearly in how we diagnose and resolve tickets, and it’s where a lot of our identity still lives. {width=900 height=503} When we were smaller and moving fast, it made sense that the middle of the ticket journey got most of our attention. Logging, routing, and closure existed, but they were lightweight – the real pride was in the deep technical work once a ticket was in your hands. As the team grew, we added structure. {width=900 height=503} Better routing. Preferred regions. Stronger closure habits. Real progress. But our language – “hard ticket”, “great work” – still mostly pointed to the middle box. That’s the gap the **lifecycle map** closes. {width=900 height=503} It doesn’t ask you to care less about Diagnosis and Resolution. It gives clear names and equal weight to the phases around them, and treats knowledge as something that runs through the entire journey – from how a ticket is logged to how it’s closed. Wherever you joined this story – early queue days or our more structured present – the goal is the same: a simple, shared lifecycle language that makes excellent work visible in every phase, not just the middle. ## What is the Support Ticket Lifecycle? The Support Ticket Lifecycle is our shared language for talking about the work we do on support tickets from the moment a customer reaches out until we’ve closed the loop. It’s not a new process to memorize or a checklist to follow perfectly. It’s a map of the work we already do, so that: - We can talk about tickets in the same way (in 1:1s, feedback, SWIR, issues). - We can see where we’re strong and where we’re struggling. - We can improve specific parts of the journey without scope creep. - We can connect our day-to-day work to knowledge creation (KCS) and continuous improvement. Every support ticket can be understood through six phases — and the knowledge practices (KCS) that run through them : - ~"TL: Logging" **Logging** – Capturing the request and its context. - ~"TL: Triage/Routing" **Triage/Routing** – Getting the ticket to the right place with the right priority. - ~"TL: Authorization" **Authorization** (when needed) – Getting the approvals or verifications we need before we act. - ~"TL: Diagnosis" **Diagnosis** – Understanding what’s actually happening and why. - ~"TL: Resolution" **Resolution** – Delivering a solution or best-available workaround and confirming it works. - ~"TL: Closure" **Closure** – Wrapping up the ticket with clear communication and high-quality data. - ~"TL: KCS" **Knowledge practices (Knowledge-Centered Service)** sit underneath and around all of these phases. Every phase both uses our shared knowledge and adds back to it. ~"TL: Map" Tickets don’t always move through these in a straight line, and some phases may be very small or effectively skipped for simple cases, and KCS opportunities exist through in all phases. 📖 Handbook reference: [Support Ticket Lifecycle workflow ](https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/19238/diffs)(draft MR) ### What this gives us The lifecycle gives us: - A **shared map** of ticket work from first contact to closure. - **Common language** we can use in 1:1s, reviews, SWIR, onboarding, and issues. - A way to spot where we’re **strong** and where a specific phase could use more support. - A clearer link between everyday ticket work and **KCS / continuous improvement**. It doesn’t come with a new set of rules to follow. We’re not changing how we work tickets today; we’re using this lifecycle as a **shared lens** and **language** we can reach for when we talk about ticket work and where it can get even better. ## Why this helps Our default instinct is to do excellent work in **Diagnosis and Resolution**, and customers feel that in the quality of our technical help. Customers also benefit from the whole journey, not just the moments when we’re actively debugging: - How easy it is to log a ticket, be understood, and know what will happen next. - How quickly their request reaches someone who can actually help. - How safe and thoughtful we are when we handle sensitive data or high-risk actions. - How clearly we close the loop and whether the outcome makes sense. There’s also value in what customers don’t see directly: - When we log and triage well, we can give Product and Engineering clear, timely signal about what’s hurting customers. - When we close consistently, we create data that makes it easier to spot trends and drive roadmap, UX, and docs improvements. - When we treat knowledge as part of every phase, future customers get better self-service and smoother digital experiences before they ever need to open a ticket. Having a shared lifecycle language helps us: - Make early and late phases (Logging, Triage, Closure) as intentional as the middle. - Talk about tickets in a way that’s more precise than “good/bad” (for example, “Diagnosis was strong; Closure needs work.”). - Decide where to invest when we change workflows, tools, or training. - Turn today’s tickets into tomorrow’s better product, better docs, and better experiences through KCS and continuous improvement, instead of relying on one-off heroics. ## How to get started (one small ask and 2 optional extras) After you’ve read this issue and the handbook page: :seedling: React React to this issue with :seedling: once you’ve read the lifecycle overview. 🧠 Optional: a quick mental check Think of one ticket you’ve worked on recently and ask yourself: - Which phase were we strongest in for that ticket? - Which phase could have made things smoother if we’d done it better (for example, Logging, Triage, Closure, KCS practices (before or after!))? Please consider sharing your observations here in the issue and seed a conversation. :sparkles: Wanna do more? Here's a [list of suggested mini-projects](https://gitlab.com/gitlab-com/support/support-team-meta/-/work_items/7590)! (And here's an [example](https://gitlab.com/gitlab-com/support/support-team-meta/-/work_items/7588)!). You can use the new [mini-project template](https://gitlab.com/gitlab-com/support/support-team-meta/-/blob/master/.gitlab/issue_templates/mini_project.md) to create an issue for any small bits of work you're doing and indicate which phases of the lifecycle it impacts. ## What's next From here, the main ask is that we **keep the lifecycle in our shared awareness**: - When we talk about tickets in 1:1s, reviews, or team forums, we can use this language: “This is mostly a Triage problem”, “Diagnosis was strong; Closure needs work”, “There’s a KCS opportunity here.” - When we look at workflows or processes, we can call out **which phases** they touch and what “better” would look like there. - When we spot friction in our day-to-day work, we can frame it in lifecycle terms so it’s easier to connect to training, tooling, or documentation changes. I’ve created an [issue](https://gitlab.com/gitlab-com/support/support-team-meta/-/work_items/7590) with a **suggested list of small lifecycle-aligned mini-projects** (for example, Logging/portal tweaks, triage and ticket weight habits, closure examples, KCS improvements) that people can pick up over time. That issue will be a good place to add your own ideas, links to example tickets, and any follow-on work you think would make this map even more useful. ## Feedback Feedback is ALWAYS welcomed! You can share it here, or DM me if you prefer, or chat with your manager.