What are your best practices for multi-Level Incident Management & Escalation (L1, L2, L3)

[#1]

Hi Atlassian Community,

We are in the process of setting up Jira Service Management (JSM) to handle incident management for our organization.

Our support model is based on a help desk structure with three support levels: Level 1 (L1), Level 2 (L2), and Level 3 (L3).

We want to ensure that our JSM configuration supports clear escalation paths between these levels and provides transparency and efficiency in our incident resolution process.

How do you configure it on your side ?

1. Project Structure:

   • Are you using a single JSM project for all support levels, or a separate projects by support tier or team?

   • What are the pros and cons of your approach?

2. Workflow Design:

   • How do you design our workflows to reflect the different support levels and escalation steps?

   • Do you have any recommended statuses, transitions, or custom fields to clearly indicate the current support level and escalation state while keeping the ability to track SLA ?

3. Roles & Permissions:

   • Do you you have any specific configuration for roles and permissions to ensure each support level has the right access and responsibilities?

If you have experience implementing a similar structure in JSM, I’d love to hear about your setup, lessons learned, and any templates or resources you can share!

I guess this discussion could become very useful for a lot of new comer to Jira Service Management.

Thank you in advance for your insights and recommendations.

[Tim Braxton]

Hello Patrice,

First, I'd look at what Atlassian states about Incident Management. Download the PDF handbook there as well. Share both the link and the handbook with others involved in the setup and policy for incident management in your organization. There is more information at the link than in the handbook - the navigation is clunky, though. Not found in the handbook for example, are IT Support Levels. Atlassian includes self service and external support as level 0 and level 5, respectively.

It appears that you have a pre-established support model. Are you moving from another Service Management system? Make sure you use the lessons-learned or issues you had from using that system. Often, it is the policies in place and trying to make the new system look like the old that can make the system seem poor to agents and customers.

Keeping up with service management system improvements that could make things better for your customers and agents can be a challenge. To build the best possible solution for your customers, you may want to seek help from gryd.io, APETECH LLC or ServiceRocket.

Hope this helps!

[Dirk Ronsmans]

@Patrice Champet ,

While every company wants to preach that Silos are bad and we need to be one unit to support, in reality almost every company still has a tiered support structure.

Regarding your questions:

Project Structure:

A single project still has my vote. Since you have a multi tiered support structure, tickets most likely go up and down through the levels. Having multiple projects would imply that you would have to clone or move the work items between the projects. 

Having a single project here makes a lot more sense imho.

The only reason I would set up multiple projects would be if the supporting group is completly diferent. Meaning HR/Facilities/IT/CS/... If they (almost) never cross paths on the same tickets. I'd keep it in their own project.

Workflow Design:How do you design our workflows to reflect the different support levels and escalation steps? Do you have any recommended statuses, transitions, or custom fields to clearly indicate the current support level and escalation state while keeping the ability to track SLA ?

I like to keep my workflow(s) as simple as possible. I'd design it as if it were always a single group/team that handles it. The only thing that often is a bit more tricky is re-assignment to a different group or team.

Personally I like working with a "Waiting for Support" status and a custom field that holds the Team that the ticket is assigned to. (at least until we have more granular control over the build in Teams on a project). Using that you can always assign a ticket to another team (and clear the assignee) you can change the status to Waiting for Support to signal that the currently assigned Team needs to take action.

This also means that the SLA for the customer/end user is not interrupted but you can still use multi cycle SLA's between the re-assignments to "Waiting for Support"

Roles & Permissions: Do you you have any specific configuration for roles and permissions to ensure each support level has the right access and responsibilities?

Everybody gets the "Servicedesk Team" role who need to handle the tickets. Besides their level of expertise they basically have the same job. I would advice to assign perhaps a specific Incident Manager or "Process" Manager who has a little bit more power to re-open/push items back and forth if needed.

And like @Tim Braxton mentions, if you want to deep dive and spar a bit, contacting a solution partner might be a good next step. You can always find one near you at https://partnerdirectory.atlassian.com/