Most IT support teams know the feeling of a queue that never seems to shrink. Tickets pile up, agents jump between requests without a clear sense of priority, and users send chase emails because nobody has updated them. The team is busy, but the work does not feel like it is moving. That gap between effort and outcome is almost always a workflow problem, and workflow problems in Jira Service Management are almost always configuration problems.
The encouraging part is that configuration problems are solvable. Unlike staffing shortages or budget constraints, a poorly configured service project is something a team can fix without waiting for approval or resources. The right changes to how Jira Service Management is set up can change the daily experience of support work significantly, for agents, for team leads, and for the users raising tickets.
Understanding What Jira Service Management Configuration Covers
Jira service management configuration is the complete set of decisions that determine how a service project behaves. It covers the portal that users interact with, the forms they fill in, the queues agents work from, the workflows that govern ticket movement, the SLA policies that measure performance, and the automation rules that handle repetitive steps without human intervention.
Every one of those areas connects to the others. A queue that surfaces the wrong tickets wastes agent time. A workflow that does not match the real process creates confusion about where things stand. An SLA policy without proper pause conditions makes performance look worse than it is. Configuration that has been set up thoughtfully across all of these areas produces a support operation that runs with far less friction than one built on defaults and workarounds.
The tips in this article address each of those areas with specific, actionable guidance that teams can apply to an existing setup or use to build a new one properly from the start.
Tip One: Build Request Types Around What Users Actually Need
Request types are the foundation of the customer portal. They define the categories of help users can ask for and the forms they fill in when raising a ticket. When request types are well designed, users raise the right kind of ticket with the right information. When they are poorly designed, agents receive vague requests that require back-and-forth before any real work can begin.
The starting point for good request types is a clear list of the support needs your users actually have. Password resets, hardware faults, software access requests, network issues, new starter setup, and application errors are common categories for IT support teams. Each of these is a distinct need that benefits from a distinct request type with fields relevant to that specific request.
The fields on each request form should be designed from the agent’s perspective. What information does the agent need to begin working on this issue without asking the user for anything else? For a hardware fault, that might be the device type, a description of the fault, and the user’s location. For a software access request, it might be the application name, the type of access needed, and the name of the approving manager. Capturing this at the point of submission removes a round of communication from every ticket.
Portal naming matters as much as form design. Request type names should use the language that users use, not IT terminology. Help with my laptop works better than hardware incident. Request software access works better than ITSM access provisioning. Clear names reduce the number of tickets raised under the wrong category and make the portal feel approachable rather than technical.
Tip Two: Organise Queues to Match Agent Workflows
Queues are where agents spend most of their working time in Jira Service Management. A queue setup that does not reflect how the team actually works forces agents to make decisions about priority and assignment that the system should be handling for them.
The most effective queue structures are built around the questions agents ask at the start of their shift. What is urgent right now? What is unassigned and needs picking up? What is approaching an SLA deadline? What is waiting on a user response? Each of those questions deserves its own queue, built on a JQL filter that answers it precisely.
Beyond the shared team queues, individual agent queues that show each person their own open tickets sorted by priority give agents a clear view of their personal workload without having to filter through the whole team’s work. This is a small change that consistently reduces the time agents spend figuring out what to do next.
Queue names should be descriptive enough that agents can navigate them without explanation. Urgent and critical, unassigned tickets, near SLA breach, and waiting on customer are clearer than queue one, queue two, and queue three. When the queue name tells the agent what they will find inside it, the whole system becomes easier to navigate.
| Queue Name | JQL Filter Logic | Primary Purpose |
| Urgent and critical | Priority in Critical, High AND status not Done | Surfaces highest priority work immediately |
| Unassigned tickets | Assignee is EMPTY AND status not Done | Ensures nothing gets missed |
| Near SLA breach | SLA breached or within 1 hour of breach | Enables proactive action before breach |
| Waiting on customer | Status is Waiting for Customer | Tracks paused tickets needing user response |
| My open tickets | Assignee is current user AND status not Done | Individual agent workload view |
| Raised today | Created date is today | Tracks new volume and response rate |
| Overdue tickets | SLA breached AND status not Done | Post-breach management and escalation |
Tip Three: Design Workflows That Reflect the Real Support Process
Workflow design is where many Jira Service Management configurations fall short. Teams accept the default workflow or build one that looks logical on paper without testing it against the actual steps their support process follows. The result is a workflow that agents work around rather than through, and a board that does not reflect the true state of the work.
A good workflow for IT support maps directly to the stages a ticket genuinely moves through. Intake covers the period between submission and triage. In triage, the ticket is reviewed, prioritised, and assigned. In progress means an agent is actively working on it. Waiting on customer means the next action belongs to the user. Resolved means the fix has been applied and the user has been informed. Closed means the ticket has been confirmed as complete.
Each transition between those stages should have a clear meaning and, where appropriate, a rule that enforces the conditions for moving forward. A ticket should not be able to move to resolved without a resolution category being set. A ticket should not be able to close without either the user confirming satisfaction or a defined period passing after resolution. These rules make the workflow self-enforcing and produce cleaner data for reporting.
The waiting on customer status deserves particular attention. Without it, tickets that are blocked by the user appear as overdue when the team has done everything within its control. Including this status and configuring the SLA policy to pause when a ticket enters it produces fairer performance measurements and reduces the frustration of agents whose SLA statistics are affected by factors outside their control.
Tip Four: Configure SLA Policies That Measure What Matters
SLA policies are how IT support teams track whether they are meeting their commitments. Getting the configuration right means setting targets that reflect real expectations, pausing the clock when appropriate, and running SLAs against business hours rather than calendar time.
Most IT support teams need separate SLA targets for different priority levels. A critical incident blocking multiple users requires a response in minutes. A low-priority software query can wait until the next business day. Applying the same target to both misrepresents performance in both directions and removes the incentive to triage accurately.
Business hours configuration prevents tickets raised outside working hours from appearing as breached when agents arrive in the morning. A ticket raised at seven in the evening on a Friday should have its SLA clock start at nine on Monday morning, not run continuously through the weekend. This requires a named calendar in the configuration that defines the team’s working hours and excludes bank holidays.
| Priority | First Response Target | Resolution Target | SLA Clock Behaviour |
| Critical | 15 minutes | 2 hours | Runs continuously including out of hours |
| High | 1 hour | 4 hours | Business hours only |
| Medium | 4 hours | 1 business day | Business hours only |
| Low | 1 business day | 3 business days | Business hours only |
| Service request | 1 business day | 5 business days | Business hours only |
| Change request | 2 business days | 10 business days | Business hours only |
Pause conditions tie directly to the waiting on customer status. When a ticket moves into that status, the SLA clock should pause. When the user responds and the ticket moves back into an active status, the clock resumes. This one configuration change often has a noticeable positive effect on SLA metrics for teams that handle a high volume of tickets requiring user input.
Tip Five: Use Automation to Remove Repetitive Manual Steps
Automation in Jira Service Management is one of the highest-value configuration areas for teams that want to improve workflow without adding headcount. Every step that happens consistently and predictably is a candidate for automation, and removing those steps from the agent’s manual workload frees up time for work that genuinely requires human judgement.
Auto-assignment is the automation that most teams implement first, and for good reason. When a ticket is raised as a hardware fault, it should be assigned to the hardware support queue or a specific agent automatically. When a ticket comes in tagged as a network issue, it should reach the networking specialist without a triage step. Setting up assignment rules based on request type, category, or keywords in the ticket description removes the manual sorting that consumes team lead time every day.
User notifications are another area where automation delivers immediate value. Users who raise tickets and then hear nothing feel ignored, even when the team is actively working on their issue. An automated notification when the ticket status changes, when an agent is assigned, and when the issue is resolved keeps users informed without requiring agents to send manual updates. This reduces the volume of inbound chase messages that interrupt agent focus.
Escalation automation protects SLA performance by alerting the right people before a deadline passes. A rule that sends a notification to the team lead when a ticket is within one hour of breaching its SLA gives the team the chance to act. A rule that automatically reassigns a ticket if the assigned agent has not updated it within a defined period ensures that nothing sits forgotten in a personal queue.
Automated closure is useful for managing the resolved but not confirmed category of tickets. When a ticket has been resolved and the user has not responded within five business days to confirm satisfaction, an automation rule can close the ticket and send a final notification. This keeps the queue clean without requiring agents to manually chase every resolved ticket for confirmation.
Tip Six: Set Up the Knowledge Base to Reduce Ticket Volume
The knowledge base in Jira Service Management connects directly to the customer portal. When a user starts typing a request, the system suggests relevant knowledge base articles before they complete and submit the form. If the article answers their question, the ticket never gets raised. For IT support teams handling a high volume of repetitive requests, this deflection capability reduces ticket volume meaningfully.
The value of the knowledge base depends entirely on the quality and relevance of the articles it contains. Articles should cover the most common requests and questions, written in the same plain language that users use rather than technical documentation style. Password reset instructions, VPN connection guides, how to request software access, and steps for connecting to a printer are the kind of articles that deflect tickets consistently.
Linking specific knowledge base articles to specific request types reinforces the deflection at the point where users are most likely to engage. When a user selects the password reset request type and immediately sees an article explaining how to reset their own password, a significant proportion of them will use the article rather than completing the form.
Tip Seven: Review Configuration Regularly as the Team Evolves
Configuration that worked well for a team of five may create friction for a team of fifteen. Processes that made sense at the start of the year may have changed by the middle of it. Service projects that are not reviewed regularly drift away from the needs they were built to serve, and the team adapts by working around the gaps rather than fixing them.
A quarterly configuration review does not need to be lengthy. An hour with the team lead and one or two agents is usually enough to surface the main pain points. Ask which queues people actually use and which they ignore. Ask which workflow statuses cause confusion. Ask which request types consistently arrive with incomplete information. The answers consistently point to the areas that need the most attention.
Treating configuration as an ongoing responsibility rather than a one-time setup task is the single habit that separates service projects that improve over time from those that quietly deteriorate.
How Code Desk Can Help Your Support Team
Code Desk works with IT support teams that want their Jira Service Management setup to reduce friction rather than create it. Whether you are starting a new service project, cleaning up a configuration that has grown inconsistent, or trying to get more from automation and reporting, Code Desk brings hands-on experience across every area of service management configuration. The team takes time to understand how your support operation actually runs before changing anything, builds workflows and queues around your real process, and trains the agents and team leads who will manage the system going forward. If your current configuration is making support harder than it needs to be, Code Desk can help you identify exactly where the setup is letting the team down and fix it in a way that lasts.
Configuration Is the Difference Between a Struggling Queue and a Smooth Operation
The tips in this article address the specific configuration areas where IT support teams most commonly lose time and miss opportunities. A portal that captures the right information, queues that surface the right work, workflows that match the real process, SLA policies that measure fairly, automation that removes manual steps, and a knowledge base that deflects common questions all contribute to a support operation that runs more smoothly than one built on defaults and workarounds.
None of these improvements require significant technical expertise or lengthy implementation projects. They require clarity about how the team works, a willingness to test and iterate, and the discipline to review the configuration regularly as the team and the business change.
Jira service management configuration is not a background detail. It is the operational foundation that determines whether the support team can do its job well. Teams that treat it that way consistently deliver better support with the same or fewer resources than teams that leave it to chance.
