Freddy AI for CX
Effortlessly deliver great customer experiences with Freddy AI.
Leverage a flexible, end-to-end, AI-powered enterprise platform to unify customer experiences
Detailing IT Ticketing Best Practices
IT tickets is the generalized term used to refer to a record of work performed (or needing to be performed) by your IT support organization to operate your company’s technology environment, fix issues and resolve user requests. Tickets may represent many different types of tasks or activities depending on the nature of your IT environment and the focus of your support team. They may go by other names like “service requests”, “trouble tickets” or “support cases” but most organizations and users are familiar with the term “IT ticket” so we will use it for simplicity.
IT tickets are important to your company because they keep a record of each of the operations and support activities that take place to keep your IT environment up and running, adding value to the business. Tickets are typically captured in an IT Service Management where they are stored, managed and updated as the issue or activity is resolved. IT helpdesks use tickets as a means of capturing and recording interactions with users. Operations teams use tickets to track technical issues that need to be addressed. IT management uses ticket data to understand the workload of their teams, make resourcing decisions and facilitate vendor partnerships.
Managing IT tickets effectively is an important part of ensuring your business receives the full value of your company’s IT investments. This is an important concept at the core of your IT operations and leveraging IT ticketing best practices is a good way to help your IT function manage costs, provide better systems and services to users and mitigate the impact of business disrupting events.
ITIL (formerly known as IT Infrastructure Library) represents the collective industry best practices and standards for how IT service management should be performed. It is important to acknowledge that ITIL does not discuss IT tickets directly but instead discusses IT Incidents and IT Service Requests which are types of IT tickets. Although ITIL uses different terminology, it contains valuable IT ticketing best practices in the Service Operations volume that should be reviewed and understood.
The term IT tickets can be used to refer to a lot of different types of support requests and activities that your IT function performs. The benefit of using tickets as a general record for these things instead of treating each independently is that they all involve similar data, follow similar lifecycle/workflows, and are often addressed by the same people. Treating them all as tickets helps drive staff productivity, gives users fewer touchpoints into IT, and enables easier data analysis and reporting.
Events are records of things that have happened in your IT environment. They may be point-in-time events or have an extended duration. Examples of events are releases, outages, maintenance activities and planned changes.
Alerts are indicators that something might have happened in your IT environment or that something is operating outside of pre-defined performance thresholds. Most alerts are system generated through automated monitoring and error handling
Incidents are unplanned interruptions or reductions in quality of an IT service or failure of a component in your IT environment that has not yet affected service. Examples of incidents are outages, errors and performance issues. Incidents have a defined start and end that correspond to some sort of event.
Also called service requests are routine activities such as requesting access, resetting passwords, updating data or provisioning services that your IT support team performs on your operational systems and services. They don’t indicate that something is broken, only that something needs to be done.
IT ticketing best practices have shown that it is helpful to manage all these items in a consistent way as “tickets” but also to classify them based on what type of issue they represent. Individual ticket types may have their own supplemental data needs, specific workflows that they go through, and unique reporting considerations. Understanding the different types of tickets your IT support organization handles is an important first step in ensuring that your ticket management processes and supporting ITSM systems are optimized to support your company’s unique needs.
Ticket creation is the most important stage in the lifecycle of your support issue. The choices that are made about when to create tickets (or not), what information to collect, how tickets should be created and what initial response should be provided to the requestor all decisions that will influence the speed, quality and perception of support provided.
When to create vs. not create a ticket
IT tickets are a record of activities and issues that need attention. The decision on whether to create a ticket or not doesn’t change whether the underlying task still needs to be performed. General IT ticketing best practices suggest that a ticket should be created if any of the following conditions exist:
Someone in IT needs to perform a task
An issue existed that impacted user productivity
A record is needed to enable analysis and decision making
There are two scenarios where companies often choose not to create tickets when best-practices indicate that they should. They are issues resolved by the user using self-service information or tools and system alerts and events that are resolved without manual intervention (such as auto-restart of services). It is important to record tickets for these scenarios because they represent potentially user impacting situations that should be analyzed and reviewed as part of your problem management and service assurance processes.
There are three primary sources of IT tickets. Since tickets are records of activities or issues, it is important to note that these are the sources of the ticket records and not the source or cause of the activity itself
Most modern IT systems include monitoring and error handling capabilities to automatically record tickets in an ITSM system when abnormal events or conditions occur.
The most common source of IT tickets is end users of IT systems and services requesting support through some sort of self-service portal, email or embedded “get help” capabilities.
helpdesk agents, operations staff and monitoring center employees record tickets for situations where a support activity is initiated but no record yet exists. Examples include calls into a helpdesk, maintenance activities and monitoring alerts.
The data you collect and record when an IT ticket is created is critically important to the efficiency of your support processes. You need to collect enough data to accurately represent the underlying issue, classify it and route it to the correct support resource, but you don’t want to collect extra data that isn’t necessary – that slows down the support process and is a waste of time and resources. The challenge most IT organizations face is not knowing what data they are going to need so they either collect too much or must go back to the user to collect more data later. Companies also tend to collect data that they already have (such as user contact, asset and location data).
IT ticketing best practices have shown that it is best to focus data collection for ticket creation on capturing the key pieces of reference data that enable you to leverage data you already have available. For example, collect a User ID or email address and use it to look up contact and location data. Capture an asset tag or device identifier and look up configuration and version information. Capture the name of the impacted system or service to lookup monitoring data and change records. Implementing this approach effectively requires your IT ticketing system to be well integrated with your other ITSM capabilities such as change management, IT asset management and monitoring tools as well as your user accounts database.
The two additional pieces of data that should be collected for user-initiated tickets and those recorded by support agents are: “What is the impact of the issue? and “how can we reproduce this issue?” The answers to these two questions can typically only be provided by the end user and are important for assessing the criticality of the ticket and assigning it the appropriate ticket priority.
A recent support trend is for users to open tickets using mobile devices. These devices provide the opportunity to collect a couple of additional pieces of information that can aid in the support process. First is geo-location – most mobile devices are GPS enabled and able to share location information with installed applications. Location data can help support staff better diagnose issues related to connectivity and network latency which can appear to the user as system or service issues. Mobile devices are also typically equipped with cameras and the ability to capture screen images and videos. Often “a picture is worth 1000 words” and it is more efficient for the user to “show you” what they are seeing with a picture rather than try to explain it in words.
You may not be able to start working on a ticket right away, however, users expect you to acknowledge and respond to their ticket request immediately. IT ticketing best practices have shown that automated email acknowledgments that the ticket has been created, providing the ticket number, expected response time and a link where the user can view status are essential ticket communications that should be sent to the user as soon as the ticket is received. Failure to provide a ticket acknowledgment email is one of the most common causes of duplicate tickets being created.
IT ticket content is generally organized into a basic structure of header data and the ticket body. The ticket header includes information about the requestor, a brief description of the reported issue, impacted systems classification data and any timestamps used for calculating SLAs. The data contained in the header is used for managing the ticket through its lifecycle. In contrast, the data contained in the ticket body is used for investigating and resolving the ticket. Ticket body data will typically include things like steps to reproduce, user correspondence, troubleshooting notes and actions taken to resolve the ticket. It is important to differentiate between header and body content because each serves a unique purpose in the IT ticketing process.
A common issue that companies face when designing their IT ticketing systems is determining what data to collect in dedicated fields on the tickets vs what data to capture in free-form text (notes) fields. Dedicated data fields are easier to use for analytics, reporting and driving workflow automation rules but they take considerably more time to populate than notes fields.
IT ticketing best practices suggest that dedicated data fields are most appropriate for ticket header data that is only typically captured once (not updated frequently) and for system generated data like timestamps. Because it is the ticket header data that are most commonly used for things like queue prioritization, routing rules and reporting, having individual data fields makes these tasks easier. Diagnostic data, user interactions and troubleshooting notes found in the ticket body are best suited for free-form text fields that enable copy and paste of large blocks of data.
An important best practice for IT ticketing is to provide multiple views into your ticket data. There is often detailed technical information, troubleshooting notes and potentially sensitive data like known issues and security flaws that are recorded as a part of the agent notes on IT tickets. This data is not intended to be viewed by the requestor or anyone outside the support organization. The ticket views that requestors see need to reflect highly curated, edited and formatted information that provides clarity and avoids creating additional confusion. IT ticketing best practices suggest that agent notes and communications with requestors be managed in separate fields within the ticket body to avoid inadvertent disclosure of data.
Ticket classification is an important part of modern ticketing processes. Classification data is used for establishing SLA expectations, routing tickets to the proper support teams and grouping tickets for analysis and reporting purposes. Rule-based workflow automation utilizes ticket classification data as a key tool for improving the efficiency of support processes. There are 4 key pieces of classification data that IT tickets should include
Tickets need to be accurately and consistently classified so they receive the appropriate level of attention from your support team and ensure that the most important issues for the company get addressed first.
Your company’s ITSM system will likely play an important role in facilitating tickets being routed between support teams. Business rules and automation can help ensure quick and effective handoffs but ultimately ticket routing is controlled by your support agents and the data they enter into the ticket. IT ticketing best practices suggest that the most effective way to avoid misrouting of tickets is through agent education on how ticket routing works. There are 3 common routing scenarios for IT tickets that your support agents should be familiar with.
Most of the ticket routing that takes place occurs within the helpdesk or IT support organization, directing tickets to specialized resources based on skills and/or experience. For example, tickets related to account permissions might be routed to an access management team, or complex software issues may get routed to experienced technical resources with access to source code. Internal routing is often referred to as re-assignment because the original agent transfers ownership and is relieved of responsibility for the issue when routing occurs.
Some companies leverage 3rd party support vendors and component suppliers to resolve tickets. These external partners typically do not use the same ticketing system as your helpdesk and routing issues to them often require creating a ticket in the partner’s system and referencing it within the internal ticket. What makes this scenario unique is that the agent working on the ticket retains ownership and is responsible for brokering status updates to the requestor as the 3rd party resolves the underlying issue.
Many global companies have IT support staff working on issues 24 hours/day – often in multiple support centers located in different geographies. At the end of the working hours in one location, open tickets are handed off to another support center for continued troubleshooting. This routing scenario is like internal support team routing except that active work-in-progress is expected to be transitioned so continuous support can be maintained (the ticket doesn’t go back into the queue for re-prioritization).
By ensuring that support agents understand how these routing scenarios work, how to initiate and control routing rules and what happens to ownership of the ticket, they will be able to transition tickets more effectively and assist the user in getting the issue resolved quickly.
When tickets are created and/or routed to a new support team, they are typically assigned to a queue or backlog instead of being assigned directly to an individual. Queueing enables managers and support team leaders to prioritize the work that their teams perform to ensure the most important issues are addressed first. Many organizations employ a first-in/first-out (FIFO) approach to queue management but IT ticketing best practices suggest using a combination of 7 key factors for prioritizing tickets in support queues (these are in no specific order).
Queue management is really workload management and while automation rules can assist in queue prioritization, a subjective assessment of the 7 factors and comparison with available resources is often necessary. Other considerations such as SLA compliance, capacity optimization and support costs can also play into queue prioritization decisions.
Service level agreements (SLAs) are a measurement tool for evaluating ticket handling performance against a pre-defined set of criteria. More importantly, they are a tool for driving the behavior of how tickets are handled by your support team and external partners. The defined SLA measurement areas and performance targets will determine how both teams and individuals manage their support workload. It is common practice for IT tickets to be evaluated on 2 SLAs
Response Time SLA – The elapsed time from a ticket being created and/or assigned to a queue until it is accepted by an individual and active troubleshooting begins
Resolution Time SLA – The total elapsed time from ticket creation until it is set to a resolved state indicating the issue has been fully addressed
Both SLAs focus on the speed of response and ticket resolution and encourage the behavior of agents trying to close cases quickly. IT support can be costly and while these SLAs can help encourage cost control, companies must be careful that this doesn’t lead to undesired behavior and quality issues. IT ticketing best practices suggest that SLAs, for the quality of support and customer satisfaction, should also be included to encourage agents to focus on resolving the underlying issue impacting the user instead of focusing on closing the support ticket. Ticket SLAs should be both measurable and include specific performance targets to be most effective.
In addition to the SLA metrics, ticketing best practices suggest that the following metrics be tracked to help with evaluating the overall performance of your support operations and targeting areas for improvement:
Recurrence / Re-open rate – a measure of quality support
Backlog count – an indicator of both responsiveness and resource capacity issues
Effort (active support time) – a simplified measure of ticket difficulty
# of handoffs – effectiveness of support workflows and routing rules
User satisfaction – a measure of communication effectiveness
First call resolution – an indicator of agent skillset and data collection at ticket creation
IT tickets can be complex, and it is unreasonable to expect agents to be able to resolve every issue presented to them within the target SLAs. There are times when tickets need to be escalated, either internally (getting help from someone else on the team) or by routing the ticket to another group (internal or external) that is more qualified to address the issue. There are 3 key scenarios that trigger an escalation of IT tickets:
User requests escalation
Agent identifies that they lack the skills, access, knowledge to resolve the issue
SLA targets are missed (auto escalation)
Ticket escalations should be treated as hand-offs (either internal or external) and should follow a similar process. The agent should summarize the current status of the ticket being sure to note any observations, assumptions and missing information along with any diagnostic and/or remediation actions taken. This information is critical for enabling the person receiving the ticket to quickly assess the situation and continue providing support. Ticketing best practices suggest that escalations should be treated as a positive action when the agent identifies the need early and avoids wasting time on tickets they know they will be unable to resolve.
IT tickets are a central part of your IT support operations, but they become even more valuable when they are connected with other ITSM and partner data. At a minimum, you should be able to associate your IT tickets with the following related data records:
With effective data integration, your support agents will be able to access the supporting data related to each of these connected objects and avoid having to re-enter them into the ticket itself. This both saves time and effort as well as provides more information to assist in resolving the user’s issue.
Best practices also suggest that your IT ticketing processes be integrated with other related ITSM processes within your organization
Tickets may include feature requests and user feedback that is helpful for developers in improving the performance and usability of IT systems and services.
Change requests are often directly related to the events that initiate and/or resolve many IT tickets. Integrating change management and ticketing workflows enables better insight into the effectiveness of planned changes.
IT ticketing is most effective when agents leverage the experience and lessons learned from previous tickets. Your ticketing process should include provisions for both creating and consuming knowledge articles.
Ticketing integration with monitoring capabilities and system generated tickets is the foundation of proactive support (resolving issues before users notice an impact).
IT tickets are a key source of data for identifying, diagnosing and resolving problems in your IT environment. Problem management is also the source of known-issue data for your IT systems.
The general theme of all these IT ticketing best practices is that your people, processes, data and systems should be optimized for resolving the user issue rather than processing and closing the ticket itself. IT tickets are a record of the IT support work that needs to be done and a tool to enable more effective workload management.
By clicking on "SIGN UP FOR FREE" you agree to our Terms and acknowledge having read our Privacy Notice
The Ultimate Guide to ITSM Best Practices
Self Service Best Practices
Problem Management Best Practices
Productivity Tips for IT agents
Start your 21-day free trial. No credit card required. No strings attached.
Sorry, our deep-dive didn’t help. Please try a different search term.