Ultimate Guide to ITIL Ticket Types and Best Practices for Efficient IT Support

Uncover the secrets to efficient IT support with our Ultimate Guide to ITIL Ticket Types. Learn best practices and expert insights for streamlined operations.

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.

Take the Shortcut: The Full Project Management Toolkit

  • 47 ready-to-use templates and 6 phase guides covering the full lifecycle – from idea evaluation to closure.
  • Templates to plan and run delivery: project plans, progress reports, RAID and risk logs, resource and budget trackers, work packages, change control, meeting minutes and more.
  • A lightweight, easy to follow, and robust framework.

Toolkit goes beyond what I expected and includes process guidance.” – Verified review

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.

ITIL Ticket Types Diagram
The ITIL Ticket Types

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

The Incident Management Process
The Incident Management Process

What Categories of Incident Tickets Should I Have?

When considering the categories of incident tickets, start with these;

CategorySub-Category
HardwareDesktops and Laptops
Printers and Scanners
Mobile DevicesServers
Network Equipment (Routers, Switches)
Peripherals (Keyboards, Mice)
SoftwareOperating Systems
Applications (Office, CRM, ERP)
Email and Communication Tools
Databases
Development Tools
NetworkConnectivity Issues
VPN Problems
Slow Internet/Network Performance
Wi-Fi Access
DNS Issues
SecurityVirus and Malware
Unauthorised Access
Data Breach
Phishing Attempts
Encryption Issues
AccessPassword Resets
Account Lockouts
Permission Issues
User Account Setup/Deletion
ServicesEmail 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 TitleData Points
Incident Identification DetailsTicket Number 
Title/Summary
Date and Time Reported
Reported By
Incident DescriptionDetailed Description
Category
Sub-category
Technical InformationAffected IT Services
Configuration Items (CIs)
System/Service Logs
PrioritisationImpact
Urgency
Priority
Incident ResponseAssigned To
Incident Status 
Resolution Details
Resolution Date and Time
Communication and Follow-UpUpdates
Resolution Confirmation
Feedback
Post-Incident AnalysisRoot 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

The Request Management Process
The Request Management Process

What Categories of Service Request Tickets Should I Have?

Here are some suggested request ticket types:

CategorySub-Category
User ServicesNew employee onboarding
Employee offboarding
User account management
Email account setup
VPN access setup
Hardware RequestsLaptop/desktop provisioning
Mobile device provisioning
Printer and peripheral setup
Hardware repair or replacement
Software RequestsSoftware installation or upgrade
License assignment
Access to shared drives/folders
Software troubleshooting
Access RequestsFile or folder access
Application access
Database access
Network access permissions
Information RequestsHow-to guides and documentation
Policy and procedure information
Training material request
Communication ServicesMobile phone services
VoIP services setup
Conference call setup
Facilities ServicesAccess card issuance
Office move and setup
Secure storage requests
Security ServicesSecurity awareness training
Password reset tools
Two-factor authentication setup
Collaboration ToolsEmail 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 TitleData Points
Service Request DetailsTicket Number
Title/Summary
Request Type
Date and Time Submitted
Submitted By
Request DescriptionDetailed Description 
Justification
Category
Sub-category
PrioritisationImpact
Urgency
Priority
Approval and AuthorisationApproval Status
Approved By
Approval Date
Request Fulfillment DetailsAssigned To
Fulfillment Plan
Status
Expected Fulfillment Date
Cost and ResourcesEstimated Cost
Resources Required
Communication and Follow-UpUpdates Completion Confirmation
Feedback
Documentation and Knowledge SharingResolution 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

The Problem Management Process
The Problem Management Process

What Categories of Problem Tickets Should I Have?

Here are some common problem ticket types;

