Jira from Both Sides of the Help Desk

As an Army cyber officer in a technical field, Jira became a valuable tool to me as both an analyst and a team manager to track intelligence and operational requests between teams. From my team using it from both a user and manager perspective, I'll be mapping how Jira can be used in an IT help desk context to optimize flows and efficiency.

The Technician Perspective

If you've ever submitted a ticket for an IT request and then checked it every 30 min wondering why nothing has moved, then you already understand half of the battle of ticketing systems and what makes a good help desk technician. Setting up a ticketing system that empowers technicians to work efficiently and give clarity to customers is key.

A little background before I get into the mechanics: I came to Jira as a solution in the Army for managing operational requests from within the intelligence side of our team for us to action. There was a sentiment from that side that their requests weren't being actioned whereas our operational side felt that that wasn't the case. To reduce animosity and increase clarity, I implemented a Jira project for intra-team requests. Translating this same idea into IT service context is very natural. After all, a ticket is just a task based on a customer need, no matter the organization.

The Ticket Lifestyle

Every Jira ticket moves through a workflow of statuses, usually something like: Open -> In Progress -> Pending/Waiting on Customer -> Resolved -> Closed. A technician is responsible for ensuring tickets are moving and not stagnating without good reason.

When a technician is assigned a ticket, the first to-do is triaging the request - What do they need? What is the priority? Can I resolve this or do I need to escalate? Jira can help immensely here as you can assign priority labels, choose to move the ticket to an escalation state which will auto-assign it to a more senior technician, and even track Service Level Agreement (SLA) timers if your organization is using Jira Service Management (JSM) to see how much time has elapsed since the ticket was actioned.

A technician can help themselves and their organization by filtering and sorting their queue! First understand what is most important to your customers and organization. Do they value response time most? Would they understand if low priority issues aren't actioned immediately? Once you understand that, set up your personal board view to organize the to-do and in-progress issues so that they are actioned according to your customers' priorities. It's likely a helpdesk manager will have already configured a helpful view but some technicians prefer to customize them further.

Good Ticket Notetaking

Now that we can see the tickets to action and have one in hand, it's time to work! While actioning an issue, it's imperative to write good ticket notes in case the issue needs to be passed along to someone else or re-visited at a later date. Here are some tips for writing good ticket notes:

• Be efficient/TLDR. Keep your notes concise while still documenting all necessary information. If the next technician getting your notes sees a 5-paragraph essay on the ticket, there's a high chance they will skim it and miss important information.

• Don't over-document. Along the same principle, there's some information that would be overkill. For example:

  • *Ticket #1042 — Resolution Note
    Opened: 09 Apr 2026, 08:32:14 AM KST Assigned to: Technician D. Smith, Tier 1 Help Desk, Building 4, Desk 12B
    Last updated: 09 Apr 2026, 09:47:52 AM KST
    Time to first response: 4 minutes 17 seconds
    Total time in queue: 1 hour 15 minutes 38 seconds

    At 08:32 AM KST on 09 Apr 2026, a ticket was submitted via the customer portal by user J. Rodriguez, Department of Operations, Employee ID #447821, located in Building 2, Room 114, Workstation WIN-OPS-0042, running Windows 11 Pro version 22H2 build 22621.3155, connected to the CORP-NET-02 network on IP address 192.168.4.87, using Cisco AnyConnect VPN client version 4.10.06090.*

    At 08:36 AM KST, technician made first contact with user via Microsoft Teams chat. User confirmed they were at their desk. User stated they had been on leave from 28 Mar 2026 to 08 Apr 2026 and had not attempted to log in during that period. User confirmed they were using their standard government-issued laptop. Technician asked user to confirm operating system. User confirmed Windows 11. Technician asked user to confirm VPN client version. User confirmed Cisco AnyConnect. Technician asked user to confirm they were on site or remote. User confirmed on site.

    Aaaaaaand if you're still reading this you have already lost interest! How's this next one in comparison?

  • Ticket #1042 — Resolution Note
    Issue: User unable to authenticate to VPN client after returning from leave. Credentials rejected at login despite correct password entry. Cause: AD password had expired on 07 Apr 2026 during user's absence. Cisco AnyConnect authenticates against AD credentials, so the expired password blocked the session before it could establish.
    Resolution: User reset password via self-service portal. VPN access confirmed restored post-reset. User advised of 90-day expiration policy and recommended setting a calendar reminder ahead of future leave periods.

• Take Notes as You Work. Have you ever received a ticket expecting it to only take a few steps and it turns out taking hours? As you resolve the ticket and go to leave a resolution note, your brain blanks...you've been working on this for hours already and you can remember most of what you did...right? Probably, but it is much easier to write a comprehensive concluding note when you documented your steps the whole time, I would recommend Notepad++ for an easy solution.

Quick Wins

Before we get into the manager side of Jira, here are two technician tricks worth knowing that most people discover way too late.

1. Press ? anywhere in Jira to pull up the full keyboard shortcut list. Learn the ones for navigating between tickets and updating statuses. On a high-volume queue day it adds up faster than you'd expect.

2. Use the Clone button for repeat request types like password resets or standard software installs. It copies the ticket structure so you're not rebuilding from scratch every time. Just know that Jira automatically creates a "Clones / Is cloned by" link between the original and the new ticket...not a problem, just something to be aware of if your manager is auditing ticket relationships. The link can be removed manually. Comments and work history don't carry over either, which is usually exactly what you want for a fresh incident.

The Manager Perspective

Managing a help desk is less about knowing every technical answer and more about building systems that produce consistent behavior without you standing over anyone's shoulder. If your technicians are skipping workflow steps, leaving tickets in the wrong status, or writing one-liner resolution notes, the problem is usually that nothing in the environment is stopping them from doing so. Jira gives managers the tools to fix that at the system level.

Enforcement through Design, not Discipline

The most powerful thing you can do as a Jira manager is make doing the right thing the path of least resistance. If a ticket can only transition from "In Progress" to "Resolved" after a resolution field is filled in, technicians can't close tickets without documenting the fix because Jira won't let them proceed otherwise. Required fields, mandatory transitions, and approval gates encode your SOP directly into the tool so it enforces itself.

Here's a quick tutorial on how to create workflows for your Jira project:

https://www.youtube.com/watch?v=JTIhs0pYQ8I

Automation

Rather than manually monitoring approaching SLA breaches, automation can trigger progressive escalations. For example, if a high-priority request remains unassigned for 30 minutes, the system can automatically reassign it to a senior technician and notify the service desk manager. Set it and forget it! The same logic applies to auto-assigning tickets by request type, nudging technicians on stale tickets, and sending customers status updates. Every automation rule is a task you're no longer doing manually.

Here are some useful automation rules to consider using:

1. Auto-assign by workload - when a ticket is created, automatically assign it to the team member with the fewest open tickets so nothing sits unowned in the queue.

2. SLA breach warning - trigger a notification to the assignee and yourself 30 minutes before a ticket hits its SLA deadline.

3. Auto-close inactive tickets - run a daily scheduled rule that finds tickets waiting on a customer response for 7+ days, closes them, and leaves a comment explaining how to reopen; keep your queue an accurate picture of actual work.

Use the audit trail as a coaching tool

Every comment, field change, and action is logged automatically...perfect for IT governance, compliance audits, and post-incident reviews. It's also how you can have an honest conversation with a technician who isn't following SOP. Pull up the ticket and audit logs together. Technicians who know their work is visible tend to self-correct before it becomes a pattern.

https://support.atlassian.com/jira-cloud-administration/docs/audit-activities-in-jira-applications/