SLA Management

[Aggeliki K]

Hello,

I have set up an SLA for a specific issue type. In order for the time to be activated, I have to pre-define a target, for example 24h, so that the SLA is set for this issue.

The problem is that not all my issues should have the same target. What I want is the assignee to be able to define the time needed for the issue to be resolved.

How can I implement this?

Thank you in advance,

Aggeliki

[Gökçe Gürsel {Appfire} · Accepted solution]

Hi @Aggeliki K ,

You can do this with Time to SLA.

Time to SLA has the dynamic duration feature which allows users to enter the SLA goal in a custom field of their choosing. The input (should be a time string) will be excepted as the SLA Goal which is exactly what your use case calls for.

You can also use Automation to set this field based on different conditions.

Please let me know if you have further questions.

Regards,

Gökçe

Please note that I'm one of the members of the Snapbytes team.

[Aggeliki K]

Hello @Gökçe Gürsel {Appfire} ,

I will test this plugin and will come back with questions , if needed.

Thank you,

Aggeliki K

[Gökçe Gürsel {Appfire}]

Perfect! I'd be happy to assist you if you have further questions.

Cheers,

Gökçe

[Dirk Ronsmans]

Hi @Aggeliki K ,

i'm afraid you can't do that that easy. An SLA is a pre-defined contract for a specific set of requirements on an issue type.

Now you can easily pre-define multiple targets based on a JQL. So if you have a specific business rule for an issue you can set this as a pre-defined target. 

An example is that you have a Time to Resolution SLA where based on the priority and issue type you have different goals:

• issue type = Incident and Priority = High  Then goal = 4h
• issue type = Incident and Priority = Medim then goal = 8h
• ... and so on..

So the only way you can have an SLA that is "chosen" by your agent is to define the goals with predefined JQL's and have the Agent change the fields on the issue to match that goal.

This could be as easy as making a dropdown selection with 20 (or more) values and linking those values to SLA goals. This way the Agent woud choose the target time by correctly classifying the issue.

Personally this seems like a very strange way to define and manage your SLA's but that would work. 

[Aggeliki K]

Hello @Dirk Ronsmans

Thank you for your reply,

What you propose could be a workaround in some cases but I am afraid not in our case, as we have many criteria (that are not pre-measured) which we should take into account as far as time needed is concerned.

Thus we cannot predefine our issues' resolution time with JQL. 

Thank you anyway,

Aggeliki K

[Dirk Ronsmans]

Allright, then you are indeed going to need to invest in a plugin like @Gökçe Gürsel {Appfire}  suggests.

I do find it strange tho (but that's just besides the question), if your agents can look at the issue and define what the time goal is this should be quantifiable in the goal as well. It might be complex and/or many goals but should still be measurable based on some values entered.

pre-measured is not really needed, a SLA can be applied once it is actually valid to apply. (so it doesn't need to be calculated at the moment of creation)

I somehow feel your idea of SLA is not completely correct. When you mention "the time needed" then that would be the estimated time to resolve the issue which you can then compare towards the time spent on an issue.

An SLA should be a contract which is defined with your customer/business where you tell them what the time is they can expect to have an resolution in. If it takes longer, then it takes longer and you need to either adjust your SLA contract or find out why it took longer this time. Having an SLA which is decided on by your agent at the time they review the issue seems very very strange to me.

But hopefully Time to SLA is able to fulfill your requirement!

[Aggeliki K]

Hello @Dirk Ronsmans ,

What I have been asked to implement is a way to measure the time needed for an issue to be resolved, but excluding the time where we are waiting for the customer to comment.

I initially tried to use a time tracking procedure, but there were no pause options in it and SLA seemed the only way for me to start and pause the clock when needed.

What we do as a company when we receive an issue, is that specific (not all of them) agents review it and decide what time they will have to spend for this issue and then inform our (internal) customers. In any case, the time definition is made after the issue has been created.

If you have other options to suggest apart from the SLA, you are so welcome to do so.

Regards,

Aggeliki