CategorySub-Category
InfrastructureNetwork Issues
Server Failures
Storage Problems
Power and Cooling
Hardware Malfunctions
SoftwareApplication Bugs
Database Corruption
Performance Degradation
Integration Issues
Security Vulnerabilities
ServiceSLA Breaches
Availability Issues
Capacity and Scalability
Backup and Recovery Failures
Service Configuration
SecurityUnauthorised Access
Data Breach/Leakage
Malware Infection
Phishing Attacks
Denial of Service (DoS)
User ExperienceUsability Issues
Accessibility Problems
Interface Design Flaws
Feedback and Complaints
Training and Documentation
Process/ProcedureInefficient 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 TitleData Points
Problem Identification DetailsTicket Number
Title/Summary
Date and Time Identified
Identified By
Problem DescriptionDetailed Description
Category
Sub-category
PrioritisationImpact
Urgency
Priority
Related IncidentsIncident Ticket Links
Incident Impact
Investigation and DiagnosisRoot Cause Analysis
Diagnostic Information
Workaround and ResolutionWorkaround
Resolution Plan
Resolution Date
Change RequestsRelated RFCs (Request for Change)Change Impact
Status and TrackingCurrent Status Update History
Review and ClosureReview SummaryClosure CategoryClosure Date
Preventive MeasuresRecommendationsImplemented 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

The Change Management Process
Change Management Process

What Categories of Change Request Tickets Should I Have?

Here are some that I would expect to see;

CategorySub-Category
Standard ChangesSoftware updates and patches
Password policy updates
Minor network configuration adjustments
Pre-approved hardware replacements
Emergency ChangesCritical security patches
Urgent bug fixes
Immediate network modifications to restore connectivity
Major ChangesNew system implementations
Major software upgrades
Data center migrations
Significant network overhauls
Minor ChangesSmall application enhancements
Minor database modifications
Small-scale hardware upgrades
Service Request ChangesAccess level modifications
Service configuration changes
Installation of additional features or services
Regulatory and Compliance ChangesUpdates to comply with new laws or regulations
Changes to ensure compliance with industry standards
Infrastructure ChangesCloud infrastructure adjustments
Virtualisation platform updates
Storage capacity expansions
Application ChangesImplementation of new functionalities
User interface redesign
Integration with other systems
Security ChangesImplementation 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;

SectionData
Change IdentificationRFC Number
Title/Summary
Date and Time Raised
Raised By
Change DescriptionDetailed Description
Category 
Change Type
PrioritisationImpact 
Urgency
Priority
Risk AssessmentRisk Analysis
Mitigation Strategies
Resources and ResponsibilitiesResource Requirements
Change Owner
Implementation Team
Planning and ApprovalImplementation Plan
Test Plan
Approval Status
Approvals
Implementation DetailsImplementation Date and Time
Backout Plan
Review and ClosureImplementation 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 / UrgencyLow (1)Medium (2)High (3)
Low (1)123
Medium (2)246
High (3)369

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

  1. Keep it simple.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. Implement a Self-Service Portal: Leverage ticket data to enhance self-service portals of common fixes, allowing users to resolve their issues independently.
  9. Automate Service Request Validation: Streamline and automate the validation process for service requests to expedite resolution times. 
  10. Set up Robust SLA Monitoring: Establish and monitor SLAs for response and resolution times to optimise performance.
  11. 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.
  12. Minimise Lengthy Email Threads: Use ticket templates with additional note fields to reduce back-and-forth communications.
  13. 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.
  14. 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.
  15. 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.
  16. 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. 
  17. Comprehensive Ticket Management Workflows: Develop and enforce a clear ticket management workflow to streamline operations and set clear expectations for users.
  18. 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.
  19. 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.
  20. 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

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.

Further Reading

ITIL

Photo of author

Written by

Alan Parker

Alan Parker is an ISO 27001 consultant of over 10 years and founder of Iseo Blue Limited. He helps UK SMEs achieve certification in 90 days or less - often without a dedicated security team or a large budget. With over 30 years in IT governance and information security, Alan works with software companies, IT service providers, managed service providers, and professional services firms across the UK, Europe, and internationally. Qualifications: B.Sc (Hons) Information Systems, CISMP certified, ITIL Expert, PRINCE2 Practitioner. Named IT Project Expert of the Year (2024, UK). Alan writes in plain English for busy teams who need to get things done. Connect on LinkedIn, or explore his free ISO 27001 tools and templates at iseoblue.com.