Every IT manager who has inherited a poorly configured service desk knows the particular frustration of trying to improve a team's performance when the platform they work in actively gets in the way. Tickets that arrive missing critical information. Queues that show everything at once with no useful prioritisation. SLA clocks that run through weekends and make the team's metrics look worse than their actual performance. Notifications that flood inboxes until everyone stops reading them.

These are not problems caused by the team working poorly. They are problems caused by a platform that was set up without enough thought, never reviewed, and gradually drifted further from what the service actually needs. The fix is not a new tool or more staff. It is a systematic review of the configuration and a deliberate rebuild of the elements that are creating friction.

This checklist gives IT managers a structured approach to that review, working through every significant area of Jira service management configuration in a logical order.

Why Jira Service Management Configuration Needs Regular Review

Jira service management configuration is not a one-time task. Service teams change. New request types are added without updating the portal or the queues to reflect them. New agents join without the queue structure being reviewed to account for their workload. SLA targets are set at go-live and never revisited even as the team's capacity and the volume of requests change significantly.

The result is a platform that drifts progressively further from the team's actual needs. Configuration debt accumulates. Workarounds develop. The team stops trusting the metrics because they know the underlying data is unreliable. A structured checklist approach, applied systematically and revisited regularly, prevents this drift and keeps the configuration serving the team rather than constraining it.

Checklist Section One: Customer Portal and Request Types

The portal is the user-facing part of the service desk. Its configuration determines how easy it is for users to raise the right type of request with the right information.

Portal Organisation

• Request types are grouped into categories that users understand without explanation
• Category names use plain language rather than IT terminology
• The portal landing page displays the most commonly used request types prominently
• Outdated or unused request types have been removed or archived
• The portal is accessible on mobile devices without layout issues

Request Type Configuration

• Each request type maps to a genuine, distinct user need
• Request type names describe what the user wants to achieve rather than the IT process behind it
• Request type descriptions give users enough context to choose the right option
• Each request type has an icon that helps with visual navigation
• Request types that are no longer relevant have been decommissioned

Form Design

• Each form captures the minimum information an agent genuinely needs to begin work
• Required fields are limited to genuinely essential information
• Dropdown fields are used where predefined options reduce ambiguity
• Description fields include guidance text that explains what useful information looks like
• Fields that are only needed at later stages are captured through transition screens rather than creation forms

Checklist Section Two: Queue Configuration

Queues are where agents spend most of their time. A well-designed queue structure gives agents the information they need to prioritise their work without requiring any manual searching or sorting.

Queue Structure

• A queue exists for urgent and critical tickets that need immediate attention
• An unassigned queue surfaces tickets that have not yet been picked up
• A near-SLA-breach queue shows tickets approaching their deadline
• A waiting on customer queue tracks tickets pending user response
• Individual agent queues show each person their own open work
• Specialist queues exist for teams or agents handling specific request categories

Queue Naming and Ordering

• Queue names describe what the agent will find without requiring explanation
• Queues are ordered so the most important work is visible first
• The default sort within each queue is appropriate for the queue's purpose
• Unused queues have been removed to reduce navigation overhead

Queue Filters

• Each queue filter is accurate and returns the tickets it is designed to surface
• JQL queries in queue filters have been tested and confirmed to work as expected
• Filters are not so broad that they surface irrelevant tickets
• Filters are not so narrow that they miss tickets they should include

Checklist Section Three: Workflow Configuration

The workflow determines how tickets move from creation to resolution. A workflow that reflects the real service process makes tickets easier to manage. One that does not creates confusion about where tickets stand and what needs to happen next.

Workflow Statuses

• Every status in the workflow represents a genuine state that a ticket can be in
• Status names are specific enough to be unambiguous when read by any agent
• A dedicated blocked or waiting state exists for tickets that cannot progress
• A waiting on customer status is configured separately from active work
• The number of statuses is as small as the real process allows
• Statuses that are never used have been removed

Workflow Transitions

• Transitions map to genuine handoffs in the service process
• Transition names describe the action being taken clearly
• Transition screens capture information at the moment it becomes relevant
• Validators prevent tickets from moving forward until necessary conditions are met
• A comment is required when a ticket is placed in a waiting or blocked state

Transition Validators

• Resolution category required before closing
• Comment required when placing a ticket on hold or in a waiting state
• Priority required to be set before leaving the triage stage
• Assignment required before a ticket moves to active work

Checklist Section Four: SLA Policy Configuration

SLA policies are how the service team's performance is measured. Accurate, fairly configured SLAs produce measurements that reflect actual performance. Poorly configured SLAs produce numbers that everyone knows are distorted.

SLA Targets

• Separate SLA targets exist for different priority levels
• Targets reflect realistic expectations given current team capacity
• Targets have been reviewed since the initial go-live configuration
• Targets align with any formal agreements or service commitments in place

Calendar and Business Hours

• Business hours are defined and applied to all relevant SLAs
• Weekends are excluded from SLA calculations
• Public holidays have been added to the business calendar
• The calendar reflects the actual hours during which the team is expected to respond

SLA Pause Conditions

