JSM implementation case study: request escalation and transfer

In this article, we talk about escalating and transferring support requests to other teams using JSM.

Remember, in previous articles in this series, we looked together at how we had set up several technical and business support projects with Jira Service Management (JSM) at my customer's site:

• First of all, we thought about how Jira would be used in their context. Then the choice of a flexible and adaptable solution to meet their different needs;
• Then the addition of automatic routing of requests to the right helpdesk.

I now propose to introduce two new mechanisms to enable assistance teams :

• Escalate a request for assistance to a level 2 team;
• Transfer a support request to another support team.

In this article, we'll look in detail at the implementation of the solution adopted for request escalation. Transfer will not be discussed in detail, as the parameterization is very similar to escalation.

As a reminder, my client uses the following plugins:  

• Script Runner ;
• Automation for Jira (included in Jira Software and Jira Service Management Data Center) ;
• Assets - ex Insight (included in version 4.15 of Jira Service Management Data Center).

Climbing, transferring or both?

Before we begin, I would like to clarify the difference between the two terms used by my customer:

• In the case of escalation, the agent asks for help from another team, known as "level 2", which has the skills and knowledge required to resolve the request. This might be a software development team, for example, which is able to correct an anomaly detected by a user. During escalation, the agent retains control of the user's request: he remains his privileged interlocutor, and the user does not see "what's happening" on the development team side. It is the agent who will act as the link between the level 2 team and the user, if necessary;
• In the case of transfer, the agent sends the support request to another support team who will take over. This may be necessary, for example, if the user has used the wrong channel to report the problem, and the request has fallen to the wrong team. During the handover, the agent hands over responsibility for processing the request to the other team. He no longer follows it up. The new support team in charge of the request exchanges directly with the user.

Escalation to the IT department: the need

The three support teams needed to be able to escalate requests to the application teams on the IT department side:

• The Strawberry and Pineapple teams wanted the target team to be automatically deducted according to the qualification of the request. For example, if the request concerns the SUPERAPP application, then the request should be escalated to the team in charge of the SUPERAPP application;
• The Apple team wanted to be autonomous in choosing which team to escalate the request to, from a very specific list.

The Strawberry team also needed to be able to specify to the target team a list of actions expected during the escalation.

Finally, all three teams wanted assistance requests to be in a dedicated state following escalation, so that they could be easily isolated. The support request would then automatically return to a given state when the escalated request was resolved. In this way, the support team would know that it could regain control.

On the end-user side, depending on the situation, this stage may or may not be completely transparent.

Level 2 teams needed access to the context of the support request, visibility of exchanges with the end-user, and knowledge of the agent in charge of the support request so they could contact him or her when necessary.

Transfer between support teams: the need

The Apple team specializes in technical assistance and equipment management. The Strawberry team specializes in business support and expertise. It's not uncommon for a user to make a request to the wrong channel, and for it to fall to the Strawberry team. Whereas the problem concerns the Apple team.

In such cases, the Strawberry team could simply close the user's request, telling him he's made a mistake. But that's not very nice: he's probably already spent some time trying to formalize his request on the problem that's been bothering him all day, and bam, he's told that no, this isn't the right place... and since we don't talk to each other between teams and it's not our place, we have to do it all over again.

From a user's point of view, my customer is a single entity. It was therefore important that, in the event of an error, the switchover to another team should be as seamless as possible.

For this reason, each of the two teams needed to be able to easily transfer a request to the other. The transfer had to involve changing the state of the initial request automatically, with an appropriate resolution (to identify them later).

The user also needed to know what was happening. His first request is closed, but another is automatically created for him, with a link to access it.

How to use the standard "Create a linked ticket" functionality

In view of the various requirements, we quickly identified the following solution:

• Whether transferring or escalating, a new request must be created in the project concerned. There is no question of moving the original request for reasons of subsequent monitoring and analysis;
• A link must be created between the two applications, the original and the copy.

To meet the general need for team escalation, Jira editor Atlassian proposes to use the standard Create a linked ticket functionality.

This feature is available from any support request. It enables you to quickly create a new request in the project of your choice, which will be linked to the original request. When using this feature, a creation screen pre-filled with some information from the original request is displayed to the user, who can then :

• Select the Jira project in which you wish to create your new request;
• Select the type of link between the two requests;
• Adjust the content of initialized fields, such as the summary or description ;
• Complete the mandatory fields of the target project;
• Choose whether or not to copy attachments.

On paper, this feature seems to meet many of the needs outlined above, and may even be perfectly functional for some organizations. However, we very quickly identified several bottlenecks to its use in our context, which led us not to opt for this solution:

• Too many elements are left to the agent's freedom and manual action, which can lead to errors and inconsistencies:
  • The feature does not trigger a status change: the agent must therefore remember to do this after or before copying the request;
  • The target project must be chosen from a list of all the projects to which the agent has access, which can potentially be very long and difficult to read;
  • The agent is free to choose the type of link;
