Build a Support Queue in Jira

Configure a Tier 2 support queue with SLAs and triage workflows in Jira.

Introduction

30 Second Summary

When a critical integration breaks and a routine password reset arrives at the same time, someone needs to decide which one gets attention first. That decision is what a well-configured support queue automates for you.

In this project, you will build a Tier 2 technical support operation in Jira Service Management. You will create custom queues, configure time-based SLAs, and resolve a realistic support ticket from start to finish.

What You'll Build

Imagine opening your support dashboard to see a critical HRIS sync failure surfaced above a routine login request, with SLA timers counting down on each ticket.

By the end of this project, you'll have:

A customer portal where you submit support tickets that land in custom queues, automatically sorted so critical integration failures surface above routine requests.
Working SLAs with time-to-first-response and time-to-resolution targets that start, pause, and stop based on your workflow statuses.
A ticket walked through its complete lifecycle from triage to resolution, with internal notes, customer communication, and a Tier 3 escalation along the way.
Secret Mission: A custom automation rule that auto-assigns high-priority tickets the moment they arrive.

Do I need any previous Jira experience?

No. This project walks you through everything from creating your Atlassian account to resolving your first ticket. All you need is a web browser.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters for the role you're targeting.

Sign Up for Jira Service Management and Create Your Service Space

To build your support queue, you need a live environment where you can create tickets, configure workflows, and track SLAs. Jira Service Management is Atlassian's purpose-built platform for exactly this.

In this step, you'll sign up for a free account and create a service space using the IT service management template. The template comes with pre-configured workflows and request types, so you can focus on building your Tier 2 operation instead of starting from scratch.

In this step, get ready to:

Sign up for a free Jira Service Management Cloud account.
Create a service space named Tech Support Hub using the IT service management template.
Confirm that the default queues and workflows are loaded in your space.

Sign up for Jira Service Management

The Free plan requires no credit card and supports up to 3 agents. It is free forever with 2 GB of storage.

Open the Jira Service Management signup page in your web browser.
Enter your email address and create your Atlassian account.
When prompted to select a product, choose Jira Service Management.
Complete the signup by verifying your email if Atlassian sends a confirmation link.

After completing signup, you land on your Atlassian Cloud home page or Jira Service Management dashboard.

What is Jira Service Management?

Jira Service Management is Atlassian's platform for support operations. It includes queues, SLA tracking, a customer-facing portal, and ITIL-aligned workflows out of the box.

Plain Jira Software targets software development teams. For a Tier 2 support queue with SLA targets, Jira Service Management is the right fit.

Not seeing a confirmation email?

Check your spam or junk folder. Atlassian confirmation emails sometimes land there.

If you already have an Atlassian account, sign in at atlassian.com instead of creating a new one.

Help me sign up for Jira Service Management

Create your service space

A service space is your team's workspace for managing support requests. The IT service management template pre-configures it with workflows, request types, and queue structures.

Click Spaces in the left sidebar.
Click Create space.
Under the Service management category, select the IT service management template.
Click Use template.
Enter Tech Support Hub as the space name.
Leave the generated space key as-is.
Click Create space.
On the welcome screen showing default request types, click Continue to space.

Your Tech Support Hub service space dashboard loads with the pre-configured request types and workflows.

What does the IT service management template include?

This template comes pre-configured with ITIL practices including a request portal, service catalog, queues, and SLA fields. It also includes incident and change management features.

Starting from this template means you already have working workflows. Your job in the next steps is to customize them for Tier 2 support.

Can't find the IT service management template?

Make sure you clicked Spaces in the left sidebar first, not a different menu item. The Create space option appears from there.

Look under the Service management category specifically. The IT service management template is listed alongside other service management options.

Help me find the IT service management template in Jira Service Management

Confirm the default queues

Click Queues in the left sidebar.

You should see several pre-configured queues, including All open. These queues handle general IT support requests.

Why aren't the default queues enough?

The default queues group every ticket into broad buckets. A Tier 2 integration support team needs to see urgent integration failures before routine password resets.

You'll build custom queues with priority-based filters in Step 3 to solve exactly this.

