JIRA as a Support System

Wanting to use JIRA as a support system or helpdesk? Check out JIR A Service Desk: it provides a customizable customer help portal, powerful SLA management and realtime reporting.

Introduction
This document shows how to set JIRA up as a support system or helpdesk. We all know JIRA is a great project tracker. It's great at tracking tasks and managing issues, and that's what a helpdesk is all about! Lots of customers are using JIRA for a helpdesk because of its versatility and extensability. Below we'll tackle the ways JIRA can address the key features required in a helpdesk. This page includes general tips. We've also written up a document specifically about support.atlassian.com. Check out How Atlassian Uses JIRA for Support.

Security
Project Security versus Issue Security
Typically as an end user you can only see issues that you, or your company has raised. You can secure your issues either via project security or issue security.
Project Security

At a very simple level, if you are supporting a very limited number of clients, you can set up a different project for each of your clients, with a different permi ssion scheme for each project. This also works well for an internal helpdesk, where you can set up a project for each department. You can set up the permissions so that only the reporter of an issue, and the support staff, can see the issue (i.e. give the 'Browse Projects' permission to the Reporter and appropriate internal groups). This means that each user can only see their own issues, and is very suited to an internal help desk system, or any other support system with a large number of end users. If you pick project level security, you'll also get the benefit of project level workflows, issue types, and screen schemes.
Issue Level Security

You can set up different security levels for each customer. This is similar to having different projects, but allows the support team to manage the issues in just one project.

2
On this page: Introduction Security Project Security versus Issue Security Ticket Management Workflo w Shared Filters and Dashboa rds JIRA Agile Escalation and SLA Reporting and Analytics Time Tracking Built-in JIRA Reports Extendin g the Reportin g Structur e Multi-Channel Support Email Chat Phone Knowledge Management Customer Portal and Integrations Example Scenario Further Support Discussi on Related Best-Pra ctice Discussi ons

Ticket Management

3
Workflow
Take some time to learn about Configuring Workflow, and set one up that caters to your customers. A few tips: Make transition names action names. Think of them as the titles of the buttons. Make status names the names of states. Think of them for your reporting, for how long a ticket waits in a status. Use conditions to hide certain buttons from certain groups, both for simplicity and security. For example your different escalation paths might be executed by different groups.

Shared Filters and Dashboards

Create your work queue with Shared Dashboards and Shared Filters. Keep in mind that some filters can be personalized, using 'currentAssignee' or other Advanced Search features. The JIRA toolkit will show you whether the last commented was from a JIRA Administrator, or whether it was from a customer. This allows issues to be prioritised by the order in which they need a response. Read about How Atlasian Visualizes our Support Queue.

JIRA Agile
JIRA Agile is great for support! It offers the following features, for triage and lifecycle management: 1. Story Points are a good way to consider triaging tickets. More complex tickets - such as performance or setting up a new system - can get a higher number of story points. This can help gauge capacity. 2. Use the Rapid Board to figure out where your backlog and churn are. For example, you may have few new tickets coming in, but a lot waiting for customers to get back to you. The Rapid Board is a great way to visualize where your work is throughout its lifecycle.

Escalation and SLA

For a proper helpdesk, you'll need to manage your service commitments, whether they are internal or public. Here are a few tips on how to do that:
Jelly Scripts

The most powerful approach is to write a Jelly script (sample available) which invokes a saved search (filter), and loops over the issues, adding a comment, transitioning them to a new state (e.g. "Requires Response"), or otherwise letting people know that action needs to be taken. This Jelly script would then be run periodically by a Jelly runner service. Atlassian uses this approach on https://support.atlassian.com, to automatically close issues that have not been replied to in X days. We have a filter returning issues in status "Waiting for Customer", updated from any time to 1 week ago (i.e. not touched in the last week), and these are transitioned to "Inactive", which triggers an email letting the customer know.
Filter Subscriptions

To notify managers or senior staff about when an issue is in breach of or about to breach a service commitment, consider filter subscriptions. See Receiving Search Results via Email for a description. Create a search filter that finds all issues that meet a certain criteria. Save this filter and subscribe to it, either by email (through JIRA) or by subscribing to the filter's RSS feed in an RSS reader. This way JIRA will notify subscribers what issues are 'outstanding'. For more information on creating and saving filters and subscriptions please see this page. There is also a short video on Simple SLA with Filters.
Extending JIRA with a Service

