Here's a fun diagnostic I run with new clients: I ask to see their Jira Service Management project, and then I ask one question. "When a ticket comes in, how does your team know which one to work on first?" The answers are revealing. Sometimes it's "whoever shouts loudest." Sometimes it's "Dave just knows." Occasionally it's a long pause followed by "...vibes?"

If your service desk runs on vibes and Dave, this post is for you. Because underneath every JSM rollout that actually works — including all the AI-powered wizardry getting keynote time lately — sit three unglamorous load-bearing walls: SLAs, queues, and automation. Get these three right and everything else gets easier. Get them wrong and no amount of AI will save you, because you'll just be disappointing people faster.

Let's build them in the right order.

Step one: SLAs — write the promise down

An SLA in JSM is simply a clock attached to a promise. "We'll respond to high-priority requests within one hour." "We'll resolve standard requests within two business days." The clock starts, pauses, and stops based on conditions you define — and that's where most teams stumble, so let's be precise.

Head to Project settings → SLAs. Out of the box, JSM gives you Time to first response and Time to resolution. Start with exactly those two. For each, you define three things:

• Start condition. Usually "Issue created." Simple, defensible, hard to argue with.
• Pause condition. This is the one everyone forgets, and it's the one that keeps your metrics honest. Set the clock to pause when the status is Waiting for customer. If the requester goes silent for three days, that's not your team's three days — and your SLA report shouldn't say otherwise.
• Stop condition. For first response: the first public agent comment. For resolution: the resolution field being set. Note that distinction — resolution set, not "status changed to Done." Workflows drift; the resolution field tells the truth.

Then attach goals to segments of work using JQL. A goal of one hour where priority = Highest, eight hours for High, two business days for everything else. And assign the right calendar to each goal — JSM lets you define working hours, so a ticket filed Friday at 6 PM doesn't breach a 9-to-5 team's SLA over the weekend. Unless you genuinely run 24/7, in which case, set the calendar to say so and staff accordingly.

One trusted-advisor note before you set anything aggressive: an SLA is a promise to other humans. Set targets your team can actually hit at normal staffing, not targets that look impressive in a slide. A 95% hit rate on an honest goal beats a 60% hit rate on a heroic one, every single quarter.

Step two: queues — make the promise visible

SLAs without queues are like speed limits without speedometers. The queue is where your agents live all day, so design it like you'd design a kitchen: the things you reach for most should be closest to hand.

Queues are built in Project settings → Queues (or right from the agent view), and each one is just a JQL filter with columns and a sort order. The pattern I install almost everywhere:

• "Breach imminent" at the very top: open issues sorted by Time to SLA breach, ascending. The ticket closest to breaking a promise is always the first thing every agent sees. This single queue does more for SLA performance than any pep talk ever delivered.
• "Unassigned" next: anything without an owner. Work that nobody owns is work that nobody does.
• Per-team or per-request-type queues after that: hardware, access requests, HR onboarding — whatever your real lines of work are.
• "Waiting for customer" at the bottom: parked, paused, out of the way.

And then the hard part: stop. Queue sprawl is real. I've audited projects with twenty-six queues, of which agents used four. Every queue is a claim on attention; if nobody works from it, delete it. Five to eight well-named queues beats two dozen clever ones, and your new agents will onboard in an afternoon instead of a week.

Step three: automation — defend the promise while you sleep

Now the quiet robot. JSM's automation lives in Project settings → Automation, and every rule follows the same grammar: when something happens, if conditions are met, then do something. The craft is in choosing rules that protect the SLAs and queues you just built, rather than automating randomly because the editor is fun (it is, though).

The starter set I'd put in any project:

• Auto-triage on intake. When a request is created, set priority and route it based on request type. Password resets don't need a human to decide they're a password reset.
• The breach defender. When an SLA hits, say, 30 minutes remaining, ping the assignee; at 15 minutes, escalate to the team lead and bump it into a high-visibility queue. Your SLA report stops being an autopsy and starts being an early-warning system.
• The nudge. When a ticket sits in Waiting for customer for three days, post a friendly reminder. After seven days of silence, resolve it with a polite note and an invitation to reopen. Stale tickets evaporate; agents stop babysitting ghosts.
• Balanced assignment. Round-robin new requests across available agents so work spreads evenly instead of piling onto whoever answered fastest last sprint.

Two rules of the road: test every rule in a sandbox or low-stakes project before trusting it, and revisit your rule list quarterly. Automation that misfires silently is worse than no automation — and rules, like queues, accumulate barnacles.

The Avaratak Take

Notice the order we built in: SLA first, queue second, automation third. That's not arbitrary. The SLA defines the promise, the queue makes the promise visible, and the automation defends the promise when humans are busy, away, or asleep. Teams that bolt on automation before defining their promises end up with very efficient chaos.

And here's the forward-looking part: this trio is also the foundation everything new gets built on. Every AI capability arriving in JSM — virtual agents, auto-triage, autonomous resolution — reasons over the structure you define here. An agent can't honor an SLA you never configured or route to a queue that doesn't exist. The boring plumbing is the prompt. Do it well, and the shiny stuff actually shines.

If you'd like a second set of eyes on your SLA targets, a ruthless queue audit, or an automation rule set that earns its keep, that's exactly the work we love at Avaratak Consulting. As an Atlassian Solution Partner, we'll tell you honestly which promises your team can keep — and then help you build the machinery that keeps them. Find us at avaratak.com. Dave deserves the help.