Many service desk teams need a way to do what they call a “quick ticket.” These kinds of service desk issues are especially useful to teams who take calls or receive other communications from customers which need to be in the system for reporting purposes but don’t need to ‘live’ beyond being recorded since they were resolved on the first communication with the customer.
What these teams need is a way to both create and resolve a new issue at the same time. With a good way to handle first-call resolution, the team can move more quickly on to helping the next customers who need them.
There may be an Atlassian Marketplace add-on to enhance or even replace my approach below, but the great thing is that this requirement from a team can be addressed beautifully with Jira Service Desk right out of box!
First, let’s create a custom Jira field to use on Jira screens where a first call resolution process is needed if you don’t have one already. The idea is to record in a Jira field the fact that the issue was resolved on the first call so that we can then take action when that field gets set.
There are several Jira custom field types that would work, but I’ve chosen to add a Checkbox field. I added only one option to this field: “Yes”.
Now it’s time to create a transition on your Jira workflow. You may even already have a transition from the first status in your workflow directly to a resolved state. If so, you can use that existing transition. If not, create a new transition from your initial state to a resolved state. In my example here, I called my transition “First Call Resolution” and created it from New to Resolved.
There are a couple of things we need to configure on this transition to support our goal:
- Set the Resolution
Since the issue will be moving directly to a terminal state, we must ensure the resolution is recorded in Jira’s Resolution field. I’ve just used “Done” here, but any resolution will work.
- Assign the Issue
We also want to record an assignee for the new issue. This might be optional, depending on your specific requirements. My example reflects one possible business decision, namely that we want the recorder of the new issue to be stored in the Assignee field for reporting.
Note: The first three steps above must be performed by a Jira administrator, but from Step 4 configuration can be both implemented and maintained by a project admin. This is great since we want to delegate any configuration work we can to our project admins to keep our Jira admins focused on system-wide needs.
The last piece to put in place is a new Jira Service Desk Automation rule. This rule will tie in the Jira field we created in Step 1 and the workflow transition we created in Step 2 and configured in Step 3.
Create a new Jira Service Desk Automation rule on your project using the Custom Rule template. I’ve named mine “First Call Resolution”.
Add a “When” event to the rule so that it is only called when a new issue is created.
Add an “If” condition to the rule so that it only fires on the right issues. My example rule will only take action if the “First Call Resolution” field we added to Jira in Step 1 is set and the issue is an Incident.
Now, add two “Then” actions to the new rule.
a) Add the “Transition issue” and Then action from the list. Then select the workflow transition you configured in Step 3.
b) Add the “Add comment” Then action from the list. While this is an optional step, it’s good to document that the rule acted on the issue.
Ready to test it out? Create a new Jira issue, being sure to set the field you added in Step 1.
The new issue shows a resolved status. The Resolution field is set. The issue is assigned to the currently logged-in user. And a comment appears indicating that the issue was a first-call resolution.
We hope this was useful!