Your support operation has a home base. Next up, you'll submit your first support ticket and watch it flow through the default workflow.

Submit Your First Support Ticket and See the Default Workflow

Your service space is set up and ready to go. Before you customize anything, you need to see how a ticket actually flows through the system out of the box.

In this step, you'll submit a realistic support ticket, watch it land in your queue, and observe the default workflow statuses. This baseline experience is what you'll improve in the next steps.

In this step, get ready to:

Submit a High-priority support ticket modeled on a real HRIS integration failure.
View the ticket in your queue and observe the default workflow statuses.
Submit a second Medium-priority ticket to build a multi-ticket queue for triage.

Raise a request on behalf of a customer

In a real support role, customers call in or email about issues, and you create the ticket for them. You'll simulate this by creating a ticket directly in your space for a fictional client.

In your Tech Support Hub space, click Create in the top navigation bar.
Select a request type such as Get IT help or a general service request.
In the Summary field, enter HRIS integration sync failing for client Acme Corp.
In the Description field, enter: Client reports that employee data from BambooHR is not syncing to the Achievers platform. Last successful sync was 3 days ago. Error message: connection timeout.
Set the Priority field to High.
Click Create to submit the request.

What is an HRIS integration?

HRIS stands for Human Resource Information System. Tools like BambooHR store employee data (names, roles, start dates) and sync that data to other platforms. When the sync breaks, a Tier 2 support agent investigates the connection and fixes it.

View the ticket in your queue

Your ticket has been created. Now you need to see where it landed and what the default workflow looks like from the agent side.

Click Queues in the left sidebar of your space.
Look for your new ticket in the default queue (such as All open).
Click into the ticket to open the full work item detail view.

You should see the ticket detail view with fields like Priority (set to High), Status (showing the current workflow state), and Reporter (your name, since you created it).

Look at the Status field near the top of the ticket. It should show Waiting for Triage.
Click the status to see the available transitions. You should see options like Waiting for Support, Waiting for Customer, and Resolved.
Close the status dropdown without changing anything for now.

What do the default workflow statuses mean?

The IT service management template comes with four workflow statuses that mirror how real support teams operate:

Waiting for Triage is the initial state. The ticket has arrived but no agent has assessed it yet.
Waiting for Support means an agent is actively working on the issue.
Waiting for Customer means the agent needs more information from the customer before continuing.
Resolved means the issue is closed.

Don't see your ticket in the queue?

Make sure you are viewing the Queues section in the left sidebar, not the Board or List view.
Try clicking the All open queue. Your ticket should appear there regardless of priority.
Refresh the page if the ticket was just created. It may take a moment to appear.

Still stuck? Help me find my ticket in the Jira Service Management queue.

Submit a second ticket with lower priority

A real support queue always has multiple tickets with different urgency levels. You need a second ticket so you can later build custom queues that separate urgent issues from routine ones.

Click Create in the top navigation bar again.
Select the same request type you used before.
In the Summary field, enter Employee unable to log in via SSO.
In the Description field, enter: Single sign-on returning 403 error for user jane.doe@acme.com. Other users unaffected. Started after recent IdP certificate rotation.
Set the Priority field to Medium.
Click Create to submit.

Why SSO and not a password reset?

SSO (Single Sign-On) login failures are a common Tier 2 issue because they involve identity provider configuration, not just resetting a password. An IdP certificate rotation can silently break authentication for specific users, which is exactly the kind of issue a Tier 2 agent investigates.

Before you check your queue, think about what you expect to see. How many tickets should appear, and what status should they both have?

Click Queues in the left sidebar.
Open the All open queue.

You should see both tickets listed. The HRIS ticket shows High priority and the SSO ticket shows Medium priority. Both have the status Waiting for Triage.

Notice anything missing?

Both tickets are sitting in the same default queue with no separation. A critical HRIS sync failure and a routine SSO login issue are treated identically. As a Tier 2 agent, you would need the integration failure to surface first. That is the problem you will solve in the next step with custom queues.

You now have two realistic support tickets in your queue and a clear picture of the default workflow. Next up, you'll build custom queues that automatically sort these tickets by priority so urgent integration failures surface above routine requests.

