How to design a JSM instance that survives contact with real users: request types, queues, SLAs, approvals, and knowledge, plus what changes when non-IT teams come aboard.
Jira Service Management is easy to install and easy to get wrong. The failure mode is rarely technical. It is a portal nobody wants to use, built by people who already knew where everything was.
Start with the request types your users actually raise, in the words they actually use. Not the categories your team uses internally. A user who needs a laptop does not think in terms of hardware asset provisioning requests, and a portal organized around your org chart will be abandoned within a month.
The useful exercise: pull six months of email requests and informal messages, cluster them, and count. The top ten clusters are your first ten request types. Everything else can wait.
Each request type should ask the minimum needed to act, and no more. Every additional field is a small tax paid by every requester forever, in exchange for information an agent might need occasionally.
Where information is genuinely needed, use conditional fields so requesters only see what applies to them. Where it can be derived from context, derive it rather than asking. A well-designed request type feels like a short conversation. A badly designed one feels like a tax return.
Queues should map to how agents actually pick up work, which is usually by skill or urgency rather than by request type. Build a small number of queues agents genuinely triage from, then resist the pull to add one per stakeholder.
SLAs are commitments, so set them where you can meet them. Aggressive targets that get missed teach everyone to ignore the metric. Start conservative, measure, then tighten. Pay particular attention to how the clock pauses: time waiting on a requester should not usually count against you, and getting that wrong makes agents look worse than they are.
Approvals are where JSM implementations most often become unpopular. Every approval step adds latency, so each one should exist because someone genuinely needs to decide something, not because it feels safer to add a checkpoint.
Prefer approvals derived from data over approvals hard-coded into workflows. Routing to a requester's manager, or to a cost-centre owner pulled from a directory, survives reorganizations. A named individual in a workflow does not.
The strongest deflection lever is a knowledge base surfaced inside the portal at the moment of request, not filed away for later. Write articles for the ten highest-volume request types first. Measure which articles prevent tickets and which do not, then rewrite rather than accumulate.
JSM increasingly serves any internal team that takes structured requests: HR for onboarding and employee cases, Legal for contract intake, Facilities for workplace requests, Finance for exceptions, Operations for procurement.
Three things change when you cross out of IT. Confidentiality matters more, so request-level permissions and separate projects usually beat shared queues. The vocabulary must be theirs, not ITIL's. And these teams often have no ticketing habit at all, so adoption depends more on the intake experience than on agent tooling.
Phased rollouts beat big-bang launches in almost every case. Launch one team with ten request types, learn what people actually ask for, then expand. A launch that covers everything on day one guarantees that every mistake is made at full scale simultaneously.
Guides only take you so far. Bring the messy specifics and we will tell you what we would actually do.
.webp)