Home Lab: IT 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 Levels

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	Impact	Example Scenario	Standard Response Time	Standard Time to Resolve
Highest / Critical (P1)	Organization-wide or business-critical system, no known workaround	A core ERP system is down, and no one can process transactions.	30 minutes	4 hours
High (P2)	Serious problem, significant functional impact, affects large user group	The sales team’s CRM is inaccessible during a quarter-end push.	1 business hour	8 business hours
Medium (P3)	Default priority, minor issue, low time sensitivity, affects single user or small group, workaround available	An employee’s laptop has a broken keyboard, but they have a spare.	4 business hours	24 business hours
Low (P4)	Minor issue with easy workaround	A typo exists on the company website	8 business hours	48 business hours
Lowest (P5)	Trivial issue, non-pressing, convenience, future need	A request to install a new font package for design work.	24 business hours	60 business 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 — Open Ticket

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 a lower level support agent hands off a ticket to a higher level agent to resolve. Escalation occurs when:

• The assigned technician reaches the limit of his expertise, diagnostic tools, or authorization. For instance, An issue might require specialized expertise to resolve.
• After reviewing an issue, an agent assigns a higher priority level to the ticket.
• A ticket has been left unresolved for too long and is about to exceed the resolution time limit established in the SLA.

There are many benefits to escalation. Tickets get resolved more efficiently. Support teams improve their resolution times. And customer satisfaction improves.

When a ticket is escalated both the reporter and the higher level agent should be notified. Communication with the reporter helps to manager his expectations. The reporter should receive:

• an explanation of why the ticket is being escalated
• the name of the new agent working on the ticket
• the estimated time to resolution.

The higher level agent should be given the information needed to quickly resolve the issue. The warm handoff should include:

• Comprehensive notes that summarize the issue and document the steps taken so far to resolve the issue.
• Screenshots and pertinent documents from the organizations knowledge base.
• Notes from the reporter

Escalations are sometimes done my mistake. An organization can avoid unnecessary escalations by training agents about when and how to properly escalate a ticket. Lower tier agents should also be empowered to access documentation and resolve tickets on their own. Support manager should review escalations on a regular basis to look for areas of improvement.

De-escalation occurs when a ticket that has been escalated is sent back to the original agent. The initial agent may need to gather more information before the higher level agent can begin working on the ticket. Or the initial agent may have escalated the issue to the wrong person.

Escalation works best when an organization has defined guideline regarding when to escalate a ticket.

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 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.

SLAs help to prioritize tasks correctly based on the impact to business operations. 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 acknowledges 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
Highest / Critical (P1)	30 minutes	4 hours	Immediate escalation to IT leadership; incident review required
High (P2)	1 business hour	8 business hours	Automatic escalation to senior technician; manager notified
Medium (P3)	4 business hours	24 business hours	Supervisor alert if SLA metric is approaching
Low (P4)	8 business hours	48 business hours	Logged for performance reporting; no immediate escalation
Lowest (P5)	24 business hours	60 business hours	Logged for performance reporting; no immediate escalation

SLA clocks typically run during business hours. They are usually paused during off-hours or while waiting for a customer to respond with more information about an issue.

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

Performance reports offer a lot of benefits. With reports organizations can track SLA performance, including tickets that are approaching their SLA deadlines. They can identify trends in tickets and use the information to improve business operations or identify technicians who need more training.

Ticketing system reports are not just for management. They are a tool for every member of the support team to understand where demand is coming from and whether their performance is improving over time. 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. In our lab, Henry David Thorough is a tier 1 agent, and Ralph Waldo Emerson is a tier 2 agent.

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.

Set up SLAs

A Service Level Agreements (SLA) is the contract a support team has with an external or internal customer for delivering support services. In this section we will explore how to configure SLAs in JSM so they align with your contracts and can be used to track the support team’s performance.

The support administrator can modify the SLAs in JSM by going to Space Settings > SLAs.

By default JSM has provided three SLAs:

• time to first response
• time to resolution
• time to close after resolution

We will walk through how to make changes to the default SLA settings for “time to resolution.”

JSM differentiates between Incidents and Service Requests. Incidents are the unplanned events that require immediate attention. Service requests are planned events scheduled by customers. We will modify the resolution times for Incidents and Service Requests to align with the times provided earlier in the Priority Levels section.