• The SLA clock pauses when a ticket enters a waiting on customer status
• The SLA clock behaviour in waiting on third party states has been deliberately configured
• The SLA clock resumes correctly when tickets leave waiting states
• Agents understand how the pause conditions work and use waiting statuses correctly

Checklist Section Five: Automation Configuration

Automation removes the manual steps in the service process that happen consistently and predictably. Each automated step is time returned to the team for work that requires human attention.

Auto-Assignment Rules

• Tickets are automatically assigned to the correct team or agent based on request type
• Assignment logic has been tested and confirmed to work correctly
• Auto-assignment is reviewed when team structure changes
• Tickets that cannot be auto-assigned route to an unassigned queue for manual pickup

Notification Automation

• Users receive a confirmation notification when their ticket is received
• Users are notified when the status of their ticket changes
• Agents receive a notification when a ticket approaching SLA breach is assigned to them
• Team leads are notified when a ticket has been blocked or unactioned for an extended period

Escalation Automation

• Tickets approaching SLA breach trigger an alert to the team lead
• Tickets that have been blocked for longer than the agreed threshold are automatically escalated
• Resolved tickets that receive no user response are automatically closed after a defined period
• Auto-closure sends a final notification to the user before closing

Automation Rule Maintenance

• All active automation rules are documented
• Automation rules are reviewed when workflows or request types change
• Rules that are no longer needed have been deactivated
• Rules are tested after any significant configuration change to confirm they still fire correctly

Checklist Section Six: Notification Schemes

Notifications that nobody reads are worse than no notifications at all, because they create a false sense of communication while ensuring that important alerts are missed alongside the irrelevant ones.

Notification Review

• The notification scheme has been reviewed and trimmed from the default settings
• Agents are notified when tickets are assigned to them
• Agents are notified when tickets they are assigned to are updated by the user
• Users are notified at key stages of their ticket's journey
• Notifications are not sent for every event, only for events that require action

Notification Content

• Notification templates include enough context for the recipient to understand what action is needed
• Notifications link directly to the relevant ticket
• Notification language is clear and does not use internal jargon that users would not understand

Checklist Section Seven: Knowledge Base Configuration

The knowledge base reduces ticket volume by answering common questions before they become requests. Its effectiveness depends entirely on the quality and relevance of the articles it contains.

Article Quality

• Articles address the specific questions users actually ask, not theoretical questions
• Article language matches how users describe problems rather than how the IT team describes them
• Articles include screenshots or step-by-step instructions where these help
• Articles have been reviewed for accuracy within the past six months
• Outdated articles have been updated or archived

Portal Integration

• Knowledge base articles are linked to the relevant request types
• Article suggestions appear when users begin typing on the portal
• The most useful articles for each request type are surfaced prominently
• Deflection rates for each request type are tracked and reviewed

Checklist Section Eight: Reporting and Dashboards

Configuration quality is ultimately visible in reporting quality. Clean configuration produces reliable reports. Inconsistent configuration produces numbers that require qualification every time they are presented.

Dashboard Configuration

• A team lead dashboard exists showing current queue depth, SLA performance, and unassigned tickets
• A management dashboard exists showing monthly trends, volume by request type, and SLA compliance
• Dashboards are reviewed at least monthly and adjusted when the team's needs change

Reporting Data Quality

• SLA met and breached rates are tracked by priority and request type
• Average resolution times are available by category
• Ticket volume trends over time are visible
• Agent workload distribution is monitored regularly

Checklist Section Nine: Permissions and Access

Permissions control who can do what within the service project. Overly broad permissions create risk. Overly restrictive permissions create bottlenecks.

Agent Permissions

• Agents can create, edit, transition, and comment on tickets
• Agents cannot modify project configuration or workflow settings
• Agents can view all tickets in their assigned queues

Admin Permissions

• Project administrator access is limited to a small, named group
• Configuration changes are reviewed before implementation
• A record is kept of significant configuration changes and when they were made

How Code Desk Can Help Your IT Management Team

Code Desk works with IT managers who need their Jira service management configuration to match the demands of the service they are running. Whether the need is a complete setup review using this checklist as a starting framework, rebuilding a specific area such as SLA configuration or queue structure that is causing persistent problems, or creating the documentation and governance practices that keep the configuration reliable as the team and the service evolve, Code Desk brings the service management expertise and the Jira technical depth to get it done properly. Every engagement starts with understanding how the team actually operates before recommending any changes, and ends with the training and documentation the team needs to maintain the improvements without ongoing external involvement.

A Well-Configured Service Desk Is a Better Place to Work

This checklist covers every significant area of Jira service management configuration that affects how effectively a service team operates. Working through it systematically, addressing the areas with the most impact first, produces a service desk that is easier for agents to work in, more responsive for users, and more accurately measured by management.

The investment in configuration review and improvement pays back quickly in reduced manual overhead, more reliable metrics, and a service environment where the team can focus on resolving issues rather than managing the tool. That outcome is worth the time the checklist takes to work through, and worth revisiting every six months to keep the configuration aligned with how the team and the service continue to evolve.