Build Custom Queues for Tier 2 Triage

You have two realistic support tickets in your queue and you've seen how the default workflow moves them through statuses.

The problem is that both tickets sit side by side in the same undifferentiated list. A critical HRIS sync failure looks identical to a routine SSO login issue, so a Tier 2 agent has no way to triage by urgency.

Custom queues solve this by filtering tickets automatically. You'll build two queues using JQL (Jira Query Language) so that urgent integration failures surface above everything else.

In this step, get ready to:

Create a custom queue that shows only critical integration failures.
Create a second queue for standard support requests.
Organize both queues into a priority group for easy sidebar access.

Create the Critical - Integration Failures queue

Your first custom queue will catch every high-priority, unresolved ticket. This is the queue a Tier 2 agent checks first thing in the morning.

In your Tech Support Hub space sidebar, find Queues and select More actions (the icon next to it).
Select Queue settings.
Click Create new queue.
Enter Critical - Integration Failures in the Name field.
In the Filter by section, click Advanced to switch to JQL mode.
Enter this JQL query in the filter field:

priority = High AND resolution = Unresolved

In the Columns section, configure the columns to show Key, Summary, Status, Priority, Created, and Assignee by dragging and dropping them into the desired order.
Click Create.

What is JQL?

JQL stands for Jira Query Language. It's Jira's built-in search language for filtering issues based on fields like priority, status, and resolution.

The query priority = High AND resolution = Unresolved finds all tickets that are marked High priority and haven't been resolved yet. Resolved tickets are filtered out automatically so your queue always shows active work.

Your new queue should now appear in the queue list on the Queue settings page. You'll see Critical - Integration Failures listed alongside the default queues.

Don't see your new queue?

Make sure you clicked Create at the bottom of the form. If you navigated away before saving, the queue was not created.
Check for a red error banner on the form. A typo in the JQL query (like a missing AND or a misspelled field name) prevents the queue from being created.
Help me troubleshoot my queue creation in Jira Service Management.

Create the Standard Support Requests queue

Your second queue catches everything that isn't critical. Medium and low-priority tickets land here so they don't clutter the urgent queue.

On the Queue settings page, click Create new queue again.
Enter Standard Support Requests in the Name field.
Click Advanced in the Filter by section to switch to JQL mode.
Enter this JQL query:

priority in (Medium, Low) AND resolution = Unresolved

What does this query do differently?

The in (Medium, Low) syntax matches tickets that have either Medium or Low priority. This is JQL's way of checking against a list of values instead of a single one.

Configure the same columns as before: Key, Summary, Status, Priority, Created, and Assignee by dragging and dropping in the Columns section.
Click Create.

You should now see both Critical - Integration Failures and Standard Support Requests listed on the Queue settings page.

Create a priority group to organize your queues

Right now your custom queues exist but they're mixed in with all the default queues. A priority group bundles related queues together under a labeled section in the sidebar, so agents can find their Tier 2 queues without scrolling past unrelated ones.

On the Queue settings page, click the Priority group tab.
Click Create group.
Enter Tier 2 Support in the Group name field.
Click Create.
Next to your new Tier 2 Support group, click Manage queues.
Check the boxes next to Critical - Integration Failures and Standard Support Requests.
Click Save.

What is a priority group?

A priority group is a labeled folder for queues in the sidebar. Instead of agents scanning through every queue in the space, they select their group and see only the queues relevant to their role.

In a production environment, you might have separate groups like "L3 Urgent Escalations" for engineering and "Design Team Requests" for designers. Each group gives its team a focused view.

Before you check your queues, predict: which ticket do you expect to see in each queue?

Click Queues in the left sidebar.
Select the Tier 2 Support priority group from the group selector at the top of the queue list.
Click on the Critical - Integration Failures queue.

You should see only the High-priority HRIS ticket ("HRIS integration sync failing for client Acme Corp"). The Medium-priority SSO ticket is filtered out.

Switch to the Standard Support Requests queue in the sidebar.

