There is a problem with Jira Service Management escalations...

If you have worked in a larger company you probably have noticed that escalation between the different support tiers cause a lot of problems. Perhaps you even notice this in medium or even small companies as well. The reason for this is that Jira Service Management is missing functionality that is needed for escalation to work properly. For a tool that claim to be an ITSM tool, this is quite strange, but well in line with the way Atlassian thinks about their products.

If you are unfamiliar with ITSM and support tiers, then I suggest this nice article as a starting point: https://www.bmc.com/blogs/support-levels-level-1-level-2-level-3/. If you don't want to read all that, then the short summary is that in ITSM support is set in multiple levels of technical expertise.

It starts with a basic support, which is to answer the most obvious questions and to make sure the tickets have enough information. Then the tickets Tier1 can not solve goes to Tier 2 which have more technical knowledge and so on. You can have as many tiers as you want, but most models have 3 or 4 where the last tier is outside help towards vendors for example.

Jira Service Management does not support collaboration

This might be a strong statement, but in this case I feel it is actually true. Maybe we should say handovers, which is what we are actually talking about, but since communication has to remain constant towards the customer I feel that this is still true.

So what am I talking about?

In Jira Service Management today there are hard boundaries around the projects that can not be bridged without harming customer experience. What I mean by that is that in order for me to hand over a ticket to another team I am restricted to 4 options:

1. Have everyone working in one giant monolith project.
2. Move the ticket to another project.
3. Clone the ticket to another project.
4. Create a linked ticket to another project.

Before we dive into what these 4 options mean, let us first define what our customers expect from the interaction with support. From a customer perspective they have a problem, or a request of some sort and they have done their job by submitting a ticket to support. They now expect support to handle their request and solve their problem in that ticket. This is a fair expectation and if we break this expectation they will experience frustration.

1. One Monolith to ruin it for all

This is by far the most common way to work in small companies and it is how Atlassian envision us using Jira Service Management. One box where everyone that needs to be involved have a role. The problem with this setup however becomes very apparent when you start to grow as an organization, or when you start to have multiple products and services with shared resources.

Not only will there be a lot of people in the project, perhaps several hundred people or thousands even if the organization is large, internationally distributed or need to handle multiple companies setup because of company structure or acquisitions. To be able to make sense of a large instance with many teams you need to make a lot of queues and this is where the first problem is with Jira Service Management today: There is no nesting of queues. You have to get an add-on to handle that, which add cost to your already quite expensive platform.

The second problem is that when you mix many teams in one project, you will start to add complexity as the various teams want to customize their experience. You will start to build automations with multiple exceptions, you need to start adding local groups with all the problems that come from that and you will have subsets of screens connected to customized issue types and... well you get the idea. It quickly becomes messy and soon you will have manuals for how to work based on what type of request for which team you are working for to navigate all those custom fields that confuse everyone.

This is a horrible way of working.

If we instead work with Jira Service Management where we have an IT Support desk for first line support (Tier1) and dedicated projects for Tier 2 and Tier 3 teams, then we are in a much better place. But there are still issues...

2. Move ticket to another project

Our first option when not working in a monolith when we want to hand over a ticket to second or third tier teams is to move the ticket to their project. It makes sense technically because the tier 1 team will have no more involvement with this ticket and it should not be handled by another team.

From a customer service perspective it is a terrible option, however. Not only do you break all old communication because by moving you are now changing the URL and the ticket ID. This will make all old communication useless because links will not work and the poor customer no longer can reference the ticked ID as they now have a new one.

Technically you also have permissions to consider and if you do not have the same setup the customer can lose access to their ticket all together. The information in the ticket can also vanish if you do not use Forms and the custom fields are not the same in the projects.

Any SLA you have will also be ruined since each project have their own SLA and when you move a ticket the SLAs will be reset as they are counted again with the new SLA in the project they are being moved to.

In short: Never move support tickets if you can avoid it.

3. Clone the ticket to another project

This is an even worse solution than moving the ticket. Not only do you get all the negatives from moving the ticket, you also duplicate the information. This means that the customer now have two identical requests, but you also have different statuses and different communication. If you for example clone the ticket and then close the initial ticket, the customer will get a notification that their request has been closed, which will confuse the heck out of them when they then get a reply in a ticket that look identical, but with a different ID and different URL.

In short: Never clone a support ticket unless you REALLY want to frustrate your customers.

4. Create a linked ticket to another project

This is very similar to cloning the ticket if you are doing it wrong. That would be that you create a linked ticket and assign it to the customer. Then it would just be a cloned ticket you have linked.

