Five Tips for Building Better Service Request Workflows

Abstract

Team service requests will be created and updated by customers and service desk agents, who may or may not be familiar with Jira Service Management, or Jira Service Management terminology. The service request workflow needs to be intuitive and concise. These five tips are intended for teams to use when working together to design their service request workflows, and to encourage workflows that are better by design.

Use the same verb for the workflow status and transitions

Using consistent plain English throughout the Jira workflow will make it intuitive and easy to use. The simplest way to achieve this is to use the same verb for the status and the workflow transitions, for example:

• The transition “close” changes the status of the ticket to “closed”
• Or the transition “approve” changes the status of the ticket to “approved”

A common approach is to use the present tense for the transition – “close” – and the past tense for the status “closed”. Alternatively, some may prefer to use the continuous tense for some statuses, but still use the same verb – for instance, “Progress” and “Progressing”.

This simple tip will ensure that customers and service desk agents know what the result of any workflow transition action will be.

Understand the happy path

Most service requests will follow the same transitions and status changes throughout the workflow; this is known as the “happy path”. The happy path should be streamlined to have a minimal number of transitions and status changes necessary to complete a request. As a rule of thumb, a happy path should involve fewer than 6 steps or Jira workflow transitions that the ticket must move through.

If the happy path has more than 6 transitions, check if it can be simplified further by removing:

• Redundant waiting or ready statuses – for example, consider ‘reviewed > ready for approval > approved’  – the queue of tickets for approval, are probably those that have been reviewed, so ‘ready for approval’ is not needed.
• Statuses that will only apply to a minority of service requests – in which case they may be better managed with their own Jira issue (ticket) type and workflow.
• Statuses that represent handovers between teams – these might be better modelled through ticket assignments or dynamic queues.

Maintain the locus of control

The outcome of a service desk agent’s actions should always be within the agency of the Jira Service Management agent. The service request workflow should be designed so that the agent is always in control of the ticket status. There are three simple rules you may want to consider, in ensuring that your workflow supports your service desk agents' self-efficiency:

1. Allow workflow transitions to be undone. For example, if you have a workflow transition “Order” and a status of “Ordered”, then you should add an undo transition of “Undo Order”.
2. Limit the use of workflow conditions and workflow validators to permissions. If fields need validation, it is often better to report on non-compliance, than impact every user interaction on the workflow.
3. Make every workflow transition meaningful to the service desk agent.

Understand the difference between resolution status and workflow status

The workflow status describes where a ticket is in the workflow, whereas the resolution status explains why a ticket is not active anymore. For example, a ticket is in the workflow status of “Closed”, but it was closed because it was cancelled with a resolution status of “Cancelled”. By having both a workflow status and a resolution status, it provides more granular closure reporting options: for example, “Closed (Completed), Closed (Cancelled), Closed (Duplicated)”

The resolution status is set when a ticket moves from an unresolved state to a resolved state. Likewise, the resolution status needs to be removed if an issue flows back into an unresolved state. This can be achieved using the workflow post-function ‘Update Issue Field’, to set or unset the resolution status on the transition.

Encourage customer self-service

One of the most overlooked features of Jira Service Management is allowing the customer who creates a service request, to transition the ticket via the Customer Portal. This allows the service desk customer to self-service, updating the ticket if they have resolved it themselves or withdrawn the request.

To show a workflow transition in the customer portal, you must enable the transition in the Jira workflow editor; when editing the service request workflow in Jira, select ‘Show transition on the customer portal’ on a highlighted transition.

Consider allowing your service desk customers to perform basic transitions on the portal, for example:

• Cancelling, postponing or withdrawing a request
• Marking a request, resolved or completed
• Marking a request, unresolved or incomplete
• Escalating an overdue or high-priority request

Conclusion

Whenever you design any Jira workflow, we’d recommend gathering everybody involved around a big screen, with the Jira workflow editor open, collaborating and discussing the workflow design in a workshop. The next time you need to design a service request workflow –  or any Jira workflow for that matter – consider these tips, as an aide-mémoire or review checklist, and build a better workflow.