You should see only the Medium-priority SSO ticket ("Employee unable to log in via SSO"). Each queue shows exactly the tickets it was designed to catch.

Seeing the wrong tickets in a queue?

Double-check the JQL for each queue in Queue settings. A queue that shows priority = Medium instead of priority = High will pull in the wrong tickets.
Make sure both queues are assigned to the Tier 2 Support priority group. Queues outside a group appear under View all queues instead of in the group selector.
If a queue shows zero tickets, confirm the priority you set on your test tickets in Step 2 matches the JQL filter exactly.
Help me troubleshoot why my custom queues are not filtering tickets correctly.

Your queues are now sorting tickets by urgency automatically. Next up, you'll configure SLAs that track how quickly you respond to and resolve each ticket, turning your queue from a to-do list into a time-bound operation.

Configure SLAs with Time Targets and Working Hours

Your custom queues now separate urgent integration failures from routine requests. But there is nothing tracking whether you are actually responding to those urgent tickets fast enough.

The Achievers role specifically calls out meeting or exceeding SLA targets. Without configured SLAs, your queue is just a to-do list with no time pressure. In this step, you will add countdown timers that track your response and resolution speed in real time, turning from green to yellow to red as a breach approaches.

In this step, get ready to:

Edit the default "Time to resolution" SLA with priority-based time targets.
Configure a "Time to first response" SLA with its own targets and conditions.
Verify SLA countdown timers appear on your HRIS ticket.

Navigate to SLA settings

SLA settings live in your space's configuration panel, under the same section where you manage request types and workflows.

In the left sidebar of your "Tech Support Hub" space, click Space settings.
Under Request management, select SLAs.

You should see a list of default SLAs that JSM automatically created with the IT service management template. Look for "Time to resolution" in the list.

What is an SLA?

An SLA (Service Level Agreement) is a time-based commitment to respond to or resolve a support ticket within a set window. In Jira Service Management, SLAs work like stopwatches that start counting down the moment a ticket is created.

Each SLA has three conditions: when to start the clock, when to pause it (for example, while waiting on a customer reply), and when to stop it (for example, when you resolve the issue). If the timer runs out before the stop condition is met, the SLA is breached.

Edit the "Time to resolution" SLA to add priority-based goals

The default "Time to resolution" SLA exists but has no priority-based targets. You will add specific time goals so High-priority tickets get a tighter deadline than Medium-priority ones.

Click Edit next to "Time to resolution."
Scroll to the Goals section.
Select Add priority under a goal.
For High priority tickets, set the target to 4h.
For Medium priority tickets, set the target to 8h.

What do these time targets mean?

A 4-hour target for High-priority tickets means your team commits to fully resolving critical integration failures within 4 working hours. Medium-priority tickets like SSO login issues get 8 hours.

These targets give your team concrete deadlines instead of vague expectations. The timer on each ticket counts down toward zero, so you always know how much time you have left.

Now scroll down to the Conditions section to configure when the SLA clock starts, pauses, and stops.

Under Start counting time when, verify the condition is set to Issue Created.
Under Pause counting time when, add the status Waiting for Customer as a pause condition.
Under Finish counting time when, verify the condition reads Resolution: Set.
Click Save.

Why add a pause condition?

When you send a customer a question and wait for their reply, the resolution clock should not keep ticking against you. The "Waiting for Customer" pause condition freezes the timer whenever the ticket is in that status. Once the customer responds and the ticket moves back to "Waiting for Support," the clock resumes.

After saving, you should see the "Time to resolution" SLA listed with your updated priority-based goals.

Don't see the Conditions section?

Scroll down below the Goals section. The Conditions section sits lower on the same page. If you still cannot find it, make sure you clicked Edit on the SLA rather than just viewing it.

Help me find the SLA Conditions section in Jira Service Management.

Configure the "Time to first response" SLA

The "Time to resolution" SLA tracks how quickly you close a ticket. But the Achievers role also requires a fast first response. A separate "Time to first response" SLA measures how quickly you acknowledge a customer's request with a visible reply.

