On average, organisations have 205 ticket types in the service desk and use just 34.
Poor ticket categorisation leads to confusion in the team, inefficient ticket handling, crappy reports and an increased cost per ticket.
I’m certified at the ITIL expert level. Having spent more than 30 years working and consulting in the IT Service Management sector, I have seen what works and what doesn’t.
This article will help you;
- Define your categories & subcategories.
- Capture the right information the first time.
- Identify 20 best practices to avoid painful mistakes and dead ends.
Table of Contents
What are the different ITIL ticket types?
The ITIL ticket types in an Information Technology Infrastructure Library (ITIL) framework are;
- Incident Tickets: These are for unplanned interruptions and to restore regular service operations as part of Incident Management.
- Service Request Tickets: For service requests, information, or access as part of Request Management.
- Problem Tickets: For underlying causes of one or more incidents as part of the Problem Management process.
- Change Request Tickets: This is for formal proposals for IT service alterations as part of the change management process.
All can be managed through an IT Service Management (ITSM) ticketing system.
Incident tickets
So, this is usually the big one: the service desk ticket, where you want super efficient service delivery and explore the data in various reports for trend analysis, etc.
The ITIL Incident Management process tickets will likely be the backbone for the other types of tickets. For example, categories here will likely influence categories in the Problem Management process.
The Incident Ticket Process
What Categories of Incident Tickets Should I Have?
When considering the categories of incident tickets, start with these;
Category | Sub-Category |
---|---|
Hardware | Desktops and Laptops Printers and Scanners Mobile DevicesServers Network Equipment (Routers, Switches) Peripherals (Keyboards, Mice) |
Software | Operating Systems Applications (Office, CRM, ERP) Email and Communication Tools Databases Development Tools |
Network | Connectivity Issues VPN Problems Slow Internet/Network Performance Wi-Fi Access DNS Issues |
Security | Virus and Malware Unauthorised Access Data Breach Phishing Attempts Encryption Issues |
Access | Password Resets Account Lockouts Permission Issues User Account Setup/Deletion |
Services | Email Service Disruption Cloud Service Issues Collaboration Tools Downtime Printing Services Backup and Recovery Failures |
Are they going to work for everyone? No, but at least with this, you aren’t starting by looking at a blank screen.
Keep the categories to no more than two levels, as tempting as it may be to start having sub-sub and sub-sub-sub-sub categories. Keep it so that it makes intuitive sense for people to use.
You’ll also likely have some bespoke systems you’ll want to track. For example, I worked at a mortgage company and ran their service desk for several years. We had in-house systems and modules within those systems. So, I’d add those in, but only to that level.
What Data Should I Record in my Incident Tickets?
Here’s a suggestion, but keep it as simple as possible. Where possible, try to use the system ‘out-of-the-box’. Any major ITSM supplier will have configured their solution carefully, so if you start adding bespoke fields, ensure you are clear about why and what you will do with that data.
Section Title | Data Points |
---|---|
Incident Identification Details | Ticket Number Title/Summary Date and Time Reported Reported By |
Incident Description | Detailed Description Category Sub-category |
Technical Information | Affected IT Services Configuration Items (CIs) System/Service Logs |
Prioritisation | Impact Urgency Priority |
Incident Response | Assigned To Incident Status Resolution Details Resolution Date and Time |
Communication and Follow-Up | Updates Resolution Confirmation Feedback |
Post-Incident Analysis | Root Cause Analysis (RCA) / Categorisation of Cause Lessons Learned Future Prevention Measures |
Service Request Tickets
So, you may have mixed your incident process and service request ticket process.
If you haven’t already separated these processes, then you should. It’ll help both the speed of resolution of the tickets and help you with your reporting. Service requests are not the same as Incident requests.
The IT Service Requests Process
What Categories of Service Request Tickets Should I Have?
Here are some suggested request ticket types:
Category | Sub-Category |
---|---|
User Services | New employee onboarding Employee offboarding User account management Email account setup VPN access setup |
Hardware Requests | Laptop/desktop provisioning Mobile device provisioning Printer and peripheral setup Hardware repair or replacement |
Software Requests | Software installation or upgrade License assignment Access to shared drives/folders Software troubleshooting |
Access Requests | File or folder access Application access Database access Network access permissions |
Information Requests | How-to guides and documentation Policy and procedure information Training material request |
Communication Services | Mobile phone services VoIP services setup Conference call setup |
Facilities Services | Access card issuance Office move and setup Secure storage requests |
Security Services | Security awareness training Password reset tools Two-factor authentication setup |
Collaboration Tools | Email distribution lists set up Collaboration platform access Video conferencing setup |
If you have an IT service catalogue, the service request tickets should mirror its options. There may be options online through a portal to allow for self-registration of requests from the customers/users.
What Data Should I Record in my IT Service Request Tickets?
IT Service Requests will be similar in structure to Incident tickets, but here are some suggestions:
Section Title | Data Points |
---|---|
Service Request Details | Ticket Number Title/Summary Request Type Date and Time Submitted Submitted By |
Request Description | Detailed Description Justification Category Sub-category |
Prioritisation | Impact Urgency Priority |
Approval and Authorisation | Approval Status Approved By Approval Date |
Request Fulfillment Details | Assigned To Fulfillment Plan Status Expected Fulfillment Date |
Cost and Resources | Estimated Cost Resources Required |
Communication and Follow-Up | Updates Completion Confirmation Feedback |
Documentation and Knowledge Sharing | Resolution Details Knowledge Article |
Problem Tickets
Problem tickets are about investigating the root causes of incident tickets. So, why for example you have to keep rebooting that one damn server every Thursday afternoon. The purpose behind incident tickets is to get it rebooted and working again, but the problem ticket says, ‘Hey, there’s a trend here’.
I said earlier that your problem tickets will likely align closely with your incident ticket types, but maybe not 100%. Having a common basis does help with linking problems to incident tickets.
The Problem Ticket Process
What Categories of Problem Tickets Should I Have?
Here are some common problem ticket types;
Category | Sub-Category |
---|---|
Infrastructure | Network Issues Server Failures Storage Problems Power and Cooling Hardware Malfunctions |
Software | Application Bugs Database Corruption Performance Degradation Integration Issues Security Vulnerabilities |
Service | SLA Breaches Availability Issues Capacity and Scalability Backup and Recovery Failures Service Configuration |
Security | Unauthorised Access Data Breach/Leakage Malware Infection Phishing Attacks Denial of Service (DoS) |
User Experience | Usability Issues Accessibility Problems Interface Design Flaws Feedback and Complaints Training and Documentation |
Process/Procedure | Inefficient Workflows Policy Gaps Communication Breakdowns Compliance Issues Change Management Failures |
What Data Should I Record in my Problem Tickets?
Here’s my suggestion as an essential minimum for the problem management process tickets.
Section Title | Data Points |
---|---|
Problem Identification Details | Ticket Number Title/Summary Date and Time Identified Identified By |
Problem Description | Detailed Description Category Sub-category |
Prioritisation | Impact Urgency Priority |
Related Incidents | Incident Ticket Links Incident Impact |
Investigation and Diagnosis | Root Cause Analysis Diagnostic Information |
Workaround and Resolution | Workaround Resolution Plan Resolution Date |
Change Requests | Related RFCs (Request for Change)Change Impact |
Status and Tracking | Current Status Update History |
Review and Closure | Review SummaryClosure CategoryClosure Date |
Preventive Measures | RecommendationsImplemented Changes |
Change request tickets
The Change Management process starts with logging a Change Ticket or a Request for Change (RFC). It’s used to track a change from the request through to it’s implementation and may be linked to Incident and Problem tickets.
The Change Request Process
What Categories of Change Request Tickets Should I Have?
Here are some that I would expect to see;
Category | Sub-Category |
---|---|
Standard Changes | Software updates and patches Password policy updates Minor network configuration adjustments Pre-approved hardware replacements |
Emergency Changes | Critical security patches Urgent bug fixes Immediate network modifications to restore connectivity |
Major Changes | New system implementations Major software upgrades Data center migrations Significant network overhauls |
Minor Changes | Small application enhancements Minor database modifications Small-scale hardware upgrades |
Service Request Changes | Access level modifications Service configuration changes Installation of additional features or services |
Regulatory and Compliance Changes | Updates to comply with new laws or regulations Changes to ensure compliance with industry standards |
Infrastructure Changes | Cloud infrastructure adjustments Virtualisation platform updates Storage capacity expansions |
Application Changes | Implementation of new functionalities User interface redesign Integration with other systems |
Security Changes | Implementation of enhanced encryption Addition of new security tools or services Updates to firewall configurations |
What Information Should Be Recorded in My Change Management Ticket?
An RFC should collect the following;
Section | Data |
---|---|
Change Identification | RFC Number Title/Summary Date and Time Raised Raised By |
Change Description | Detailed Description Category Change Type |
Prioritisation | Impact Urgency Priority |
Risk Assessment | Risk Analysis Mitigation Strategies |
Resources and Responsibilities | Resource Requirements Change Owner Implementation Team |
Planning and Approval | Implementation Plan Test Plan Approval Status Approvals |
Implementation Details | Implementation Date and Time Backout Plan |
Review and Closure | Implementation Review Post-Implementation Review (PIR) Date Change Status |
How to Calculate Ticket Priority
A widely accepted method for calculating this priority is the Impact * Urgency = Priority formula.
- The impact is the scale at which the ticket disrupts business services.
- The urgency is how quickly it needs to be resolved.
Both will typically be on a scale of 1(low) to 3(high), with specific criteria defining each level.
Impact / Urgency | Low (1) | Medium (2) | High (3) |
---|---|---|---|
Low (1) | 1 | 2 | 3 |
Medium (2) | 2 | 4 | 6 |
High (3) | 3 | 6 | 9 |
Prioritisation Example
An incident causes a service critical to business operations to be completely unavailable.
- Impact: High (3) because the service is critical to business operations and multiple users.
- Urgency: High (3) as the service needs to be restored immediately to avoid significant business loss.
Using the formula:
Priority=Impact×Urgency=3×3=9
Any ITSM solution will likely use this method, which applies equally well to service request, problem, and change tickets. However, you might adjust the definitions of your high/medium/low criteria for each.
20 Best Practices for IT Ticket Management
- Keep it simple.
- Automate Ticket Creation: Empower users with a self-service knowledge base for common issues to reduce unnecessary ticket volume. Get your support staff fixing rather than logging issues because that’s where the value is.
- Ticket Acknowledgment: Implement automated acknowledgements for ticket submissions, offering ticket numbers, expected response times, and status tracking links to enhance the user experience and reduce duplicate submissions. When logging a fault, nobody likes to be left open-ended, so set expectations.
- Customised Dashboards & Reporting for Agents and Requestors: Provide tailored views of ticket data to ensure sensitive information is shielded from requestors while maintaining clarity and reducing confusion.
- Address Single-Points-of-Failure: Establish backup roles for critical positions like the Assigned Change Manager to maintain workflow continuity during absences. You don’t want the whole process grinding to a halt when they are on leave.
- Spam management: Utilise automated tools to filter out junk mail, streamline ticket processing, and focus on genuine issues. It’ll just create endless tickets that’ll skew your stats.
- Structured Ticket Type Templates: Design tickets with organised templates to facilitate problem-solving and improve data collection and analysis. Use out-of-the-box templates and processes where possible.
- Implement a Self-Service Portal: Leverage ticket data to enhance self-service portals of common fixes, allowing users to resolve their issues independently.
- Automate Service Request Validation: Streamline and automate the validation process for service requests to expedite resolution times.
- Set up Robust SLA Monitoring: Establish and monitor SLAs for response and resolution times to optimise performance.
- Comprehensive Ticket Metrics Reporting: Beyond response times, monitor re-open rates, backlog counts, effort levels, handoff numbers, and customer satisfaction to gauge support quality and efficiency. Examine the trends.
- Minimise Lengthy Email Threads: Use ticket templates with additional note fields to reduce back-and-forth communications.
- Effective Queue Management: Prioritise tickets based on multiple criteria such as age, system priority, and required skills to manage workloads efficiently. Daily reports for team leaders can help them know where to focus their attention.
- Strategic Ticket Escalation: Recognise when to escalate tickets based on agent capability, SLA compliance, and user requests to ensure timely resolutions. Automate escalation where possible.
- Positive Perception of Escalations: Treat ticket escalations as constructive steps when identified early, optimising resolution efforts. They aren’t a failure, there are a variety of reasons for escalation.
- Tier Support Structures: Implement a tiered support system to align ticket assignments with agent skills, improving resolution efficiency and satisfaction. If you can, split Incident and Request handling ownership – task switching kills.
- Comprehensive Ticket Management Workflows: Develop and enforce a clear ticket management workflow to streamline operations and set clear expectations for users.
- Empowerment of Service Desk Staff: Provide staff with the necessary tools, knowledge, and training to efficiently resolve tickets and contribute to a comprehensive knowledge base. Service Desk should own the tickets during their life, and chase other teams on behalf of the customer.
- Integration of Tickets with Other Data: Link tickets to relevant ITSM and partner data for a more informed resolution process, enhancing efficiency and effectiveness. You can get some great reports with helpful insights.
- Avoidance of Ticket Misrouting: Educate agents on proper ticket routing to internal and external support teams and utilise automation to ensure tickets promptly reach the right hands. I’ve seen many systems where tickets can fall between stalls and not get picked up by someone because of faulty workflows.
Conclusion
Mastering ITIL ticket types and implementing best practices is crucial for efficient IT support.
Effective categorisation, avoiding common mistakes, and focusing on resolution metrics can significantly improve team performance and customer satisfaction.
Streamlined processes, from ticket creation to comprehensive management workflows, enhance support efficiency, cut costs, and boost customer experiences.
As technology and business needs evolve, these practices will remain vital to maintaining service excellence and addressing the dynamic challenges of IT service management.
Further Reading for Service Management Ticket Handling
- Help Desk Ticket Classification: Setting up ticket categories
- CA Spectrum Automation Manager – TechDocs
- The Ultimate Step-by-Step ITSM Implementation Project Plan
- Understanding the Anatomy of a Work Package Template – Iseo Blue
- IT Support Ticket Types
FAQs
What are the steps in a ticketing system?
The steps typically include ticket creation, classification, prioritisation, assignment, resolution, and closure.
What is an IT support ticketing system?
Ticket management in IT involves the processes and tools used to track, prioritise, and resolve support requests and incidents.
What are the four ITIL aligned ticket types?
The four ITIL-aligned ticket types are incident, problem, change, and service request.
What is ticket categorisation?
Ticket categorisation involves classifying tickets based on their type, urgency, and impact to streamline their management and resolution.
What should be included in an IT ticket?
An IT ticket should include the issue’s description, impact level, urgency, user contact information, and any error messages or relevant screenshots.