I work on a small team that uses both on-premise and cloud solutions, and we often receive tickets that simply ask for access or tasks to be done after hours. The challenge is that there's usually no system owner, approver, or designated time frame, leading to confusion and incidents as tickets bounce between teams. What I'm looking for is advice on process improvements rather than specific tools or vendors. For those who have managed to tighten this up, what essential fields do you include before starting on a ticket (like owner, approver, access requirements, urgency, etc.)? Also, what key factor drives most of your required fields, such as on-call staffing or maintenance windows? Lastly, how do you measure success? Are there fewer clarification comments, quicker triage times, or a reduction in SLA misses?
3 Answers
It’s crucial to define ownership for every system or application. You could set up your ticketing system so that it automatically routes tickets to the appropriate team or provides a knowledge base where this information is accessible. Having a 'Not in the list' category could help ensure that someone with the authority finds out who the responsible person is and adds that to your system whenever something new comes up.
Often, the problems in ticketing processes arise because they’re designed by people disconnected from the actual task of creating or resolving tickets. It helps to create templates from your top ticket issues, allowing users to select and fill in minimal details, which streamlines the process. Understanding the different types of requests—service requests, incidents, and change requests—can help in designing these templates more effectively.
Totally agree! How do you see the reports and statistics helping the team members who are actually tackling these issues? Is it more about management insights, or do they contribute to practical changes for the workers?
Resolving the ownership issue is key. Every application should automatically link to a dedicated team so that users don’t have to hunt down who’s responsible. If it’s production, that team should have a connection to an on-call system. All access should ideally be limited to service owners to prevent issues stemming from organizational processes. Also, categorizing severity can be huge—having tiers like a major incident versus a minor one helps prioritize tickets effectively.
For teams without enough personnel for on-call duty, is it effective to have high-severity cases routed to a manager instead? What’s your take on this?
That’s a solid approach! Who typically manages the knowledge base, and how long does it usually take to set one up from scratch?