OTRS SLA per queue

[Snowmanko]

Hi there,
I would like to ask if there is anybody able to find solution for me and help me to realize how to configure custom SLA per queue.
I need to setup our OTRS 2.4.7 :: ITSM 1.3.2 like this :

Code: Select all

MAINQUEUE (here the ticket will be initialy created)
	- SUBQ1
	- SUBQ2
	- SUBQ3

So we have serveral queues with some sub-queues. We need to setup sla/reminder for Agents/Oweners so that when ticket will come to MAINQUEUE, its opened by our customer care dept. and SLA should start, lets say SLA will be 18 hours. When nobody will reply for this ticket in 18 hours, all agents/owners will get notified that nobody answered to custommer. When some agent/owner will reply to custommer or do it's job on ticket he will then move ticket to another SUBQ, like SUBQ1 so another department should do it's job on ticket.
And here is the problem, we need to setup SLA that way that when the ticket is moved to next SUBQx SLA for that ticket in that paticular queue should be reseted and should start counting new SLA (next 18 hours). So every department have 18 hours to do it's job, otherwise they will get notified that they are late.
TLDR : Every ticket in every queue should have new 18 hours SLA when its moved to paticular queue/subqueue.

Thanks for any suggestions.

Regards

[crythias]

Every ticket in every queue should have new 18 hours SLA when its moved to paticular queue/subqueue.

So, theoretically, you could bounce this ticket forever between queues and never reach the SLA? No.

[Snowmanko]

Exactly!You could bounce this ticket forever between queues and never reach the SLA. It's like every queue is managed by separate department/team and every department/team have certain time (SLA) to reply to their tickets. But sometimes workflow require another team to add some work to solve ticket.

[crythias]

This is awful. A ticket has an SLA to solve, period. It takes its information from the Queue and the Queue's settings, including the Queue's calendar, or from the ticket-service-SLA (if no service-SLA, queue wins. If service-SLA, service-SLA wins). From a customer perspective, you don't have an SLA. you just have milestones. And even then, the milestones must and always will be calculated from the datetime of ticket creation.

If Tier Two gets an additional 18 hours to first escalation on the ticket, then the ticket has 36 hours of escalation total. If Tier Three gets an additional 18 hours of escalation, the ticket gets 54 hours total. But from a customer perspective, you're not actually helping. Incidentally, the SLA of the ticket probably should be consistent, no matter who handles it, and one would *think* that escalation would actually reduce time to resolve, not make it take longer.

There are certainly items that are out of your control, including vendor purchases, etc., but a customer needs to have some reasonable service level expectations met that you've already agreed upon. Otherwise, don't bother with the SLA feature.

[Snowmanko]

I don't insist on fact, it should be done by SLA. I need some notification maybe. Some funcionality that will remind people that ticket is in their queue for more than x hours.

[crythias]

You might use Generic agent to change a value of something (a state, etc.) and notification event react to that.

every 10 minutes, check the ticket for:
this queue
last change time before 18 hours ago
state open

set:
state: 18+ hours

notifications, yes...

[Snowmanko]

last change time before 18 hours ago

Right! I will try to configure it, but should i use Escalation - Update Time in GenericAgent as timer for 18 hours ?

[crythias]

should i use Escalation - Update Time in GenericAgent as timer for 18 hours

I don't really understand how that will be helpful in this case. Update time reflects contact with customer.

[Snowmanko]

You said this should be configured as GenericAgent.

every 10 minutes, check the ticket for:
this queue
last change time before 18 hours ago
state open

I mean, how to track/setup in GenericAgent "last change time before 18 hours ago".. ?
How to track change of ticket state with time as an argument, thats what we are talking about.

[crythias]

How to track change of ticket state with time as an argument, thats what we are talking about.

I am looking at last change of any type to the ticket.

change time.png

[Snowmanko]

I see only this options :


So maybe problem is that my version do not support change times, is that true ? Or it's possible to turn it on somewhere in SysConfig.

[crythias]

Possible. I'll have to look at 4. that's an interesting omission. also please update your signature (see mine).

[Linwood]

I had four up and was working on something similar. Here are the options I see at the top for select ticket:

Select.jpg

Left me even more confused as to the difference in "Last changed" and "changed". I did not knowingly do anything to turn these on. I am on 4.0.6.

[Snowmanko]

Possible. I'll have to look at 4. that's an interesting omission. also please update your signature (see mine).

Updated, OTRS 2.4.7 :: ITSM 1.3.2, MySQL backend.

[crythias]

Oh. yeah. also too old to practically support here.

[Snowmanko]

/cry, can't upgrade to 4 now so it's not possible with my version and result is that I am not able to do it..

[crythias]

2.4->3.0.latest->3.1.latest->3.2.latest->3.3.latest->4.0.latest would be close enough for now.