Different SLAs based on different reporting customers

[James K_]

We are looking to further develop our support offerings using Jira Service Management, and I've been having issues trying to set up SLAs with different timeframes.  The goal is to have two sets of SLAs, a standard, and then premium SLA that I would either enforce via organization or a support level flag.

I am not seeing ways to restrict request types to certain organizations, so I've setup a custom field called 'Support Tier'.  I have an automation that is trigger on ticket creation and runs based on the Organization of the submitting customer.   This automation will set the 'Support Tier' field to "Premium".  I currently have SLAs set up based on a 'SLA tier' that is determined via the request type (eg. 'SLA tier': "1" has a 1 hour response time).   I created a new SLA rule that looks at both the 'SLA tier' and 'Support Tier' (eg. 'SLA tier': "1" and 'Support Tier': "Premium" has a 30 minute response time).

I did some testing (with an internal test organization), and while my automation will trigger, (adding the "Support Tier") the SLA was still under the base 1 hour, instead of my premium 30 minute response time.

I suspect that the SLA is applied before my automation runs.  My direct goal would be some way setup my SLAs in a way that I can have SLAs based on groups of customers - either set via a field trigger via automation, or if there are ways to 'tag' certain organizations.  We've had issues with customers attempting to receive higher tier service using 'premium level' request types, so being able to restrict access to higher SLAs to the applicable organizations is the goal.

I'd like to not have to create a separate project for this purpose, as there are downstream reporting concerns that rely on both a standard and premium support offering being evaluated together. 

The questions I hope to resolve are:

1. Can I have SLAs based on fields that are set via automations that run when a user opens a ticket?

2. If not, is there a way to restrict request types to blocks of customers.

3. Is there a way to force a customer to share a ticket with their organization to enable automations based off of the reporting user's organization? (We have customers that are in the same company but operate in different organizational units, so automations based on a user's domain name aren't possible)

Thanks,
James

[Giovanni Melai · Accepted solution]

Hi @James K_ ,

In relation to your first question the SLAs are dynamic so it's not important if the field is updated by an automation, once the field change the SLA is recalculated. In your case the issue might be the order of the Goals, they are evaluated top down so the 30m goal should be added above, in your case something like this:

1. 30m - Support Tier = Premium
2. 1h - whatever JQL you use
3. 4h - All remaining issues

In relation to your third question, you cannot force a user to share the ticket with the organization, they can always decide not to do so. I see that you are on the Premium plan so you have access to Jira Assets, I would suggest you to create a sort of simple CRM in there with the list of customers and Companies and you will be able to create automations around them. 

I hope this helps 

[Jack Brickey · Accepted solution]

Hi @James K_ ,

This all comes down to when you start the SLA. I am assuming that you are starting upon issue creation, which is the problem since the automation runs after the creation.

Here is one way to accomplish this, however, I don't know if it's the best way, without really understanding your full workflow which I'll explain later.

Create a new status, let's call it Triaged. Now change the start for the SLA to be when an issue enters Triaged. Now let's assume that the original status is "waiting for customer". Have your automation that is currently setting the tier value to transition from waiting for customer to triaged and back to Waiting for customer. Perform these transitions after the tear value is set, and I would recommend using a refetch data action before the transitions as well.

As I stated, initially, it's hard for me to give you the best answer without fully understanding your workflow. In the above suggestion, it assumes that every single issue is going to get triaged with an appropriate value and that it will be used as part of the SLA goal.

Please let me know if this makes sense or not and if you have any further questions.

[James K_]

Jack,

Thank you so much, that sounds like a way to address my first point.  You are correct in that the SLAs are run when the Issue is created.

As far as the automation in setting it back and forth between a new status 'triaged' and 'waiting for support' (the default status it enters), does there need to be any action, or would moving it back and forth in the same automation satisfy the trigger for the SLA.

Thanks!

[Jack Brickey]

It should work as stated. My only concern would be the possibility of a race condition where the transition is missed. So to combat that you could have a second automation that is triggered on the transition to triaged to transition him back. With that said, certainly keep in mind the recent communication on limits of successful rules. For that reason, I would certainly try to make a single rule work first. Possibly some other components that would add delays between the two transitions.