Return to the SLA list. If a "Time to first response" SLA already exists, click Edit next to it. If it does not exist, create a new SLA and name it Time to first response.
Under Start counting time when, set the condition to Issue Created.
Under Pause counting time when, add Waiting for Customer.
Under Finish counting time when, set the condition to Comment: For Customers.

What does Comment: For Customers mean?

This finish condition stops the clock the moment an agent posts a customer-visible reply. Internal notes that only your team can see do not count. The SLA only stops when the customer actually receives a response.

Under Goals, select Add priority under a goal.
For High priority, set the target to 1h.
For Medium priority, set the target to 2h.
Click Save.

Both SLAs are now configured. Time to see them in action on your tickets.

Before you check, what do you think you will see on your HRIS ticket now that SLAs are configured? Will the timers be counting up or counting down?

Return to Queues in the left sidebar.
Open your Critical - Integration Failures queue under the Tier 2 Support priority group.
Click into the HRIS integration ticket.

You should see SLA timers displayed on the ticket. The "Time to first response" timer shows a 1-hour countdown and the "Time to resolution" timer shows a 4-hour countdown. Both should display green indicators, meaning you are on track.

What do the SLA timer colors mean?

Green means you are on track. As you approach the deadline, the timer turns yellow. If you miss the target entirely, it turns red. These visual signals let you triage at a glance without doing mental math on timestamps.

SLA timers not showing on the ticket?

Make sure both SLAs have a defined time target for the ticket's priority level. If the SLA goal does not include a target for a given priority, the timer will not appear on tickets with that priority.

Also confirm you clicked Save after editing each SLA. Unsaved changes are not applied.

Help me troubleshoot why SLA timers are not appearing on my Jira Service Management tickets.

Your support queue now has real accountability. Every ticket carries visible countdown timers that track your performance against defined targets. Next up, you will walk a ticket through its complete lifecycle, from triage to resolution, and see how the SLA timers respond to each status transition along the way.

Walk a Ticket Through the Full Support Lifecycle

Your support queue now has priority-based triage and SLA timers tracking every response and resolution commitment. The configuration side is done.

Configuring queues and SLAs is only half the job. The Achievers role requires you to reproduce bugs, determine if Tier 3 engineering is needed, communicate with stakeholders, and resolve issues. In this step, you will walk a ticket through every stage of that lifecycle.

In this step, get ready to:

Triage and investigate the HRIS integration failure ticket.
Communicate with the customer and escalate to Tier 3 engineering.
Resolve the ticket and verify your SLA targets were met.

Triage and investigate the HRIS ticket

The first thing a Tier 2 agent does when a ticket arrives is claim it and start investigating. You will assign the HRIS ticket to yourself, transition it to an active status, and document your initial findings.

Click Queues in the left sidebar.
Under the Tier 2 Support priority group, select Critical - Integration Failures.
Click the HRIS ticket ("HRIS integration sync failing for client Acme Corp") to open it.

The ticket detail view shows the priority, current status, reporter, description, and SLA timers all in one place.

Click the Assignee field and select your name from the dropdown.

The ticket is now assigned to you. Next, you need to signal to the team that you are actively working on it by changing the status.

Click the current status (Waiting for Triage) near the top of the ticket to open the status dropdown.
Select Waiting for Support to transition the ticket.

The status badge updates to "Waiting for Support." This tells anyone on the team that the ticket is under active investigation.

Now document your investigation by adding an internal note. Internal notes are visible only to agents, not to the customer.

Scroll down to the activity section at the bottom of the ticket.
Click Internal note to switch the comment type to agent-only.
Type the following investigation note into the text field:

Checked BambooHR API logs. Connection timeout suggests firewall rule change on client side or API rate limiting. Need to verify SFTP credentials and check if client IT made network changes. Reproducing in staging environment.

Click Save.

Your internal note appears in the activity log with a visual indicator (such as a lock icon or a colored bar) confirming it is agent-only.

What is an internal note?

Internal notes are visible only to agents on your team. Customers never see them in the portal.

They are used to document investigation steps, share findings with teammates, and keep a troubleshooting record. In a real support operation, a thorough internal note is what lets another agent pick up the ticket if you are unavailable.

Don't see the internal note in the activity log?

