Set Up a Jira Helpdesk Step by Step Complete Guide

You do not need a server, a database or an installer. A Jira helpdesk in 2026 starts as a cloud site:

1. Sign up at Atlassian and create a site - the address looks like yourcompany.atlassian.net
2. Add Jira Service Management to the site and start on the Free plan
3. The free plan covers a small team - it has historically allowed up to 3 agents, while customers stay free and unlimited. Plans change, so confirm the current limits on Atlassian's plan page before you commit the team to it

Stay on free while you build. Every step in this guide works on the free plan, and you can upgrade later without rebuilding anything.

Inside Jira, create a new project and pick a service management template - the IT service desk style template is the right starting shape for an internal helpdesk. Give it a short key (for example IT), because the key becomes part of every ticket number your users will quote at you, like IT-142.

One honest choice appears here: company-managed projects share schemes and settings across projects and are run by Jira admins; team-managed projects are simpler and owned by the project team. For a first helpdesk with one team, either works - just know the settings screens differ slightly between the two.

The portal - Atlassian calls the combined view the help centre - is the only screen most of your users will ever see, so set it up before you invite anyone:

1. Write a one-line welcome message that says what this desk handles
2. Set who can raise requests - for an internal desk, only people in your organisation; for customer support, you can open it wider later
3. Add an announcement only when you have something real to announce, like a maintenance window

Do not invite the whole office yet. A portal that opens half-configured teaches people to go back to email.

Request types are what the customer clicks; the work item types behind them are your internal business. Start with a handful that cover real life:

• Report a problem - something worked before and stopped
• Request access - a system, folder, VPN or application
• Ask for new hardware - with a short form for what and why
• Ask a question - the honest catch-all

Each request type gets a small form. Ask only what an agent truly needs to start work - every extra field costs you completed tickets, because people abandon long forms and phone you instead. You can add request types later in minutes; you cannot easily un-teach a bad first impression.

Now add the people who will work the tickets. In Jira Service Management there are two very different kinds of user:

• Agents - they work queues, reply to customers and close tickets. Agents are what plans count and charge for
• Customers - they raise requests and follow their own tickets. Customers are free and unlimited

Invite your support staff as agents and add them to the project. Resist adding managers and bystanders as agents just so they can look around - a person who only raises or watches tickets should stay a customer, or get a view-only route, because agent seats are the scarce resource in this product.

Queues are how agents see work. A queue is simply a saved filter with columns, sorted the way the team agrees to work. Build three on day one:

1. All open - everything not finished, oldest first, so nothing quietly rots
2. Unassigned - new work nobody owns yet; this queue should return to zero daily
3. Waiting on customer - tickets blocked on a reply, so they stop polluting your active list

Queues are powered by Jira's search language, but you do not need to learn it today - the queue editor builds the filter as you pick statuses and assignees. Add an urgent or VIP queue later only if the team asks for it.

An SLA in Jira is a timer on the ticket: mainly time to first response and time to resolution. Keep the first version almost embarrassingly simple:

1. Set goals by priority - for example, highest priority gets a first response in 1 hour and a fix target of 4 hours; normal work gets a response the same working day
2. Attach a calendar that matches your real working hours, so a ticket raised on Friday evening does not show as breached on Monday morning
3. Start the timers on ticket creation and stop resolution on your resolved status

An SLA nobody can meet is worse than none - it trains the team to ignore red clocks. Tighten goals after a month of honest data, not before.

Plenty of users will never visit a portal, and that is fine. Turn on the project's email channel: each service project gets its own email address, and anything sent to it becomes a ticket with the sender as the customer.

You can also connect your own support mailbox (a Google or Microsoft mailbox your users already know) so the familiar address keeps working. Replies from agents go back out as email, and customer replies land on the same ticket. The honest caveat: email tickets arrive with whatever subject line the sender invented, so request types and tidy forms belong to the portal - email is the safety net, not the front door.

Before the office hears about this helpdesk, break it yourself:

1. Open the portal in a private browser window, raise one request of each type, and check the forms make sense to a non-IT person
2. Send one email to the project address and confirm it becomes a ticket
3. Work both tickets as an agent - assign, reply, resolve - and watch the SLA clocks and the customer's view at each step
4. Fix the two or three rough edges you find, then announce the portal link with one sentence about what it replaces

That is the whole setup. Everything else in this series - automation, reports, knowledge base articles - is an improvement on top of a desk that already works, not a requirement for day one.