• Only the mandatory fields of the target project are proposed in the form: the agent cannot complete other fields that might have been relevant;
• Information can be lost, such as comments, custom fields and attachments, if the agent forgets to explicitly check the Copy attachments box.

These elements can lead to faulty applications and malfunctions in the set-up. If the status is not properly updated, SLAs, for example, will not be paused or stopped. And if the link type or status is incorrect, the original request will not automatically change status when the copied request is resolved. Finally, if the target project for the escalation is not the right one, this will generate complexity for the teams, as well as wasting time where responsiveness is generally expected.

So, when in doubt (and in the interests of preserving forests), we opted for a specific solution tailored to our different needs. A technical solution, once again requiring the use of a plugin like Script Runner.

Choice of a customized but controlled solution

The solution therefore consists in setting up different transitions dedicated to each case (transfer, escalation). Each transition enables :

• Manage the change in status of the request ;
• Propose a transition screen with additional fields if relevant;
• Execute a Groovy script that will take care of all operations "under the hood", i.e. :
  • Recover target project for escalation or transfer ;
  • Create a copy of the support request ;
  • Enrich and adapt the data in the application copy, before saving it in the target project;
  • Create a link of the right type between the original request and the copied request;
  • Inform the various stakeholders of the actions carried out.

It's time to get out our best keyboard, our favorite code editor and a thermos of coffee: we're back to coding (well, we've got a few preparatory actions to do first)!

Implementation of escalation of a support request for the Strawberry team

Together, we're going to set up all the parameters needed to perform the escalation and what follows for the Strawberry team. The method is similar for the other support teams.

Prepare the necessary settings

The first step is to prepare in Jira all the elements we'll need to carry out our climb.

We have seen that one of the first things to implement is the deduction of the target escalation project according to the qualification of the assistance request. This value must be able to be overloaded by the agent during escalation. To do this, we need :

• Identify the escalation Jira project for each relevant helpdesk form;
• A custom field that brings up the list of Jira projects.

To easily isolate and identify escalated requests, we also need a dedicated report, and link types that we'll use to link support requests to requests copied across projects.

The Strawberry team also wanted to be able to pass on additional information to the team to whom they escalate the request. We already have a free text field Expected actions DSI in our Jira instance, which we reuse.

We now have everything we need to set up our climbing transition.

Setting up a transition dedicated to climbing

We need to create and configure our climbing transition. Beforehand, we have created a small transition screen which contains at least the fields :

• Climbing project
• Actions expected DSI
• Attachment 

The escalation transition is ready. All that remains is to set up the script that will perform all the operations of copying, updating data and so on. The script is a post-function script, placed as its name suggests, after the transition. To find out more about this type of script, please consult the editor's documentation: Post Functions Tutorial (adaptavist.com).

Here we are! The script is in place and the transition is now functional. Make sure you allow agents to create requests in potential escalation projects.

Automate the change of state of the original request when resolving the escalated request

To increase efficiency, we implement an automatic rule that changes the status of the support request when the escalated request is resolved. In this way, the support request returns to the list of requests to be processed.

In concrete terms, the rule must :

• Trigger when a request linked to a support request with the right type of link switches to a "final" state;
• Update support request status.

What about transferring a support request to another support team?

Implementation of the solution for transferring a request remains very similar to that for escalation:

1. Prepare the necessary settings, i.e. create a specific report and/or resolution to easily identify requests transferred to another team;
2. Create a transition dedicated to the transfer, for example Transfer to Strawberry, without manually choosing the target project, since we know it in our case;
3. Set up a Post-function script to copy the request and set up the link between the two requests.

In addition, the script should include a public comment on the original request, informing the user that the request has been transferred, and indicating the link to the new request.

Two or three groovy scripts later... The final word

You've made it this far: thank you for your patience and time. I concede that this series of articles is not necessarily good for the headache.

But after all these steps, we've seen that there are solutions to make the process of requesting assistance as smooth as possible:

• When it is created, by automatically assigning it to the appropriate support unit;
• In the event of escalation or transfer, by copying the request "cleanly" in one click to the right project;
• During processing, by having a maximum amount of information from the moment it is created, and then qualifying it thanks to the Assets repositories.

We have also seen that there are a multitude of solutions for adapting your Jira Service Management to your needs and organization. Sometimes, the standard is enough. But acquiring an all-purpose complementary plugin such as Script Runner can be more than useful and cost-effective, provided you have the skills to make full use of it.

If I had to give one recommendation after a few years working on this subject, it would be tobe patient and do things step by step. There's no magic formula that's going to get it right the first time. Even after 10 brainstorming sessions with the leading experts.

It's through trial and error, more or less successful attempts, improvements and feedback from your users that you'll progress towards the solution that suits you best. What works for my customer may not work for you, or at least not without adaptation. But your tool should be a facilitator for your teams' day-to-day work, not a constraint. So it may be worth spending the time it takes to get there.

---

Cover illustration by pch.vector on Freepik