Make sure you selected Internal note before typing. If you accidentally posted it as a customer-visible reply, the note will still appear in the activity log but without the agent-only indicator.

If the activity section is empty, scroll down further. The comment area and activity log are at the bottom of the ticket detail view.

Need more help? Why isn't my internal note showing up on the ticket?

Communicate with the customer and escalate to Tier 3

Your investigation is documented. Now you need to reach out to the customer for more information. This is where your SLA timers interact with your actions.

Sending a customer-visible reply stops the "Time to First Response" clock. Transitioning to "Waiting for Customer" pauses the "Time to Resolution" clock while you wait for the client.

In the activity section of your HRIS ticket, switch from Internal note to the customer-visible reply option (such as Reply to customer).
Type the following customer-facing message:

Hi, we are investigating the HRIS sync failure for your account. Our initial analysis suggests a connectivity issue between your BambooHR instance and our platform. Could you confirm whether your IT team made any recent firewall or network changes?

Click Save.

Check the SLA section on your ticket. The "Time to First Response" timer should now show as completed with a green indicator. You sent a customer-facing reply, which is the finish condition you configured for that SLA.

Why did the Time to First Response timer stop?

You configured the "Time to First Response" SLA with a finish condition of "Comment: For Customers." The moment you posted a customer-visible reply, Jira Service Management recognized that condition was met and stopped the clock.

Transition the ticket status to Waiting for Customer by clicking the status badge and selecting the new status.

What if the status already changed automatically?

Jira Service Management includes a default automation rule that transitions tickets between "Waiting for Support" and "Waiting for Customer" when comments are added. If your ticket already moved to "Waiting for Customer" after your customer-visible reply, that is the automation at work. You can skip the manual transition.

With the ticket in "Waiting for Customer" status, the "Time to Resolution" timer is now paused. The clock does not count time that is outside your control.

Now simulate the customer responding. Since you are the only user in your Free plan environment, you will add a reply on their behalf.

In the activity section, make sure the customer-visible reply option is selected.
Type a simulated customer response: "Our IT team did make firewall changes last week. We will check the rules and get back to you."
Click Save.
Transition the ticket back to Waiting for Support to indicate you are resuming work.

The "Time to Resolution" timer resumes counting now that the ticket is back in your court.

The next step in a real Tier 2 workflow is escalation. You have identified a potential API-level issue that needs engineering investigation. You will create a linked Bug work item to represent the Tier 3 handoff.

On the ticket detail view, find the Link option in the ticket's detail panel or actions menu.
Click Link and select the option to create a new linked work item.
For the issue type, select Bug.
Enter the summary: Investigate BambooHR API timeout - Tier 3 engineering.
Click Create (or Link, depending on what your screen shows).

Your ticket now shows the linked Bug in the details panel. This is your Tier 3 escalation trail.

Why link a Bug instead of reassigning the ticket?

Linking a separate Bug keeps the original customer-facing ticket active while giving the engineering team their own tracked work item. The customer continues to receive updates on their ticket, and the engineering team works on the Bug independently.

The link creates a visible audit trail connecting both issues. If a manager asks "what happened with the Acme Corp sync failure," the answer is one click away.

Can't find the Link option?

The Link option may appear in different locations depending on your screen layout. Look for it in the detail panel on the right side of the ticket, in the top action bar, or under a More actions menu (often shown as three dots).

If you see an option to link to an existing issue but not to create a new one, look for a "Create linked issue" or "Create and link" button within the link dialog.

Need more help? How do I create a linked Bug work item from my Jira Service Management ticket?

Resolve the ticket and check SLA completion

The engineering team (in our simulation) found the root cause. Now you close the loop with the customer and resolve the ticket.

In the activity section, make sure the customer-visible reply option is selected.
Type the following resolution message:

We identified the issue: the SFTP credentials for your BambooHR integration expired during the recent certificate rotation. We have refreshed the credentials and confirmed a successful sync. Please verify on your end.

Click Save.
Transition the ticket status to Resolved.

Before you check the SLA section, predict: do you think both timers (Time to First Response and Time to Resolution) will show green completed indicators? Think about whether you met the 1-hour first-response target and the 4-hour resolution target.

