Enterprise SLA tables with nine priorities and forty goals look impressive in a presentation and die quietly in a real office. A small team needs three queues it trusts and two timers it can actually keep.
Queues and SLAs sound like the advanced end of a Jira setup; they are actually the daily end. A queue is simply a saved question - 'show me everything unassigned, oldest first' - pinned to the team's screen. An SLA is a promise with a clock: how fast you respond and how fast you resolve, counted against your real working hours. This page builds the smallest version of both that still changes behaviour, and it is honest about the trap in the other direction: promises set to impress management, which the team learns to ignore within a month.
A ticket does not live in a queue the way a file lives in a folder. A queue is a live filter: the moment a ticket matches the question, it appears; the moment it stops matching - assigned, resolved, status changed - it leaves. One ticket can show in several queues at once, and that is a feature.
This matters because it changes how you design them. You are not sorting mail into boxes; you are writing the three or four questions the team asks every morning. If a queue's question is one nobody asks, delete the queue - an unused queue is just a place tickets go to be forgotten with extra steps.
Columns matter as much as the filter: summary, request type, reporter, created date, priority and SLA time remaining. An agent should be able to scan the queue and know what to touch next without opening five tickets to find out.
Start with the two measures customers actually feel:
Set goals per priority, in plain bands. A small office might promise: highest priority, respond in 1 hour and resolve in 4; normal, respond within 4 working hours and resolve in 2 working days; low, respond in a day and resolve in a week. Your numbers will differ - what matters is that the team helped choose them and believed them possible on an ordinary bad day, not a perfect one.
An SLA without a calendar runs on wall-clock time: nights, Sundays and holidays count against you. A ticket raised at 6 PM Friday with a 4-hour goal shows breached before anyone reaches the office on Monday - and a team that sees false breaches learns to ignore real ones.
Jira lets you attach a calendar of working hours to SLA goals. Set it to your actual office hours, add your public holidays, and the clocks pause when the office is closed. This five-minute setting is the difference between SLA data the team respects and SLA data everyone has agreed to pretend is broken.
Two habits make SLAs useful instead of decorative. First, use the time-remaining display in queues and let agents sort by it when choosing next work - the clock should steer the day quietly, before anything turns red. Second, hold a short weekly look at breaches: not a blame meeting, a pattern hunt. Breaches cluster around causes you can fix - one request type with a missing form field, one system whose tickets always wait on a vendor, one hour of the day when nobody triages.
What not to do: publish per-agent breach league tables in month one. You will get faster-looking tickets, angrier customers and gamed statuses. Measure the desk first; coach individuals privately with the data later.
Separate SLA goals per request type, VIP reporter groups, pause conditions for vendor waits, escalation automation - Jira supports all of it, and all of it is week-ten work. The small-team failure mode is building the enterprise configuration on day one, then spending more time maintaining the helpdesk's rules than helping anyone.
The discipline is simple: every new queue or SLA goal must name the decision it changes. "We added a hardware queue because stock requests were hiding inside the problem queue and getting missed" is a reason. "A complete system should have one" is not.
See every screen of the Jira helpdesk setup live, from the empty project to the first real ticket.
Watch Full VideoA queue is a saved filter shown as a work list for agents - for example, all unassigned tickets oldest first. Tickets enter and leave automatically as they match the filter. Each project starts with default queues, and you should trim them to the few questions your team actually asks daily.
Only if you let them. SLA goals can follow a working-hours calendar that you define, including holidays. Without a calendar, timers run around the clock and tickets raised on Friday evening will show breached by Monday - set the calendar before you judge any breach numbers.
Start with two measures - time to first response and time to resolution - with goals per priority band. That is enough to steer daily work and produce honest reports. Add request-type-specific goals later, only when the basic numbers show a pattern worth separating.