If a Jelly script cannot do what you want, or JIRA's searching capabilities are not sufficient to match issues you want, you could write a custom service that locates issues that meet a certain criteria and then does something with matching issues. For example, a service could reassigns the issues to another team member (e.g. project's lead), increments priority, sends notifications, etc. For more information on JIRA services please see this page. For an example of code that uses JIRA's API to escalate issues please see: Simple Escalation.

4
SLA Plugin

Check out Vertygo's SLA plugin in the Atlassian Marketplace and SLAdiator - service level agreement real-time monitor for JIRA.

Reporting and Analytics

Reporting is a key component to a great helpdesk.

Time Tracking
The Time Tracking Report is a great way of understanding where your time is spent. Consider it in combination with Defining a Component, so that you can bill back to certain services or departments. For an external helpdesk, or one where you need to hide the time tracking field, you may need to implement a custom field. See 'Admin-only editable field' from our developer docs for a guide on restricted custom fields.

Built-in JIRA Reports

JIRA has a good number of built-in reporting. See Generating Reports.

Extending the Reporting Structure

Business Intelligence

If your company has a data warehouse, JIRA fits into this nicely. JIRA's database model is described here, and there are some great community-driven SQL tips here.
EazyBI

If you'd like JIRA to house its own business intelligence, the EazyBI plugin is a good option.

Multi-Channel Support
Email
JIRA can easily be set up to handle incoming email, and create new issues, or comment on existing issues. It also sends mail notifications to users when the issue has been updated. When setup this way, the client can create and comment on an issue, without having access to JIRA. For more information, see the documentation on Setting up email integration in JIRA particularly the CreateOrCommentHandler. To customize the email templates with your branding, see Customizing Email Content. To handle transitioning issues to a new workflow status when you receive an email response, see the auto-transition listener in the JIRA toolkit. The Enterprise Mail Handler for JIRA (JIRA 5.0+) plugin provides comprehensive inbound mail processing (including ability to manipulate JIRA issues via Directives, live template editing, integrated event listener and more), for more information see the wiki.

Chat
Integrating JIRA with chat can happen in two ways. From a chat client to JIRA is available through the JIRA REST api. Alternatively, displaying chats in your working IM client is a great way to notify staff of a new or updated ticket. Check out JIRA's HipChat and Jabber integrations.

Phone
The create or comment handler can also handle attachments. Many phone systems will send voicemails over an

5
email, so it's possible to create a phone support project that takes attachments over email, adding voicemail messages to new tickets. See Logging Phone Calls In JIRA. Our ShipIt VI Winner, JIRA Caller ID, is still under development. Check in there for updates.

Knowledge Management
Integration with knowledge management is a key piece of a great support tool. Here are some of JIRA's Knowledge Management features:
Remote Issue Linking

See Configuring Issue Linking. You can add links to Confluence, other JIRAs, or different resources altogether, to measure and manage the support tickets that were resolved by a resource in a different system. This is a powerful tool for measuring and understanding which things resources are helping solve tickets.
Suggestimate

Suggestimate is a plugin that tracks other tickets that may have been already filed, to cut down on duplicates. Check it out in the Atlassian Marketplace.

Customer Portal and Integrations

Rest API

The SOAP and REST APIs for JIRA are quite powerful ways to integrate third party applications with JIRA. You can create a full portal application for creating and managing issues in a simple email portal, using the REST API. For inspiration, check out what's possible in the game Minecraft, using JIRA's REST API.
Plugin Development

JIRA is customizable in substantial ways, if you're ready to dive into plugin development. Get started over at our development hub.

Unknown macro: {HTMLcomment}

http://tinyurl.com/jira-sla-example

Example Scenario
Here is an example scenario for a support environment within an organisation and suggestions on how to setup JIRA to fit this environment. 1. End-users: company workers place phone calls to the 'hot-line' team. 2. Hot-line: answer the end-users and open a ticket for every issue 3. 1st level Help Desk: analyse hot-line tickets, and close them if they are able to respond themselves. Otherwise they dispatch the ticket to one of three 2nd level help desk teams. a. Technical 2nd level help desk b. Functional 2nd level help desk c. Logistic 2nd level help desk The best way to setup JIRA for the above environment is to create a separate JIRA project for each of the four support groups (one 1st level support team and three 2nd level support teams). It would also be useful to create a separate permission scheme for each project so that permissions can be managed for each project separately. For more information on permissions please see: Managing Project Permissions The hot-line team will create a new issue in the 1st level support team's dedicated project (referred to as 'hot-line' project from here on) for every call they receive. The way the hot-line project should be setup depends

