Exploring the ITIL Ticket Types (2024)

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.

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 Devices Servers 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 Impact Urgency Priority
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 Summary Closure Category Closure Date
Preventive Measures	Recommendations Implemented 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.

FAQs

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.

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?An IT support ticketing system is a software tool that helps manage and track the resolution of IT service requests and issues reported by users.
What is ticket management in IT?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.

About the author

Hello, my name is Alan, and I bring over three decades of experience in the IT industry. My expertise spans IT Governance, Information Security, Project Management, and IT Service Management across diverse organisational styles and market sectors.

I am academically grounded with a degree in Information Systems. I have furthered my professional qualifications with an ITIL Expert certificate, PRINCE2 Practitioner qualification, and CISMP Certification in Information Security Management.

Throughout my career, I've led multi-million-pound change programmes, managed significant government contracts, and accumulated a wealth of practical knowledge and insights, often learned through overcoming challenges in the field.