In out company we have the first level support, who recieves all the tickets.
When they are not able to solve the issue or if its something that belongs to second level or the other support team they escalate the ticket to them.
My question is. How can I have different SLAs depending on the group that has the ticket.
I have ticket A with an SLA of 4 hours.
First level, after 3 hours reviewing noticed that this is an issue for second level and they give the ticket to them.
Second level, of course, have their own times to review tickets but if they get the ticket with 1 hour SLA remaining I have a problem because they didn't have the time needed to review (lets say 3 hours) and I'll get contaminated statistics.
Is there some way that the SLA changes when is being passed to another resolution area?
easy enough just takes a bit of setup. To get you started here are some basic steps. I think if you play with it you will figure it out.
make adjustments to meet your specific needs.
This is because when you passed the ticket to another team, the ticket remained within the same cycle of the same SLA metric.
I see two options to solve this:
1) Provided your issue enters a new status when you change support levels you can configure your current SLA metric to stop when an issue enters that status, and also create another SLA metric that would start when an issue enters that status. This way you'll have separate SLA metrics for different support levels. Configuring SLA metrics to start/stop on assignee change is not safe, because you can have multiple assignees within a single support level.
2) If your status does not change when you escalate your issue to the next level and it's just a matter of changing the assignee or another field value then you need to somehow start a new SLA cycle. To do that create a dummy status and configure your SLA metric to stop when an issue enters that status. Then create a transition to that status and attach a screen to it. Make sure that screen has all the fields that you need to change to escalate your issue. Then create a transition back from your dummy status to the original status. After that create an automation rule which will trigger when an issue enters your dummy status and will transition the issue back to the original status. Alternatively you can add a post-function to the dummy status transition which will transition the issue back, but that requires a 3rd party addon like JMWE.
So when you'll need to escalate your issue, click on the dummy transition, change your field values on the transition screen and then the issue will be transitioned right back to the original status which will start a new SLA cycle.
I'm trying to do this scenario and I find several problems.
1) This scenario works if you have more than 2 Groups? for example 3?
2) When I create the automation to "comeback" to previous status, the SLA "change the behaivor". For example, if you have "main status" called Working In progress, change to Dummy status Group1 and execute the trigger to come again to working in progress, the SLA start again to count.
Do you understand my situation?
Hello Community 👋, I'm a product manager at Atlassian, looking at improving change management capabilities across our products. In particular, we're looking at bridging the gap between Dev & ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events