Click on Edit next to “Time to resolution.” Repeat the following steps for Incidents and Service Requests:

• Change the calendar for the Highest priority from 9-5 to 24/7.
• Click “Add priority” and add the Lowest priority.
• Change the resolution times.

Scroll down to Conditions. Under “Pause counting time during” add the statuses Pending, Waiting for customer, and Waiting for approval. Then the support team will not be penalized when they are waiting for someone else to move the ticket forward.

When all the changes are made click Save.

Request Types

A request type is 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

A service request passes through various stages (or a workflow). A customer or agent opens a request and then the status is updated (either manually by the agent or automatically by the system) until the issue is resolved.

In the earlier section Request Types we viewed a list of the current service requests types. The third column shows the workflow used by each service request type. They are all using the workflow “TIS: Service Request Fulfillment workflow for Jira Service Management.” We will view the details of the workflow.

The workflows available in JSM are found at Space settings > Request management > Request types > Workflows.

In the Workflows page click the diagram link below the workflow “TIS: Service Request Fulfillment workflow for Jira Service Management.” A pop-up windows displays visual representation of how a ticket can move between the statuses.

The workflow for a service request can be modified in JSM to align with an organization’s process of resolving tickets. We will modify the “Service Request Fulfillment workflow.

In the Workflows page, click on the link “Edit workflow.” A page opens where the workflow can be modified. Statuses appear in the first column Transitions appear in the second column.

For the status “Waiting for customer”, we are going to modify the Transition “Respond to Customer (851).” Click on the transition name and a third column opens titled “Transition.”

Scroll down in the third column to Path > From statuses. Click on the down arrow button and check the box next to “In Progress.” The status “In Progress” is added to the list of statuses that can precede the status “Waiting for customer.” Click the button “Update workflow.”

Later in this lab we will walk through a Workflow Example in which we will need to transition the status from “In Progress” to “Waiting for Customer.”

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.

Reports

JSM has default reports that provide useful information for tracking performance by the support team. You can also create a custom report such as “Time to first response.”

Open Tickets

In this section we will explore the various ways that tickets (service Requests or incidents) can be created in JSM by customers and agents. In an organization customers 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:

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

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 David Thoreau). 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.

Email

