Ticketing Systems

A ticketing system is a tool used in IT support teams to track, manage, and resolve user issues efficiently. Every user issue is logged in the system allowing the IT support staff to prioritize and organize the workload of outstanding tickets.

A ticketing system is the backbone of an effective IT support operation. It transforms the noise of incoming requests into an organized, trackable, and accountable workflow. Without a structured way to capture, prioritize, and track all of those requests, things fall through the cracks, users get frustrated, and the IT department earns a reputation for being unresponsive.

This post covers ticketing systems — from the fundamental concepts to the best practices for keeping the queue clean and users happy. Jira Service Management will be used to illustrate some of the key concepts.

What is an IT Ticketing System?

An IT ticketing system is software that converts every incoming support request into a structured record called a ticket. Each ticket functions as a digital case file, capturing all relevant details about the issue — who reported it, what device or system is involved, when it was submitted, the urgency in resolving it, the technician assigned to resolve the issue, and what steps have been taken to address it.

A ticketing system streamlines communication, provides transparency, enhances productivity, increases response times and user satisfaction, and organizes workflows.

An effective ticketing system allows users to easily create a support request and receive frequent updates on the status of the request.

The key processes in a ticketing system are:

1. Intake – requests are received and logged.
2. Triage – requests are prioritized and assigned to technicians
3. Escalation – challenging and important tickets are escalated to technicians with the expertise to resolve the issue.

A ticket is created through email, a self-service portal, a phone call to the support team, or an automated trigger.

IT support departments rely on ticketing systems to:

• Prioritize new tickets.
• Categorize tickets
• Assign work to the right technician
• Hold technicians accountable for their assigned tickets. When every request has a unique identifier and an assigned owner, nothing gets lost in someone’s email inbox.
• Track progress in resolving each issue.
• Enforce response deadlines to increase user satisfaction.
• Communicate with users directly through the ticket interface.
• Organize workflows for resolving support requests.
• Maintain historical records for auditing.
• Generate performance reports.
• Document everything done on support requests including troubleshooting steps, communication with the user, and ticket resolution. Then the documentation can be referenced when a similar issue occurs, the issue is escalated to a new technician, or management wants to analyze trends in recurring problems.

Some of the most widely used ticketing platforms in the industry today include:

• Jira Service Management bridges the gap between IT support and software development teams. We will look at Jira in more detail later in this post.
• ServiceNow is a heavyweight enterprise platform used by large organizations with complex ITSM needs.
• Freshservice is a cloud-native tool known for its clean interface and ease of configuration.
• Zendesk is popular among organizations that want a ticketing solution with strong customer service roots.
• Spiceworks is a free option that is a common starting point for small IT teams and MSPs.

Key Components of an IT Ticketing System

Understanding how tickets are structured helps technicians use the system more effectively and helps organizations configure their platform to capture the right information. While different platforms have their own terminology, the following components appear in virtually every major ticketing system.

Ticket ID

