Workflow help: global triage team, but then localised support teams

[Steven Lees-Smith]

Hi there,

Just exploring some workflows for our JSM instance and this came up.  We have support teams in Sydney and Vancouver.

The support supervisors want to have a global triage queue / project where all the tickets that come in land.  The triage team can just take the tickets as they appear and if they can action them they will otherwise they will escalate them to the relevant support team.

How would we set this up in Jira when there is a Sydney Support Team and a Vancouver Support Team. 

The triage team would send a ticket to the support team for the site that the user is reporting to and it would be unassigned OR if they know who specifically can handle the ticket it will be assigned to that person directly.

Has anyone worked like this, is it a viable triage to support approach or do you have a completely different recommendation.

Thank you.

[Patrick Haley]

Commenting to watch for future answers in case there's a better way to handle it. I also have support teams in the US, New Zealand, and Australia. We just set up different JSM projects for each region. Projects share permissions schemas and workflows, so they're nearly identical. Each support supervisor triages the issues to the relevant agents in their region.

Occasionally a customer creates an issue for the wrong region, but we just edit it and move it to the right project as needed. The main problem with managing it this way is that Components and Versions are different. Other than that it works well for what we use it for. 

[Nic Brough -Adaptavist-]

You can just click "watch", next to comment!  

But your model is a good one, and one I've seen work well in a lot of places. 

The main point is to look at where the issues need to land, rather than a location.  In your case, you have geographical teams, so the best thing to do is geographical portals.

If you need to delegate by some other parameter (server issue, human equipment or building services for example), then it's better to have different portals for those.

A global support team where things are being triaged out because the customers can't be expected to know which team it will land with are probably better off with a single project, and a field on the issue behind the request that the triage team sets to tell which team it should go to.

[Steven Lees-Smith]

@Nic Brough -Adaptavist-   Are you saying we have our customer portal which the global triage team get the tickets, but then what is the structure for the support teams.  

So we have;

One global triage team which then if they do not resolve a ticket pass it to;

One Sydney Support team  OR

One Vancouver Support team

If the support teams cannot solve the issue they then escalate to

One Sydney Sys-eng team OR

One Vancouver Sys-eng team.

Would love to see a document on how this is all structured or best practices.

[Nic Brough -Adaptavist-]

Yes, your need is that the customers (those raising the requests) do not know what team (by location) it will be handled by, so your global triage team decide for them.  They will add more data to the issue that enables the relevant team to pick them out, OR maybe create a linked issue in the target team's project.

So, if you have one portal (rather than two - one for Vancouver and one for Sydney), then your triage agents could stick the name of the current team on the issue, and then you could set up reporting for the teams based on "issue's team field = X"

However, non-Agents can't do much with the issues behind the requests in JSM projects, so it is probably better for the Agent to "create linked issue" in the appropriate project (I'd have one for Vancouver and one for Sydney, and a Support or SysEng flag on the issues, so the two teams can identify their issues and not have to mess around moving issues between other projects)

[Steven Lees-Smith]

Thanks for that, I like the idea of the triage team assigning a team to an incident and then we have queues setup for all the relevant teams for their unassigned,  assigned in progress etc etc.