A customer can send an email to a specific email address in order to create a servicer request. 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 provides the URL to the customer portal (e.g., https://techwayfarer.atlassian.net/servicedesk/customer/portal/3). It also provides the option to change the appearance of the portal including the message and logo. And you can 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 Tickets in the Support Portal

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

To access the portal a customer needs the URL that might be provided a wiki page or an email from an agent. In an earlier step we found the customer portal URL in JSM at Space settings > Channels & self service > Portal > Portal configuration tab. In our lab the portal URL is https://techwayfarer.atlassian.net/servicedesk/customer/portal/3.

Go to the customer portal and when prompted login as a customer (e.g., Jaclyn Smith). In the IT support portal click on the portal group “Common Requests.”

Click on a service request type (e.g., Get IT help) to open the request intake form. Fill out the fields with an example ticket of a user reporting broken hardware (e.g., VPN 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 David Thoreau) can view them in JSM by opening the IT Support space and choosing Service requests > Open service requests.

Keep in mind that in Jira open Service Requests and open Incidents are found in two different locations in the menu. Incidents are found just below Service Requests in the menu for your IT support space (e.g., Techwayfarer IT Support).

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 tickets 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, it is Henry David Thoreau’s turn.

The triage process for each organization may differ. Our example organization (Techwayfarer) triages new tickets by:

• deciding upon the correct priority level
• assigning an agent to work the request or incident.

Below are the details for one of the open tickets. In the Assignee field we see that Henry David Thoreau assigned himself to resolve the ticket. The Priority field is marked as Medium.

After triaging the remaining open tickets, the All Open queue shows the Assignee for each ticket. Henry David Thoreau is a tier 1 agent, so he is given the low and medium priority requests. Ralph Waldo Emerson is a tier 2 agent, so he is given the high and critical priority requests.

Workflow Example

In this section we will walk through the lifecycle of a single support ticket. We will return to the example used in earlier sections in which a customer’s “VPN is not working.”

The path a ticket follows from inception to resolution may vary depending on the:

• Type of ticket
• Ticket priority level
• Structure of the support team
• Responsiveness of the reporter
• Resources available to agents for resolving issues

In the earlier section Ticket Lifecycle we described eight stages of a normal support ticket. In our example ticket the stages are combined into the followin steps:

1. Create ticket
2. Triage
3. Gather more information
4. Escalate to a higher level support agent
5. Resolve and follow-up – the agent resolves issue, confirms resolution with reporter, and closes ticket
6. Analyze ticket – identify areas for improvement

Step 1: Create Ticket

In the earlier section How to Open Tickets we described the various ways that a service request or incident can be created by a customer (email, customer support portal, chat using Slack or Microsoft Teams), or by an agent using the Create button in JSM.

Earlier we also created the example ticket “VPN not working” in the support portal. Below is a quick summary of the process.

A user is provided a URL (e.g., https://techwayfarer.atlassian.net/servicedesk/customer/portal/3) to the customer-facing support portal.

The customer clicks on a portal group (e.g., Common Requests) and a request type (e.g., Get IT help) and fills out the required fields.

After opening a ticket the customer can view it by logging into support portal, clicking on their avatar in the top right corner, choosing Requests, and then opening the new ticket.

In the “Add request participant” field the customer can share the ticket with others, who can then view the ticket and receive status updates. In our example, Jaclyn shared the ticket with Farrah Fawcett.

When viewing a ticket soon after it is created, a customer might also be able to add additional language or attachments.

Step 2: Triage

Agents can view a new ticket in the JSM service queue by opening the IT Support space and choosing Queues > All open.

In an earlier section we triaged the ticket “VPN not working.” To review, the agent triaging an open ticket decides upon the priority level (e.g., low, medium, high, highest). And he assigns an agent to resolve the issue based on the team structure (e.g., tier 1 agents work low and medium issues, and tier 2 agents work high and critical issues).

Step 3: Gather More Information

In this step the assigned agent reviews the ticket in greater detail to see what information has been provided by the customer and what information is still needed to resolve the issue.

Customers often do not provide enough information in the initial ticket for the agent to begin working on the issue. In our example ticket (VPN not working) an agent might need to know the type of error message the customer receives when attempting to logon to the network with her VPN app. And he might need to know which version of the VPN app the client is using.

We will go to the Activity section of the open ticket and open Comments > Reply to customer. And we will send the customer a message requesting more information.

In the message it is helpful to acknowledge the customer’s issue and explain why you are requesting more information. Comments posted in “Reply to customer” are publicly visible by anyone with access to the support portal.

After clicking Save the customer will receive an email with the response from the agent. The customer can then login to the support portal and respond with the needed information.

The “Similar requests” field in an open ticket might be set up to search past tickets that involve the same subject. In our lab, we have yet to create past tickets related to VPN issues, so no results appear.

We will also change the status of the ticket. In the top right corner of the open ticket click on the status button and change the status from “Waiting for support” to “Waiting for customer.”

A pop-up window will appear that has to be filled out before the status can be changed. You can choose whether the comment is an internal note or a reply to the customer. Since we already sent a reply to the customer we will choose “Add internal note”, then enter the internal comment, and click Update.

The internal note appears with a yellow highlight at the bottom of the Activity list. It is only visible by agents with access to the organization’s JSM account.

In the right column the SLA shows the clock is paused because we have yet to set up the SLA feature for the space.

We now switch back to the customer’s view of the portal. Under Activity the customer can see the message from the agent and the status update. She cannot see the internal note created by the agent.

The customer replies to the agent and clicks Save.

We switch back to the agent’s view of the ticket. The agent can view the ticket in the Queues > All Open.

Automations

JSM can be setup with automations that take actions based on triggers. For instance, a customer responds to a agent inquiry and the ticket status changes from “Waiting for customer” to “Waiting for support.” And the agent might get an alert letting him know the agent has responded to his inquiry.

In our lab the automations have not been setup in JSM. Even though the customer has responded the status still shows “Waiting for customer.”

Without automations that change the status, the agent has to periodically look at his open tickets and update the status as needed.

Step 4: Escalate

Escalation is the process of assigning a ticket to an agent who has a higher level of support, greater system access, or more knowledge to resolve the issue. In our lab there are two agents. Henry David Thoreau is a tier 1 agent, and Ralph Waldo Emerson is a tier 2 agent.

Henry is currently assigned to the ticket. He periodically reviews his open tickets. He views the details of the ticket “VPN not working” and sees the customer’s reply. The customer said she is using VPN version 5.

At this point in the resolution process Henry might reach out to others in his support team for assistance in resolving the ticket. Or he might look at the organization’s support documentation (knowledge base or wiki) to find troubleshooting steps or a solution.

When working open tickets agents may have access to a documentation that provides guidance on how to resolve the issue. Agents should be encouraged to create or update documentation in the course of resolving tickets. Thorough documentation reduces guesswork and helps agents close tickets more quickly.

After reading the documentation, regarding VPN version 5, Henry realizes the ticket should be escalated to someone with more knowledge and access. The documentation might include a chart with issue types and the agents who should be assigned the tickets. Henry sees that Ralph is the agent designated to resolve tickets involving VPN version 5.

Henry now performs a warm handoff of the ticket to Ralph. Henry adds an internal note on the ticket explaining why the ticket is being assigned to Ralph and any information that might help Ralph resolve the issue. Ralph is at mentioned in the note so he receives a notification about the new ticket assigned to him.

Henry also changes the ticket status to Escalated. A pop-up window appears that has to be filled out. Henry choose reply to customer and sends Jaclyn a message letting her know that another agent (Ralph) will now to be working on the issue. Keeping the reporter informed about the ticket helps to manage her expectations and reduce her frustration in waiting for the ticket to be resolved.

Henry changes the Assignee on the ticket to Ralph and is done working on the ticket.

Step 5: Resolve and Follow-up

In this step the ticket is resolved by the tier 2 agent, Ralph. We will begin by logging into JSM as Ralph. In the IT support space under Queues > Assigned to me, we see the ticket “VPN not working” with a status of Escalated.

Ralph clicks on the newly assigned ticket to open the details and read the prior notes. Then he changes the ticket status to “In progress” and is required to create a comment. He sends a message to the customer (Jaclyn) letting her know he is working on the issue.

Ralph then works on resolving the issue. When he believes the issue is resolved, he clicks on the status button to change the status from “In Progress” to “Waiting for Customer.” In the earlier section Workflow we modified the transition “Respond to Customer” and added “In Progress” to the list of statuses that can precede the status “Waiting for customer.” Because of our modification to the default workflow, we can choose “Waiting for customer” as the next status.

Under the list of possible next statuses, you can click on “View workflow.” It shows the current status, the options for the next status, and the path a ticket can take in JSM.

The agent chooses “Waiting for Customer” as the status. Then in the pop-up window he sends another message to the customer explaining what he has done and asking her to confirm that the issue is resolved.

We now go back to the customer’s view of the ticket. The customer sees the message from Ralph asking her to confirm the issue is resolved. After verifying that her VPN is working, the customer sends a message to the agent.

When the agent receives the message from the customer, confirming the issue is resolved, he changes the status to Resolved and enters a final message to the customer.

The Resolved status identifies to the support team that work is completed on the ticket.

The final status in our workflow is Closed. For many organizations a ticket is moved from Resolved to Closed after a waiting period that gives the customer time to reopen the ticket if additional help is required.

Step 6: Analyze Ticket

Support teams should routinely review closed tickets that involve the same type of issue (e.g., VPN). There may be commonalities among tickets that if resolved could reduce the need for opening similar tickets in the future.

In our example business, a support administrator created a new queue “Resolved, Done, Closed” that lists all tickets that have a status of resolved, done, or closed. The support staff can further filter the queue to find tickets involving the same issue.

If we click on the two tickets related to VPN, we can see the details of each ticket such as the issue faced by the customer and how the issue was resolved by the agent. Both tickets were related to a particular version of the VPN app. It may prevent the customers from logging on to the network. And after a certain number of login attempts the customer’s account might be locked. If we are correct and the VPN issue can be resolved, then fewer tickets will be opened for the same issue in the future.

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.

To Do

add featured image

Image size – change many to 800 px wide.

Automation – explain automation in Jira

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.

portal groups – how to modify