Every ticket is assigned a unique identifier, or reference number, the moment it is created. It may be numeric (e.g., #8675) or alphanumeric (e.g., TW-2026-0812). Support technicians reference it in their communications with users, in escalation emails, and in management reports. And it is used for searching historical records.

Requestor Information

The requestor is the person who has an issue and opens a ticket. The requestor’s contact information is recorded on the ticket such as name, email, department or business unit, phone number, and employee ID. Technicians can contact the requestor to gather more information or provide status updates.

Requestor information also helps IT teams analyze ticket data over time such as identifying departments with recurring issues, users who may need additional training, and patterns that point to systemic problems.

Issue Categories

Categorization is how IT teams route incoming work to the right people and generate meaningful metrics about the demand for support resources. Standard top-level categories include:

• Hardware – physical devices such as laptops, monitors, printers, and peripherals
• Software – application errors, licensing questions, and installation requests
• Network – connectivity problems, VPN access, and bandwidth issues
• Security – malware, phishing, account compromise, and access anomalies
• Access management – password resets, new account provisioning, permission changes, and offboarding tasks

Within each of these categories the subcategories allow for more granular classification, which is helpful for trend analysis and automating ticket routing.

Priority Level

The priority level of a ticket determines how quickly a technician is expected to respond and resolve the issue. Assigning the correct priority levels to tickets is essential to resolving issues in the correct order.

Not all issues carry the same weight. For instance, a server outage affecting hundreds of employees demands an immediate response, while a request to install optional software can wait.

When priority levels are assigned correctly critical business operations are addressed immediately, and less urgent work is handled in an orderly queue. When priority assignment is handled incorrectly then either: (1)everything becomes “urgent” and the support agents waste time focusing on unimportant issues, or (2)genuinely critical issues sit unaddressed because someone underestimated their impact.

Priority is typically set based on two factors:

• Urgency indicates the time-sensitivity of the issue.
• Impact indicates many people or how much of the business is affected by the issue.

A reliable approach to priority assignment is a two-axis matrix that scores each issue on urgency and impact independently, then combines those scores into an overall priority rating. Most organizations use a four- or five-tier priority scale.

Priority	Urgency	Impact	Example Scenario	Typical Response Target
Critical (P1)	Immediate	Organization-wide or business-critical system	A core ERP system is down, and no one can process transactions.	15 minutes
High (P2)	Within hours	Department-wide or significant revenue impact	The sales team’s CRM is inaccessible during a quarter-end push.	1 hour
Medium (P3)	Within the business day	Single user or small group; workaround available	An employee’s laptop has a broken keyboard, but they have a spare.	4 hours
Low (P4)	Flexible; can be scheduled	Convenience or future need	A request to install a new font package for design work.	24–48 hours

A few principles help teams apply these levels consistently.

• Impact generally outweighs urgency when the two conflict. A server that fails silently at 3 AM is critical even if no one has called in yet.
• Priority should be assigned based on actual business impact, not on how aggressively a user is requesting escalation.
• Priority should be adjusted as circumstances change. For instance, a medium-priority network issue becomes critical if it turns out more systems are affected than initially reported. Many organizations build SLA timers directly into their priority structure. When a ticket is created at a given priority level, a countdown clock begins and escalation alerts fire automatically if deadlines approach without resolution.

Assigned Technician

Once a ticket is created and categorized, it needs to be assigned to a technician to resolve the issue. Proper assignment ensures that someone with the right skills is accountable for each ticket.

Assignment can be manual in which a dispatcher or team lead reviews incoming tickets and assigns them. Or assignment can take place automatically using rules that take into account the ticket’s category, priority, keywords, or the requestor’s department.

Team Structure

Most support teams include three tiers:

1. Tier 1 technicians handle the more basic support requests. They are frequently provided a defined list of questions and tasks they are authorized to complete in resolving a ticket. Tickets are escalated to a higher-level technician when they require action beyond the authorized scope or expertise of the tier 1 technician.
2. Tier 2 technicians have greater knowledge and authorization to resolve tickets. If they lack the detailed expertise required to resolve a ticket then the issue is escalated to the next level.
3. Tier 3 technicians work on critical business issues and those involving high-level expertise in a particular subject.

Ticket Status

Ticket status is the real-time indicator of where an issue sits in the support workflow. A well-designed status model gives every stakeholder — the user waiting for a fix, the technician working the issue, and the manager watching the queue — an accurate and shared understanding of what is happening.

Using status fields technicians, managers, and users can understand at a glance whether work has started, whether the ticket is waiting for additional information, or whether the issue has been resolved. Below are common status fields in ticketing systems.

Status	Meaning	Who Typically Sets It
New / Open	Ticket has been created but no technician has begun work on it	System (automatic on creation)
Assigned	A technician or team has been designated to handle the ticket	Dispatcher, manager, or routing automation
In Progress	Active troubleshooting or fulfillment work is underway	Assigned technician
Pending — User Response	The technician needs additional information from the requestor before proceeding	Assigned technician
Pending — Third Party	Resolution depends on a vendor, external provider, or another internal team	Assigned technician
On Hold	Work is intentionally paused, often for a scheduled maintenance window or approved delay	Assigned technician or manager
Escalated	The ticket has been transferred to a higher tier of support or a specialist	Assigned technician or manager
Resolved	The fix has been applied, and the issue appears to be corrected; awaiting user confirmation	Assigned technician
Closed	The user has confirmed resolution, or the ticket has been closed per policy after a set period without response	Assigned technician, manager, or system automation

A few status management habits separate disciplined support teams from chaotic ones.

• Tickets should never sit in “In Progress” status for days without an update. If work has stalled, the status should reflect the reason.
• When a ticket moves to “Pending — User Response,” many organizations implement an automatic reminder that fires after 24 or 48 hours, followed by auto-closure if no response is received after a defined window. This prevents the queue from filling up with stale tickets that cannot move forward.

Notes, Work Logs, and Attachments

When a ticket is opened initial fields are populated in the system. Then a ticket accumulates additional information as work progresses. Technicians add internal notes to document troubleshooting steps, observations, and hypotheses. Work log entries record how much time was spent on the issue. Attachments like screenshots, error logs, and configuration files are linked to the ticket. These running records transform a ticketing system from a simple task manager into a knowledge base.

Resolution

When an issue is resolved, it is best practice to document the root cause and the specific steps that fixed the problem. The additional information helps the next technician who encounters the same issue, feeds into knowledge base articles, and supports post-incident reviews for major outages.

How to Properly Log a Ticket

The way in which a ticket is created (or logged) greatly influences how efficiently it will be resolved. A poorly written ticket with vague descriptions and missing details forces the assigned technician to play detective before any real troubleshooting can begin. A well-written ticket, on the other hand, gives the technician everything they need to get started immediately.

Capture Requestor Information

Record the user’s full name, primary contact email, department, and phone number. In shared device environments (e.g., call centers) record the device name or asset tag of the affected system, since the user submitting the ticket may not be the person who uses the affected machine.

Describe the Issue

The issue should be described clearly and in detail. Vague descriptions like “the computer is acting weird” or “the system is slow” are not actionable. Encourage users to answer four key questions when submitting a ticket:

• What exactly is happening?
• What were you doing when it happened?
• What is the error message, if any?
• When did it start?

The following is an example of correctly logged ticket that gives an agent a head start in resolving the issue: “Microsoft Outlook crashes immediately after I click Send on any email with an attachment. The issue started happening yesterday morning after the overnight Windows updates. The error message says: Microsoft Outlook has stopped working. Running Windows 11 on a Dell Latitude 5520.”

Document the System

When creating the ticket include the device name, the operating system and version, and the version of any relevant application. This context matters enormously for troubleshooting. A browser compatibility issue behaves differently on Chrome versus Edge. A software crash might only affect a specific OS patch level. Without this information, the technician may spend an unnecessary hour replicating an environment before they can even reproduce the problem.

Set the Category and Priority

Whoever logs the ticket — whether that is the user through a self-service portal or a help desk agent taking a call — is responsible for making an initial category and priority determination. This does not need to be perfect since technicians reviewing the queue will adjust as needed. Yet a reasonable initial categorization ensures the ticket lands in the right team’s queue quickly rather than sitting in a generic inbox awaiting triage.

Add Attachments

Screenshots of error messages, event logs, network traces, and photographs of physical hardware issues are all enormously useful. Training users to attach screenshots as a standard part of ticket submission can cut resolution time significantly for software-related issues. Prominently display the attachment option in the self-service portal to encourage user adoption.

Add Internal Notes

The ticket should include everything done by the support team. As troubleshooting progresses, every meaningful step should be logged in the ticket notes. For example:

• Tested rebooting the device — issue persists.
• Reinstalled the application — issue persists.
• Ran diagnostics — no hardware faults detected.
• Escalated to Tier 2 for deeper investigation.

This running log serves as a hand-off document if the ticket is escalated, a reference if the issue recurs later, and a source of data for post-incident review.

Ticket Lifecycle

Every ticket follows a journey from the moment a user experiences a problem to the moment the issue is confirmed to be resolved and the ticket is archived. Understanding this lifecycle helps technicians know what is expected of them at each stage and helps managers identify bottlenecks.

Stage 1 — Submission

A ticket is opened when a user encounters a problem and submits a service request. The ticket is stamped with a creation time, and SLA clocks typically begin at this moment.

Tickets are submitted through various channels:

• self-service web portal
• email-to-ticket integration
• phone call to the help desk
• live chat interface
• monitoring systems can automatically create tickets before humans report them

Stage 2 — Triage and Categorization

In the triage stage incoming tickets are reviewed by a dispatcher, tier 1 technician, or automated routing rules to confirm the correct category, priority, and assignment. Mislabeled or misrouted tickets get corrected in the triage stage, so the correct technician can start working the issue and delays in ticket resolution are avoided.

Stage 3 — Initial Response and Acknowledgment

The assigned technician reaches out to the user to confirm receipt of the ticket and to gather any additional details that are needed. Users who receive a prompt response when their ticket is submitted, even one that simply confirms their ticket is in the queue, are more tolerant of wait times than users who hear nothing and do not know whether their request was received.

Stage 4 — Investigation and Troubleshooting

In the investigation state the actual technical work occurs. The technician works through the problem systematically, testing hypotheses, applying fixes, and documenting each step in the ticket notes. Good documentation is important for escalation and knowledge base contributions.

Stage 5 — Escalation

A ticket is escalated when the assigned technician reaches the limit of his expertise, diagnostic tools, or authorization. The escalation should be accompanied by a clean hand-off note that summarizes what has already been done to investigate and resolve the issue. Then the receiving technician avoids duplicating work and can resolve the issue more quickly.

Stage 6 — Resolution

A ticket status is updated to Resolved when the technician applies a fix and verifies that the issue is corrected. The user is notified with a clear explanation of what caused the problem and what was done to address it. The explanation should be written in plain language and without technical jargon. So the user understands what was done and can apply any recommended preventive steps going forward.

Stage 7 — Confirmation and Closure

The ticket is marked Closed when the user confirms that the issue is resolved. If the user does not respond within the organization’s defined window, which is typically 48 to 72 hours, most platforms will automatically close the ticket. Closed tickets are archived but remain searchable, so their documentation lives on as institutional knowledge.

Stage 8 — Post-Resolution Review

Many organizations complete a post-resolution review for major incidents, critical-priority tickets, or issues that took significantly longer than the SLA to resolve. The review is a brief structured conversation or written analysis that examines the root cause, response effectiveness, and process changes that might prevent a recurrence.

Service Level Agreements (SLAs)

A Service Level Agreement (SLA) is a formal commitment that defines the response and resolution standards the IT support team is held to for different categories and priorities of tickets. SLAs can be a legal contracts or internal policy documents.

Why SLAs Matter

SLAs transform a ticketing system from a passive tracking tool into an accountability mechanism. They remove ambiguity by establishing shared, written expectations that both IT teams and the people they support can reference.

Without SLAs, IT support teams operate in an environment where everyone defines “fast” differently. For instance, a manager in finance might believe that any IT issue affecting their team should be resolved within the hour. Yet a busy technician might consider a same-day resolution perfectly acceptable for the same issue.

SLAs also create the foundation for performance measurement and improvements to the IT support process. For instance, if the team is consistently missing the SLA on medium-priority tickets then changes to staffing, tooling, or the support work flow may be needed.

Key SLA Metrics

Response time refers to how quickly a technician must acknowledge and respond to a new ticket. Resolution time is the outer limit within which the issue must be fully resolved.

Many organizations track time-to-first-response separately from time-to-resolution because the two measure different aspects of service quality. A technician can respond to a critical ticket within 15 minutes by reaching out to gather information, even if the fix itself takes two hours.

SLA Structure by Priority

Priority	Response Time Target	Resolution Time Target	Breach Consequence
Critical (P1)	15 minutes	2 hours	Immediate escalation to IT leadership; incident review required
High (P2)	30 minutes	4 hours	Automatic escalation to senior technician; manager notified
Medium (P3)	2 hours	8 hours	Supervisor alert if SLA metric is approaching
Low (P4)	4 hours	48 hours	Logged for performance reporting; no immediate escalation

SLA Breach Handling

When a ticket is at risk of breaching its SLA or has already breached it, most ticketing platforms will fire automated alerts to the assigned technician, their supervisor, and sometimes the requestor.

The response to a breach should be swift. The ticket is reviewed. Additional resources are allocated if needed. And the user receives proactive communication explaining the delay and the revised timeline.

SLAs should account for real-world constraints. Most organizations specify that SLA clocks run during business hours only, with exceptions for critical-priority tickets that use a 24/7 clock regardless of when they are submitted. Tickets placed in “Pending — User Response” or “Pending — Third Party” status are often paused from the SLA clock, since the delay is outside the IT team’s control.

Internal vs. External SLAs

IT teams operating within a single organization typically work against internal SLAs that are performance commitments to their colleagues and leadership.

Managed service providers (MSPs) and external IT contractors operate against contractual SLAs with their clients where breaches may trigger financial penalties, service credits, or contract termination clauses. The stakes are higher in contractual SLA environments, which is why MSPs invest heavily in automation, monitoring, and escalation workflows to protect their SLA compliance rates.

Best Practices for a Ticketing System

The value of a ticketing system is entirely dependent on how the technicians use it. The following practices determine whether a support team struggles to promptly resolve issues in the ticket queue consistently delivers excellent service.

Respond Promptly

The first contact with the requestor sets the tone for the entire interaction. Make it a standard practice to respond to every new ticket as quickly as the SLA requires, even if no work has been done to resolve the issue.

Users experience time differently when they are waiting for IT support. A wait of forty-five minutes feels much shorter when an acknowledgment arrives within the first 10 minutes of opening a ticket.

Update Ticket in Real Time

A ticket should never go silent for hours while a technician is actively working it. Every significant action should generate a note in the ticket immediately. Each tool run, configuration change, call with a vendor, or question sent to the user should be noted. Consistent ticket updates have compounding benefits:

• Supervisors are kept in the loop.
• A clean hand-off record is available if escalation is needed.
• The technician can substantiate all his work on the ticket.

Communicate in Clear Language

Write resolution summaries that explain what happened and what was done in language that a non-technical person can follow. User satisfaction will improve and the user will be less likely to recreate the same issue in the future.

Not everyone reading the ticket updates has a technical background. If a resolution note states “reimaged hard drive from the gold image, issue resolved” then a technician referencing your notes may understand what you did. Yet the user who opened the ticket may not understand.

Work Within the System

One of the most corrosive habits in IT support is the informal side channel in which technicians complete work that is not documented in the ticketing system. For instance, someone stops a technician in the hallway, or a manager sends a direct message asking for a favor.

All IT support work should have a ticket in order to correctly prioritize business needs and the limited resources of the IT staff. When work is done outside the ticketing system then SLA measurement is inaccurate, it is more difficult to recognize patterns in the tickets being opened, and less important issues get addressed before more important ones.

Categorize and Tag Properly

Use category and tag fields properly to improve ticket resolution times and post-incident reviews. The data your ticketing system generates is only as useful as the metadata on each ticket.

Consistent, accurate categorization enables meaningful trend analysis that can lead to improvements in the IT support process. For instance, if your team discovers that 30% of all tickets in a given month are password resets, then it may be useful to invest in self-service password reset capabilities.

Document Resolutions for Knowledge Base

Every ticket that involves a non-trivial troubleshooting process is a potential knowledge base article. When a technician resolves a tricky issue, they should ask themselves: “Is this something another technician might encounter, or is this something a capable user could resolve themselves next time?” If the answer is yes, the resolution steps should be written up in a format suitable for the knowledge base.

Over time, a well-maintained knowledge base reduces ticket volume by empowering users to self-serve. And it reduces resolution time for technicians who can find documented solutions quickly.

Ticket Deflection

Ticket deflection is the practice of empowering users find a solution to an issue on their own, instead of opening a support ticket. The result is a reduction in the number of tickets created in the system.

Both the users and the support staff benefit from ticket deflection. Users can more quickly resolve their issues instead of opening a ticket and waiting for a response.

With more ticket deflection the support staff has more capacity. They spend less time on smaller issues and have more time available to work on complex issues with greater impact on the business. Ticket resolution time decreases and user satisfaction improves.

The support teams should remove the historical tickets and identify the issues that can be deflected, such as the simple and repetitive requests. Which tickets relate to issues that a user can be empowered to handle on his own? Can the system be improved to prevent the need to have the ticket?

With proper training and a well-documented knowledge base users can solve less complicated problems on their own (e.g., password resets or basic policy inquiries).

Users can receive regular training on how to complete the simpler issues that frequently lead to ticket creation. Then users can resolve issues without even opening a ticket.

A robust knowledge base can include FAQs, tutorials, and videos. Users should be frequently reminded about the benefits of using the knowledge base and how to access it. Regular training sessions can teach users how to use the knowledge base and the benefits it provides. A user visiting the ticket intake page could see a prominent link to the knowledge base and a message encouraging him to use the resource and resolve the issue quicker.

When a ticket is opened regarding a simple issue, the triage process can include directing people to the company resources to resolve the issue more quickly on their own. A user who needs a password reset can be directed to a company web portal to complete the task himself. A user needing information on company policies can be directed to FAQ page populated by the human resources team.

After initiating a ticket deflection campaign regularly check the reporting metrics to verify improvements in resolution time and user satisfaction. And look for way to increase ticket deflection and free up support resources.

Review Ticket Queue Regularly

Queue hygiene is an important aspect of an effecting ticketing system. Building a daily or weekly queue review habit keeps the system reliable and actionable.

For instance, tickets sitting in “Assigned” status without updates for more than a day should be reviewed. Tickets awaiting user response that have passed the reminder threshold should be escalated or closed. Stale tickets that slip through the cracks become a source of SLA breaches, user frustration, and inaccurate queue metrics.

Use Reporting Data for Continuous Improvement

Most enterprise ticketing platforms generate robust reporting such as:

• ticket volume by category
• first response time
• aging ticket report
• resolution time by technician
• SLA compliance rates
• first-call resolution rates
• recurring issue frequency – highlights needed improvements in business processes
• customer satisfaction

Ticketing system reports are not just for management. They are a tool for every member of the team to understand where demand is coming from and whether their performance is improving over time. Performance reports can identify technicians who need more training.

Teams that review their metrics regularly and use them to inform process changes consistently outperform teams that treat the ticketing system as a passive record-keeping tool.

Close Tickets with Care

A ticket closed prematurely that triggers a follow-up submission creates more work for the team. And it signals to the user that the previous resolution was careless.

Before changing the ticket status to Resolved, confirm that the fix has actually held instead of only appearing to work in the moment. And before marking the ticket Closed, ensure the user has had adequate time to test the solution in their real work environment. When in doubt, leave the ticket in Resolved status a little longer and let the auto-close timer do its job.

Choosing a Ticketing System

For IT professionals who are in a position to evaluate or recommend ticketing solutions, there are a few dimensions worth assessing beyond feature lists and pricing.

Scalability

A system that works well for a five-person IT team may become a bottleneck for a fifty-person team. Evaluate whether the platform can scale with the organization — both in terms of ticket volume and in terms of the sophistication of workflows and automation you will eventually want to implement.

Integration Capabilities

Modern IT support does not happen in isolation. Your ticketing system needs to talk to other business systems such as:

• monitoring tools so alerts auto-generate tickets
• asset management system so device details populate automatically
• directory service so user information populates from Active Directory or Azure AD
• communication tools (e.g., Slack or Microsoft Teams) so technicians can receive alerts and update tickets without switching applications constantly

Self-Service Portal Quality

The self-service portal is an interface between your users and your support operation. A confusing portal increases phone and email volume when users give up trying to submit tickets online. A well-designed portal with a searchable knowledge base, intuitive ticket submission forms, and real-time ticket status visibility reduces overall support demand and improves user satisfaction.

Automation and Routing

The amount of manual triage work your team performs is directly proportional to how well the platform automatically routes tickets. An organization can reduce time to first response by creating routing rules that assign tickets to the right team based on category, keywords, and requestor attributes.

Reporting and Analytics

Spend time upfront verifying that a ticketing system fits your business operations. Before selecting a platform, spend time in the reporting module. Ask the following before choosing a ticketing system:

• Can you easily generate the metrics your management team cares about?
• Can you export data for further analysis?
• Can you build custom dashboards that display the information most relevant to your operation?

Jira Service Management

Jira Service Management (JSM) is a cloud-based, service desk platform from Atlassian that is used by IT, business operations, and development teams. IT support teams use JSM for managing service requests and incidents. Business operation teams use JSM to internal operations such as employee onboarding or payroll inquiries. Development teams use JSM to managing code deployments and collaborating with IT operations.

IT service management is the most popular feature of JSM and the focus of this blog post. The key features of JSM for IT support include:

• Customer Portal – A self-service hub where users (customers) submit tickets, search documentation, and check the status of service requests.
• IT Service Management – Tools for incident reporting, change requests, asset management and knowledge base management. JSM brings visibility to the work done by support teams and streamlines ticket workflows.
• SLA Tracking – Monitor response and resolution times for Service Level Agreements (SLAs).
• Intake from multiple channels such as web portal, email, or chat using Slack, or Microsoft Teams.

Create an Account

To create a free JSM account go to the Atlassian website, click on Products and then Jira Service Management. Enter an email, and click Sign up. After verifying your email, create a password.

Create Space for IT Support

After creating your JSM account, you will be directed to a page titled “Create a workspace” where you can create your first workspace (or space). Enter a name (e.g., techwayfarer) that will be used to create a URL for the space.

Since we are using the free version of Jira Service Management, the site will be a subdomain of atlassian.net. Click Continue.

You will be asked a few questions to set up you account. In the screen “What kind of work do you do?” choose “IT support.”

On the page “Welcome to Service Collection” click the “Create space” button.

On the page “Space Templates”, choose a template that will be used to create your new space. Click on either Service Management or IT in the left column. Then select “Basic IT service management.”

In the window titled “Basic IT service management” click the button “Use template.”

In the page “Create space” enter details about the space you are creating.

Choose a name for the space (e.g., Techwayfarer IT Support). The Key field will populate with initials that will appear before each ticket (e.g., TIS). In the Team type field choose “Information technology (IT).” In the Chanel access field choose Open so both support technicians (agents) and customers can submit requests/tickets. When done click the button “Create space.”

If you see a page displaying all the default request types for your new space click the button “Continue to space.”

Click on “Jira Service Management” in top left corner of the navigation bar. In the left menu click on Spaces to reveal your spaces. The space you created earlier will appear (e.g., Techwayfarer IT Support). Click on the Get Started tab.

Add Agents to Space

In this section more agents are added to the space (e.g., Techwayfarer IT Support). Then in a later section we will review the process of managing service request queues and resolving open tickets.

In the free version of JSM you are allowed a maximum of three agents to process service requests. When the JSM account was created earlier, the first user was given the role of Administrator.

To add two more agents to the space click on Jira Service Management in the top navigation bar, then click on the three dots next to the name of your space, and choose “Space settings.”

In the Space settings window click on Access and then “People and access.” Click on the “Add people” button.

A pop-up window opens titled “Add people to Techwayfarer IT Support.” In the “Names or emails” field enter the email address of the new agents. In the Role field choose “Service Desk Team.” Click the button “Add 2 people.”

The confirmation window explains that you can manage the new users in either the space settings or the User management window. Click OK.

Each new agent will receive an email explaining that the administrator has invited him to join the team. After clicking on “Accept invite” in the email, the agent will be directed to a page on atlassian.com asking him to confirm his email address. After email confirmation the agent’s account appears in JSM under Space Settings > Access > People and access.

Add Organization to Space

In this section we will add the name of the Organization into JSM. Click on Jira Service Management in the top navigation bar. In the left menu pane choose Spaces, then your new space (e.g., Techwayfarer IT Support), and then Customers.

In the Customers window choose Organizations and then the “Add organizations” button.

In the “Add organizations” pop-up window enter the name for your organization (e.g., Techwayfarer) and the Add button. Your organization now appears in the Customers window.

Add Customers to Space

In this section we will add customers to the space (e.g., Techwayfarer IT Support). Then in a later section we will create service requests under the customer accounts.

In the free version of JSM you are allowed an unlimited number of Service Desk Customers that can create service requests in your organization’s JSM account.

There are several ways of adding customers to JSM. You could use the same method described earlier when adding agents. You would open the Space settings window, then click on Access, then “People and access”, and then the “Add people” button.

We will use an alternative metho and add customers in the Customers window. Click on Jira Service Management in the top navigation bar, then the space for your account (e.g., Techwayfarer IT Support), and then Customers.

There are currently no real customers in our JSM account, only demo listings created automatically by Jira. Click the “Add customers” button. In the “Add customers” pop-up window enter the email addresses for the new customers. Then choose your organization, and click Ok.

Refresh the browser window and the new customers will appear in the Customers window with a status of Invited. Each new customer will be sent a verification email from Atlassian asking him to enter his full name and password. Then the customer can login to your organization’s JSM account and view the IT Support Portal. And the customer’s status will change from Invited to Active.

Request Types

A request type if a form that customers use to submit service requests in the portal. Request types are found in JSM at Space settings > Request management > Request types.

Service Requests vs Incidents

JSM distinguishes between Service Requests and Incidents. According to Jira, service requests are planned inquiries from customers who want new resources or access to files and applications. Below are the service requests available in the Basic IT Service Management template we chose earlier when setting up the account.

According to Jira, incidents are unplanned service disruptions that require immediate resolution. Below are the two default incident types. You can add more request types to your account by clicking on the button “Create request type.”

Each organization will determine whether an issue classifies as a Service Request or a System Incident. Later in this post we will create example Service Requests and System Incidents.

Modify Request Types

To modify a service request or incident, click on its name in the “Request type” field. You can modify the instructions and fields visible in the customer facing support portal.

Workflow Status

A service request passes through various stages (or a workflow). A customer or agent opens a request and then the status is updated (manually by the agent or automatically by the system) until the issue resolved. To see the workflow stages available for a request type, click on its name in the “Request type” field and choose the “Workflow statuses” tab.

We will return to the stages (or statuses) of a request in a later section when we walk through an example service request.

Queues

Queues are saved searches of service requests that agents use to view, organize, and prioritize tickets. Queues filter requests using criteria such as status or priority. The queues used by the organization are listed in JSM under Space Settings > Request management > Queues.

When our JSM account was created in an earlier step, three queues were provided by default: All open, Assigned to me, and Open tasks.

Common queues are: new tickets, high priority, and aging tickets. We will create a High Priority queue. Go to Queues in Space Settings and click on the button “Create queue.”

Enter a name in the “Queue name” field.

Leave the field “Assign to priority group” blank. Our lab has only a few agents and there is no need to use priority groups.

Under “Filter by” click on “More filters” and choose Priority, which will then appear in the Filter by list. Click on Priority in the list and choose the criteria. The options are Highest, High, Medium, Low, and Lowest. Choose Highest and High.

Under Columns add Priority so the field is visible in the list of High Priority requests.

Scroll down and click the Create button.

The High Priority queue will now appear in the list of queues in JSM under Space Settings > Request management > Queues.

Create Service Requests

In this section we will explore the various ways that service requests can be created in JSM by customers and agents. In an organization users and agents can create requests using either the portal, email, or chat using Slack or Microsoft Teams. Agents can also manually create a new service request when logged into the back end of JSM.

In the following sections we will create service requests using:

• Emails from customers
• The IT support portal that is accessible by customers and agents
• The Create button, found on the navigation bar, that is accessible by agents when logged into the organizations JSM account

In later sections of this post we will triage the requests in the service queue. And we will walk through an example of resolving a support request.

In “Space settings” click on “Channels & self service.” Four channel options are listed for adding service requests: Email, Portal, Widget, and Chat. We will begin with email.

Emails

Customers can send emails to specific email addresses in order to create servicer requests. In this section we will add an email address for service requests at Space Settings > Channels & self service > Email.

When using a free version of JSM, the domain assigned to your account will be in the format companyname.atlassian.net. When your account is created a default email is created for receive service requests for customers (e.g., tis@techwayfarer.atlassian.net).

Add another email by clicking the button “Create Atlassian email.” In the pop-up window enter the email address. Choose who will be notified when email send to the address fail to create a service request. And choose the “Request type” that will be assigned to the service request. Then click Create.

The new email address is added to the list of connected email accounts. Under “Replay-to-address” change the email address to the one just created (e.g., support@techwayfarer.atlassian.net) and click Update.

We will test whether support requests can be created by email. We will send a support request from a customer’s email account (e.g., farrah@techwayfarer.com) to our new support request email address (e.g., support@techwayfarer.atlassian.net).

When we click on the title of the request in the “Open service requests” window, we are taken to the details of the request. The subject line of the email became the title of the request. The body of the email is included in the “Key details.” The customer (Farrah Fawcett) is identified as the reporter. And the SLA status is shown in the right column.

Support Portal

The portal is often the primary way that customers create service requests in JSM. In the Get started tab of your new space, click on “Try your portal.” You are taken to the default support portal for your space where users and agents in the organization can open a new request.

Portal Settings

The portal settings are found in JSM at Space Settings > Channels & self service > Portal. The “Portal configuration” tab changes the appearance of the portal including the message and logo. You can also scroll down and under Announcements allow agents to add messages to the top of the portal.

Announcements

Announcements can be added to the top of the portal that inform customers of current support issues. To create an announcement, at the top of the support portal click on Customize > Manage announcements. Fill out the announcement and click Save.

The announcement and logo are now visible in the portal.

Modify Portal Groups and Request Forms

Portal groups are used to organize request forms. So customers can more easily find the appropriate request form in the portal and create a new service request.

Under each portal group is a list of typical request forms. IT administrators can modify the portal groups and the request forms listed under each group.

The portal groups can be modified in JSM at Space Settings > Channels & self service > Portal > Portal groups tab. Click on a down arrow button for a portal group to see the related request forms, modify the order of the forms, and add a new request form.

Help Center

In JSM the Help Center acts as a homepage for accessing all the project portals in an organization. There is a separate Portal for each service project (e.g., IT Support or Human Resources).

To access the Help Center click on the link in the top left corner of the IT Support Portal. Below is the default look of the Help Center.

To customize the Help Center click on Customize. In the Customize menu choose “Customize look and feel” to modify the name, title and logo for the Help Center. And choose “Manage topics and portals” to feature a portal in the Help Center or add Topics that bring together request forms, knowledge articles and links to external resources.

Below the Help Center has been updated with a different title and a featured portal.

Create Requests in Support Portal

In this section we will illustrate how customers can create service requests in the support portal.

Logon to JSM using a customer account (e.g., farrah@techwayfarer.com). In the IT support portal click on the portal group “Common Requests.”

Click on a service request type (e.g., Report broken hardware) to open the request intake form. Fill out the fields with an example ticket of a user reporting broken hardware (e.g., monitor not working).

Click send. A verification pop-up will appear stating that the ticket was created successfully. And the reporter will see a summary of the request that was just created.

We will add more example service requests. Then in a later section we can triage the requests.

After creating the service requests, an agent (e.g., henry@techwayfarer.com) can view them in JSM by opening the IT Support space and choosing Service requests > Open service requests.

Create Button

Agents can open a System Incident or Service request using the Create Button found in the top navigation bar of JSM. Agents may create a service request after talking with a customer. Or an agent may open a System Incident after discovering a significant issue that needs to be addressed quickly.

Login to JSM using an agent account created earlier (e.g., henry@techwayfarer.com). Click the Create button in the top navigation bar to open the form.

In our example, the inability of the sales staff to access the CRM can significantly affect business operations. So the issue is classified as a System Incident instead of a Service Request.

We will use the Create button to add another Service Incident related to the Enterprise Resource Planning (ERP) being down. Since ERP affects many business operations it is classified as a critical System Incident.

After creating the two system incidents, an agent can view them in JSM by opening the IT Support space and choosing Incidents > Open incidents.

Triage Requests and Incidents

Triage is the process of reviewing, sorting, prioritizing, and assigning incoming customer requests or incidents as they are created in JSM. We will triage the Service Requests and System Incidents created earlier.

An agent can view all open requests and incidents in JSM by opening the IT Support space and choosing Queues > All open. Agents often take turns triaging open issues in JSM. In our example, today is Henry David Thoreau’s turn.

Workflow Example

Escalate Tickets

Basic Reports

Set up SLAs

To Do

Get ideas for this post from: (1)hands on videos in Udemy Jira training program by Robert Hean and (2)the Youtube video by Stewart Gauld.

Show channel options – portal, email, chat

portal settings – announcements, modify portal

portal groups – how to modify

service requests vs incidents

how to customize request types

Create 2 service requests for each severity level using the names of users and agents. Create requests using portal and email.

Conclusion

A ticketing system that is correctly implemented is an operational infrastructure that makes it possible for IT support teams to do their best work consistently, at scale, with full accountability.

It protects users from having their issues lost in the noise. It allows technicians to do their best work in a timely manner that meets user expectations. It ensures that IT operations can be measured, optimized, and continuously improved.

Whether you are a help desk technician learning the ropes on Jira Service Management or a senior IT manager evaluating a migration to Jira, the principles covered in this guide remain constant: capture the right information, prioritize with intention, communicate proactively, document everything, and let the data you generate inform how you work tomorrow. The best ticketing systems empower technicians to efficiently support users and the organization. And the best technicians treat the ticketing stem as an asset and use it correctly to complete their work.