Used correctly however that creates a separate conversation between the two teams. This is how it should be used in Incident Management for example where we need activities to be performed in development or Infra teams for example.

This will not help us in our scenario where we want to make a handover, however as the customer conversation still will be in the original ticket. We could build an automation that sync the conversation between the original ticket and the linked ticket, but since that will be posted as the actor in the automation communication will look very bad on both sides.

We will also still have to keep the original ticket open in the project for the Tier 1 team, even though they no longer have any involvement. The customer experience might be ok, but the setup will clutter up the queues for the Tier 1 team. The Tier 1 team will also be responsible for the SLA, which means that they might unfairly get bad SLA results because of the Tier 2 team activities.

In short:  this is probably the best option, but it is not very good.

How do we solve this then?

Without knowing the architecture of Jira Service Management the suggestions here might be more or less difficult to accomplish, but I will make the suggestions based on the customer experience and UX rather than architecture.

1. Change Queues to allow tickets from any project

I can not for the life of me understand the architectural decision to restrict this when boards have had this functionality forever. Just this small change alone will make Queues so much more useful and it will allow teams to work with multiple requests from one area. Queues for Jira Service Management have the right idea, but they focus on local groups, which any sane Jira Administrator avoid like the plague, especially if they already sync users with the AD.

Make Queues like boards so they can be attached to projects or a user. Not only will that allow teams to work cross projects, but it will also open up for different views that can lead to add-ons or native improvements to how support in general can be designed.

2. Add account sync to automation

It would be very nice, not just for thise scenario, to be able to synch comments WITH the account that made the comment rather than using the automation agent as the author. This will allow for a better customer experience and it will make many types of setups feel more seamless than it does today.

3. Build a native handover function

While we can work with custom fields to handover ticket between queues if we get the change to queues to allow data from any project, I would much rather see a native function in Jira Service Management. The reason for that is that it would allow extending that function with more innovation and standard functionality.

The way I envision it a customer agent would just click on a handover link or button and then get a screen like the move screen. There they can select what project they want to hand over to and possibly what team. A comment field can be there by default if they want to add an internal comment as well.

When the support agent submits the ticket is flagged as handover and in their project it will no longer be visible by default in the original project (as it has been handed over). There should be a way to set up a queue to see all handover tickets however if that is wanted. This action will also trigger a new ticket in the project the support agent handed over the ticket to.

What makes this different from just a linked ticket then?

The first change is that the handover ticket work like a cloned ticket with the same information as the original ticket. This means that reporter for example is the customer and not the support agent as when you create a linked ticket.

The second change is that all comments are synced between both ticket with the account information on who made the comment. This way the communication is seamless from the customer perspective and the support agents. It also means that everything is synced toward the original ticket, making that the master regardless if the ticket has been handedover due to escalation.

If the handover ticket is handed over, then the same steps should happen, but the sync should now be done twice, once for each of the tickets in the chain.

What about the workflows?

This is a problem as many teams what to have their own workflows. As we can not, or want to, force people to have the same workflows, we need to figure out what status we will show to the customer. Each ticket will of course show whatever status the team put it in so they can follow their workflow in Jira Service Management, we just need to consider what to show to the customer in the portal.

I can think of several ways to solve this.

The first solution is to just add a label instead of using the workflow. This label can just say Escalated for example and the label stays until the ticket is closed. It is simple, but perhaps not the best from a customer experience perspective since the status actually is communication.

The second solution is to choose either the original ticket workflow or the handover ticket workflow. This can cause some strange scenarios if there are many different statuses between the original ticket and the handover ticket. Having status change from in progress to Open or New for example might be a little weird. While that can be fixed with not changing status from the original ticket to the handover ticket until it has moved at least one transition, it is not fool proof and can be confusing.

The third option is to treat this as some form of integration so we setup a mapping between different projects. This would be a massive thing to build and a pain to manage, but if done well it could probably be used for other things as well. This require you to do a lot of work also every time a new project is added that you might want to handover to.

The fourth option would be to present a choice when you transition a hand over ticket with the combined list of statuses from the original ticket or the handover ticket. It is messy and pretty much the same as #2, but less useful.

There are of course more solution to this, so if you have a good suggestion, please add it in the comments.

Communication must be taken seriously

Regardless how we look at support and what solution we prefer for escalating to other teams, we must remember that communication is key. No matter how good we are at solving problems it means nothing if we agitate the customers by not communicating while we solve their problems.

By breaking communication in any solution we have today, or forcing teams to be suboptimal by working in monolith projects we are limiting the potential of providing exceptional support to our customers.

I think we should take this seriously.
What do you think?