6
on whether the actual end users need to see JIRA issues. If yes, ensure that every member of this hot-line team has Modify Reporter permission so that they can set the 'reporter' of the issue as the actual end caller. It is also possible to create a custom field of type User which can be used to track who (which member of the hot-line team) actually created the issue. The hot-line team member will have to populate this field with their username. For more information on custom fields please see: Adding a Custom Field You can then give the Browse Project permission in the hot-line project's permission scheme to the 'Reporter' role (please see the permission documentation referenced above for more details) and 2 user group . One user group will represent represents the hot-line team and the other the 1st level support team. This way, the end users can see issue created on their behalf, but not issue's created for other users. The hot-line group members and the 1st level support team will be able to see all issues in the project. If the actual end users do not need to see the issues in JIRA it is probably better to not give the Modify Reporter permission to anyone for the hot-line project. The reporter field of the issue will then automatically default to the logged in user (i.e. the hot-line group member who is creating the issue). A custom field of type User can still be created and used to record on whose behalf the issue was created. The field will have to be populated manually during issue creation. This custom field can also be made 'required' so that it will have to be populated during issue creation. The user group representing 1st level support team should be given the resolve and close issue permissions so that they can resolve/close issues once they are dealt with. I also recommend setting the 'Assignable User' permission in the hot-line permission scheme to the user group representing the 1st level support team, so that issues can be assigned to them. The 'Assign Issue' permission can be given to the hot-line group so that its members can assign issues to specific 1st level support team members. Alternatively, the 'Assign Issue' permission can be given to only the 'Project Lead'. The default assignee of the hot-line project can be set to 'Project Lead' or 'Unassigned' (if unassigned issues are enabled. Then the hot-line project's lead can go through all the issues assigned to him/herself or all Unassigned issues and assign them appropriately. If the 1st level support team members cannot resolve an issue they should create a new issue in one of the other three projects (the technical support project, the functional support project, logistics support group project) to indicate that the issue has been passed to the 2nd level support. For this to occur the 1st level support team must be given the 'Create Issue' permission in the permission schemes used by these projects. The issues created in the 2nd level support projects should be linked to the issue in the hot-line project using Issue Links: Configuring Issue Linking Each of the 3 support projects can be setup as required by each team, in terms of their permissions, notifications, workflows, etc. If all internal users are stored in a LDAP directory, please take note of JIRA's LDAP integration: Connecting to an LDAP Directory JIRA's customizable workflow can also be very useful: Configuring Workflow The workflow can be customized for each project, and can be used to better reflect the business process of each support team in JIRA. For example, if issues can only have 2 stages (Open and Closed) then it is far better to create and use a custom workflow rather than use the JIRA's default workflow. Using JIRA's flexible plugin system it is also possible to extend JIRA's functionality in regards to workflow. One place where this can become useful, is when closing issues in the hot-line project that have linked issues in one or more of the 2nd level support projects. It is possible to write a custom Workflow Condition that will look at all the linked issues and only allow an issue to be Closed when the linked issues are also closed. This will ensure, that the issues in the hot-line project are only closed when the linked issues are handled by the respective 2nd level support team. For more information on creating custom workflow elements (e.g. Workflow Conditions) please see: How to create Custom Workflow Elements for JIRA 3

7
If one of the support teams also has an existing support system in place that they would like to continue using, it should be possible to integrate that system with JIRA. JIRA has a number of extension points that can be used to communicate (and hence integrate) with external systems: Extending JIRA By default, JIRA related issue links do not affect workflow, so users can close issues even if other open issues are listed as blocking it. You can enforce the rule that all blocking issues must be resolved before you can resolve the parent issue using the custom 'blockingLinksClosed Condition' workflow plugin.

Further Support Discussion

How Atlassian Uses JIRA For Support Adding Knowledge Base Functionality To JIRA LinkedIn: http://www.linkedin.com/answers/technology/information-technology/computers-software/TCH_I TS_CMP/119007-10510274 Quora: http://www.quora.com/JIRA/What-are-good-ways-to-set-JIRA-as-a-support-system

Related Best-Practice Discussions

JIRA as a Support System JIRA as a Support System JIRA as a Support System JIRA as a Support System JIRA as a Support System JIRA as a Support System JIRA as a Support System JIRA as a Support System JIRA as a Support System Confluence UI Guidelines Confluence UI Guidelines Confluence UI Guidelines Using JIRA for Agile Development JIRA as a Support System Using JIRA for Project Management This document is a work in progress. Feel free to add any comments below.