Check the SLA section on your ticket.

Both the "Time to First Response" and "Time to Resolution" timers should show as completed with green indicators. You responded well within the 1-hour window, and the ticket was resolved within the 4-hour window.

What do the SLA timer colors mean?

Green means you completed the SLA within the target time. Yellow means you are approaching the deadline. Red means the SLA has been breached.

In a production environment, these indicators power dashboards and reports that managers use during SLA reviews. A history of green indicators proves you consistently meet your service commitments.

Now review the complete history of everything that happened on this ticket.

Scroll through the full activity history on the ticket.
Confirm you can see every status transition (Waiting for Triage, Waiting for Support, Waiting for Customer, Waiting for Support, Resolved), your internal note, both customer-facing comments, the linked Bug, and timestamps for each action.

Why does the activity history matter?

This activity log is your complete audit trail. In a real support environment, this is what your manager reviews during SLA reporting and what other agents reference if the issue recurs.

For the Achievers Technical Support Analyst role, being able to point to a ticket with a clean lifecycle (triage, investigate, communicate, escalate, resolve) is concrete proof you understand the operational side of support, not just the theory.

SLA timers not showing as completed?

If "Time to First Response" still shows as active, your customer-visible comment may not have been recognized as a customer-facing reply. Go back and check that you posted the comment using the customer-visible reply option, not as an internal note.

If "Time to Resolution" still shows as active, make sure the ticket status is fully transitioned to Resolved. The finish condition for this SLA is "Resolution: Set," which triggers when the ticket reaches a resolved status.

Need more help? Why are my SLA timers not showing as completed after I resolved the ticket?

Secret mission

Create a Custom Automation Rule

You have built queues and SLAs that organize and track your support tickets. But every High-priority ticket still needs manual assignment before an agent starts working on it. Can you create an automation rule that assigns critical tickets to you the instant they arrive?

Clean Up Your Resources

This project runs entirely on the Jira Service Management Free plan, so there are no ongoing costs. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

Jira Service Management Cloud site (Free plan, includes the "Tech Support Hub" service space).
Test tickets, custom queues, SLAs, and automation rules within the space.

Keep everything running

No action needed. Choose this if you want to keep your configured support queue as a reference or continue experimenting with Jira Service Management.

Your Free plan site stays active as long as you log in periodically. Atlassian reserves the right to deactivate Free sites due to inactivity, so logging in occasionally prevents this.
The Free plan supports up to 3 agents and 2 GB of storage at no cost.
The automation rule you created in the Secret Mission counts toward the Free plan limit of 100 rule runs per month. This is more than enough for a learning environment.

Pause - I'll come back to this later

Since this is a free cloud service, there is nothing to shut down or pause to save costs. Your site remains available whenever you return.

Log in to your Jira Service Management site at least once every few months to prevent Atlassian from deactivating it due to inactivity.
Your queues, SLAs, tickets, and automation rules stay exactly as you left them.

Delete - I don't want to use this again

Remove your Jira Service Management site and all associated data. This cannot be undone.

Go to admin.atlassian.com in your browser and sign in with your Atlassian account.
Find your site in the site administration panel.
Select the option to delete the Jira Service Management product from your site.
Confirm the deletion when prompted.
This removes the "Tech Support Hub" space, all tickets, queues, SLAs, and the automation rule you created.

Nice Work!

You just built a complete Tier 2 technical support operation in Jira Service Management. From custom queues and SLAs to a full ticket lifecycle, your support queue is ready for real work.

You've learned how to:

Build custom queues with JQL filters that automatically triage tickets by priority, separating critical integration failures from routine support requests.
Configure SLAs with time-to-first-response and time-to-resolution targets, with start, pause, and stop conditions tied to workflow statuses.
Walk a support ticket through the complete Tier 2 lifecycle: triage, investigate, communicate with the customer, escalate to Tier 3, and resolve.
Secret Mission: Create a custom automation rule that auto-assigns high-priority tickets the moment they arrive, eliminating manual triage for urgent issues.

Ready to quiz yourself?