JSM Quick Start Guide: Set Up Your First Service Desk in 15 Minutes (2026)

Mike

Mike

— 9 min read
JSM Quick Start Guide: Set Up Your First Service Desk in 15 Minutes (2026)

A word from someone who's done this hundreds of times: After 14+ years implementing JSM for everyone from the BBC to Lloyds Bank, I've learned something crucial—people massively overcomplicate this. The out-of-the-box setup is actually brilliant. Yes, even for large enterprises. Let me show you how to get started the smart way.

And if you are unsure what JSM is and if it's still worth to use it, check my other article on this link.

Ready to get hands-on with Jira Service Management? This tutorial will walk you through creating your first service desk project and getting it ready to receive requests. Let's dive in.

Before We Start: The Biggest Mistake I See

Here's what happens with 90% of new JSM implementations I'm called to fix:

Teams spend weeks customizing workflows, creating dozens of request types, building complex automations, and setting up intricate portal configurations. Then they launch, and nobody uses it properly because it's too complicated.

My recommendation after hundreds of implementations: Start with the default setup. Use it for 2-3 weeks. Then customize based on what you actually need, not what you think you might need.

The out-of-the-box JSM setup isn't just "okay"—it's genuinely excellent. Even Fortune 500 companies I work with often end up using 80% default configuration.

Step 1: Create Your JSM Project

First things first, you need to create your service desk project.

  1. Log into your Atlassian instance and click on Projects in the top navigation
  2. Click Create Project
  3. Select Service Management from the project types
  4. Choose a template that matches your use case:
    • IT Service Desk - Perfect for internal IT support
    • Customer Service - Great for external customer support
    • HR Service Desk - Ideal for employee services
    • General Service Desk - Blank canvas for custom setups

For this tutorial, let's go with IT Service Desk as it's the most common starting point.

  1. Give your project a name (e.g., "IT Support")
  2. The project key will auto-generate (e.g., "ITS") - you can customize this if you want
  3. Click Create

Congratulations! You've just created your first JSM project.

Consultant tip: Resist the urge to immediately start customizing. Click around, explore what's already there. You'll be surprised how much works perfectly as-is.

Step 2: Configure Your Portal

The portal is what your users will see, so let's make it presentable.

  1. From your project, click Project Settings (bottom left)
  2. Navigate to Portal Settings
  3. Customize your portal name - this appears at the top of your portal
  4. Add a welcome message - give users context about what this service desk is for
  5. Upload a logo or icon - makes it look professional (optional but recommended)
  6. Choose your portal access:
    • Public - anyone can access (good for external customers)
    • Private - only people you invite (good for internal teams)
    • Limited - requires login but can be accessed by anyone in your organization

For an internal IT helpdesk, choose Limited access.

  1. Click Save

A Note on Knowledge Base (From My Experience)

You'll see an option to add knowledge base articles to your portal. Here's my honest take after years of implementations: Skip it for now.

I know this sounds counterintuitive, but in its current state, the Jira knowledge base gets barely any use. It often:

  • Provides unclear answers
  • Becomes outdated quickly
  • Actually distracts users from submitting proper requests

What's changing: This is why Atlassian is pushing JSM Premium so hard. The virtual agent (AI-powered, interactive) is replacing the static knowledge base and it's genuinely better. If you're on Premium, explore that instead.

For now, a clear, well-organized set of request types will serve your users better than a half-maintained knowledge base.

