How to create different SLAs within the same ticket with different resolution groups?

[Andrei Akentjew]

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.

For example:

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?

Thanks!

[Ivan Tovbin]

Hi Andrei,

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.

[Juan José Marchal Gómez]

Hello,

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?

best regards.

[Jack Brickey]

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.

1. you will need two SLAs, e.g. Group1SLA and Group2SLA
2. you will need some field to trigger between Group1 and Group2. You could create a custom field or my preference generally is to create a new status, e.g. Escalate or Group2 or whatever.
3. Assuming you use the status approach:
   1. Group1SLA starts when the issue is created and stops when done OR when status set to Escalate
   2. Group2SAL starts when status set to Escalate and stops when Done

make adjustments to meet your specific needs.