Step 3: Work With the Default Request Types (Don't Fight Them)

Request types are the different kinds of tickets users can submit. The IT Service Desk template comes with pre-configured ones that are actually really good.

Here's what you get out-of-the-box:

  • Get IT help
  • Request access
  • Report a system problem
  • Request new software

My strong recommendation: Use these as-is for your first month. Seriously.

But if you absolutely must customize immediately (I know you will), here's how:

  1. Go to Project Settings > Request Types
  2. Edit an existing request type:
    • Click on "Get IT help"
    • Change the name to something clearer like "Technical Support Request"
    • Update the description to guide users on what to include
    • Customize the icon if you want
  3. Add a new request type (only if truly needed):
    • Click Create request type
    • Name it (e.g., "New Equipment Request")
    • Add a description
    • Choose an icon
    • Click Create

Consultant reality check: I've seen teams create 40+ request types thinking it will make things clearer. It doesn't. It paralyzes users with choice. Start with 4-6 maximum. You can always add more later based on actual usage patterns.

Step 4: Keep Request Forms Simple

Forms determine what information you collect from users. The defaults are excellent, but let's look at how to customize thoughtfully.

  1. Still in Request Types, click on your "Technical Support Request"
  2. Click on Request form in the right panel
  3. You'll see default fields like Summary, Description, Attachment

Critical advice from the trenches: Every field you add reduces submission rates. People hate forms. Keep them brutally simple.

Only add custom fields if:

  • You absolutely need that info to start work
  • You'll actually use the data
  • Users can reasonably answer the question

Here's an example of a useful addition:

  1. Click Add field at the bottom
  2. Let's add a "Urgency" dropdown:
    • Select Dropdown (single choice)
    • Name it "Urgency"
    • Add options: Low, Medium, High, Critical
    • Make it required by toggling the switch
    • Click Add
  3. Reorder your fields by dragging them up or down
  4. Make fields required using the toggle switches
  5. Click Save when you're done

What I typically see work best:

  • Summary (required)
  • Description (required)
  • Urgency/Priority (optional dropdown)
  • Attachment (optional)
  • Maybe 1-2 context fields specific to your org

That's it. Five fields maximum for most request types.

Step 5: Set Up Basic Queues

Queues help your agents organize and prioritize work. The defaults are pretty good here too, but let's create a few essentials.

  1. From your project board, click Queues in the left sidebar
  2. Click Create queue
  3. Name it "Unassigned Tickets"
  4. Set up a filter using JQL (don't worry, it's simple):
   assignee is EMPTY
  1. This shows all tickets that haven't been assigned to anyone yet
  2. Click Save

Create a few more useful queues:

High Priority Queue:

  • Name: "High Priority"
  • JQL: priority in (High, Highest)

My Open Tickets:

  • Name: "My Tickets"
  • JQL: assignee = currentUser() AND status != Done

Recently Resolved:

  • Name: "Recently Resolved"
  • JQL: status = Done AND resolved > -7d

These basic queues will help your team stay organized from day one.

Pro tip: Don't create 20 queues on day one. I've watched teams waste hours configuring elaborate queue structures that nobody ends up using. Start with these four, see how your team actually works, then add more if needed.

Step 6: Configure Basic SLAs

SLAs ensure you're responding to requests on time. Let's set up a simple one.

  1. Go to Project Settings > SLAs
  2. Click Create SLA
  3. Name it "First Response Time"
  4. Set the goal (e.g., "8 hours")
  5. Define when it starts: "When issue is created"
  6. Define when it stops: "When first comment is added by agent"
  7. Set which requests this applies to (you can start with "All issues")
  8. Choose your working hours:
    • 24/7 - for round-the-clock support
    • Business hours - define your support hours (e.g., Mon-Fri, 9am-5pm)
  9. Click Save

Create one more SLA for resolution time:

  • Name: "Time to Resolution"
  • Goal: "48 hours" (business hours)
  • Starts: "When issue is created"
  • Stops: "When issue is resolved"

Real talk: Start with generous SLA targets. It's way easier to tighten them later than to constantly miss aggressive targets you set on day one. Build trust first, optimize second.

Step 7: Set Up ONE Simple Automation

Automation is where people go absolutely wild and create unmaintainable messes. Let me show you one useful automation that won't cause problems.

My philosophy on automations: Less is more. WAY more. Start with one or two simple rules. Get comfortable. Then expand slowly.

Let's create a simple automation to assign tickets automatically:

  1. Go to Project Settings > Automation
  2. Click Create rule
  3. Click Add trigger and select "Issue created"
  4. Click Add condition and select "Issue matches JQL"
  5. Enter JQL to catch high-priority tickets:
   priority = High
  1. Click Add action and select "Assign issue"
  2. Choose "Project lead" or a specific team member
  3. Name your rule "Auto-assign high priority tickets"
  4. Click Turn on rule

That's it! High-priority tickets will now automatically assign to the right person.

Warning from experience: I've debugged automation nightmares where teams had 30+ rules interacting in unpredictable ways. They spend more time fixing automation loops than handling tickets. Start simple. Seriously.

Step 8: Add Your Team Members

Time to bring your team on board.

  1. Go to Project Settings > People
  2. Click Add people
  3. Search for team members by name or email
  4. Select their role:
    • Service Desk Agent - can work on tickets
    • Service Desk Team - can view but not work on tickets
    • Administrator - full project control
  5. Click Add

Remember: Portal users (customers/employees) don't need to be added here. They can access the portal without licenses.

Step 9: Test Your Portal

Before going live, test everything from a user's perspective.

  1. Get your portal URL:
    • Go to Project Settings > Portal Settings
    • Copy the portal URL at the top
  2. Open the portal in an incognito window (to see it as a regular user would)
  3. Submit a test request:
    • Choose a request type
    • Fill out the form
    • Submit it
  4. Go back to your JSM project and verify:
    • The ticket appeared in your queues
    • SLAs started correctly
    • Any automations fired as expected

Testing checklist:

  • Can users easily find the right request type?
  • Are form fields clear and not overwhelming?
  • Does the confirmation message make sense?
  • Can users track their request status?

Step 10: Go Live (The Simple Way)

Everything working? Great! Here's how to launch:

  1. Announce to your users:
    • Email your team/customers with the portal URL
    • Explain what types of requests they can submit
    • Keep it simple - don't overwhelm them with features
  2. Add the portal link to:
    • Your intranet or company wiki
    • Email signatures
    • Slack/Teams channels
    • Anywhere users might need support
  3. Monitor the first few days:
    • Watch for common questions or confusion
    • Note which request types get used most
    • See if SLA targets are realistic
    • Check if forms are too long/short

The First Month: Learn Before You Customize

Here's what to do in your first 30 days (based on what actually works):

Week 1: Just watch

  • Don't change anything
  • Observe how people use the system
  • Note pain points
  • Resist the urge to "fix" things immediately

Week 2: Collect feedback

  • Ask agents what's working/not working
  • Check which request types are confusing
  • Look at ticket patterns

Week 3: Make small adjustments

  • Clarify request type descriptions
  • Adjust SLA targets if way off
  • Maybe add ONE automation if there's a clear need

Week 4: Review and plan

  • Look at usage data
  • Identify real customization needs
  • Plan thoughtful changes for month 2

Why this matters: I've seen teams customize heavily before launch, then realize users needed something completely different. Save yourself the rework.

Common "Customization" Mistakes to Avoid

After fixing hundreds of JSM implementations, here are the top mistakes:

❌ Complex workflows on day one
Standard → In Progress → Waiting → Done works for 90% of cases. Don't create 15-step workflows because you think you should.

❌ Dozens of custom fields
Every custom field is another thing to maintain, report on, and confuse people with. Ruthlessly question each one.

❌ Over-automation
Automation is powerful but creates invisible dependencies. Start minimal.

❌ Too many request types
More isn't better. Users get paralyzed choosing between "Hardware Issue," "Hardware Problem," "Hardware Request," and "Equipment Issue."

❌ Premature portal customization
The default portal is clean and functional. Fancy customizations can wait.

❌ Ignoring the out-of-the-box setup
This is the big one. Atlassian employs smart people who've thought deeply about service desk workflows. Trust the defaults until you have a specific, proven reason to deviate.

Next Steps After Your First Month

Once you've actually used JSM and understand your patterns, here's what to explore:

If you're on Standard:

  • Advanced queue organization
  • Canned responses for common replies
  • Integration with Confluence for documentation
  • Custom workflows (only if needed)
  • Email notifications customization

If you're on Premium:

  • Assets management - Track your IT equipment (coming in my next guide)
  • Virtual agents - Let AI handle tier-1 requests
  • Advanced automations - More complex workflows
  • Operations features - Incident management, on-call

My Philosophy: Simplicity Scales

After implementing JSM for massive enterprises and tiny startups, here's what I've learned:

Complex doesn't mean professional. The best implementations are often the simplest. They're easy to maintain, easy to train people on, and actually get used.

Start small, grow deliberately. You can always add complexity. Removing it after people are trained is painful.

Out-of-the-box is not "basic." It's the distilled wisdom of thousands of implementations. Respect that.

Your unique needs are probably not that unique. Unless you're in a highly regulated industry with specific compliance requirements, the default setup probably covers you.

Final Thoughts

You now have a fully functional JSM service desk that's simple, maintainable, and actually usable. This might feel "too simple" compared to other guides that show you how to build elaborate systems on day one.

Good. Simple is sustainable.

In my 14+ years doing this, I've never been called in to rescue a team that kept things too simple. I've been called in dozens of times to untangle over-customized nightmares.

Start here. Use it. Learn from real usage. Then customize thoughtfully based on actual needs, not imagined ones.

Need help with your JSM implementation? I work with teams to build sustainable, effective service desks that people actually use. Whether you need a quick consultation to validate your approach or hands-on implementation support, let's talk.

Coming soon: My in-depth guide to JSM Assets management—the killer feature that justifies the Premium upgrade for most IT teams.

Read more