SLAs -> Do not reset due date on status change

[arogers@schoolp]

Hi

I change the status of an Open ticket to On Hold but i want to leave the Due Date as it was. However, after the status is changed the due date has been set to the default for a new ticket (8 hours). This occurs even when i have set a new due date when i change the status to On Hold.

How can i stop that?

Thanks
Andrew

PS: I have turned off 'Reset Due Time On Status Change' in the status set up.

[markh]

I had this exact question when I first started using eSupport and I had to lodge a ticket to find out. The description of "Reset Due Time On Status Change" is a little misleading for me.

In short, you can't.

In length, when you change the status of a ticket it will automatically have a due date set to the due time of the SLA for that status. If there is no SLA defined for that status, it gets the default SLA of 24 real hours, 8 business hours.

We have to change the status, then find the ticket again in the new status and change the due date.

[arogers@schoolp]

Thanks Mark. I would consider this to be a bug. How about you?

A scenario i have come upon. I have a ticket that has a due date in 3 weeks from now. I am waiting on a reply and want to get it out of my Open list. When i change the status to On Hold i lose the Due Date.

Or, i have a ticket that is already well over due. I am waiting on a reply, change the status to On Hold and the due date now says i have another day to sort it out.

[craigbrass]

I think an option to clear due time or not should be prompted. Its half way between a bug and a feature request in my opinion.

[markh]

I saw it as a bug, in my mind the selection of a user should over-ride a default. However, it does seem to work as they intended and they stated at the time in a ticket that they'd put it on their TODO list.

Maybe we should actually create a suggestion in the feature suggestion forum?

Edit: Silly me, I looked and it is and been placed in teh 'Will Impliment'. Yay

Originally Posted by arogers@schoolp

Thanks Mark. I would consider this to be a bug. How about you?

A scenario i have come upon. I have a ticket that has a due date in 3 weeks from now. I am waiting on a reply and want to get it out of my Open list. When i change the status to On Hold i lose the Due Date.

Or, i have a ticket that is already well over due. I am waiting on a reply, change the status to On Hold and the due date now says i have another day to sort it out.

[Jamie Edwards]

Does this even happen for you when you turn this setting off (when editing a status within the administrator control panel)?

Reset Due Time On Status Change
If enabled, the due time for the ticket will be reset when changed to or from this status.

http://jamie.kayako.org/screenshots/20070817-225630.png

[Siora]

Jamie, I have this setting set to "no" and still when that status change is made it resets the due time.

I posted this yesterday as well:
Due Time is resetting

[Doug I.]

I have reported this as a bug to Kayako support. My staff started complaining about this due date changing after a status change was made immediately after upgrading to 3.11.01.

The setting in the admin control panel is useless as the due date gets changed no matter what anyway.


Doug

[danielpugh]

from my understanding, the reason it changes is because on status change essentially it is linked to a new sla. In theory it should have (new sla due date minus existing time), but that could lead to problems...

e.g. new ticket created (default basic sla - 4hrs)->
after 2hrs bumped to critical by user as its very urgent (critical sla 1hr)->
therefore if not reset it is immediately overdue triggering escalation action!

In my opinion current implementation is a little flawed. sla/escalation/notification needs a revamp for version 4.

sla timetable is a brilliant idea.
but ... sla is when things have to be done by. if it goes over sla its already too late, and if you have penalties linked to slas you lose money.

sla should just provide a framework for hours worked combined with the plan which determines priorities/queues/statuses it applies to.
most sla's are set on part of a tickets lifetime e.g. we will assign an engineer within 1 hr, we will respond withing 1 hr. Once the relevant sla is met the ticket itself may be live for weeks e.g. awaiting parts. (in a different queue)

Therefore there should be 1 field per ticket for sla due date (not affected by changes of status or multiple client replies) and one field for general due date.
A queue/status is then created for work that does not require sla due date e.g. deferred work/awaiting parts/etc.



so escalation rules should be separate and completely configurable, although the sla foundation for the action path.

ie

escalation 1 = 1 hr before sla1 expires -> send email to technician (if technician is not signed in/away then reassign to level 1 manager)
escalation 2 = 30 mins before sla1 -> email level 1 manager & change status
escalation 3 = 15 minutes before sla1 due to expire change assignment to
manager, email both level 1 manager and level 2 manager
escalation 4 = if notes/replies have been added to ticket (ie it meets sla) then change the queue to non-urgent

This would make the whole process a lot easier to understand/program/configure.

Additionally the existing sla/escalation is almost like this anyway.

This has probably already been discussed, but i thought i'd post anyway.

[Siora]

Yes that is for you. But what happens if both status' (current one and the one you change it to) don't belong to an SLA? Why does it still reset?

[danielpugh]

sorry, i was just theorising as i believe currently its been configured that way "by design", and suggesting that the way things are currently means that the system is inherently always going to fail one group or another.

I agree with the proposed change, and am just suggesting that a minor rethink/restructure/simplification is required for v.4.

Inherently if an sla is broken before any escalation takes place you have already failed the client.

Being told you have broken an sla is useful for reports, but no use in preventing the problem.

IMHO

[Matthew]

Originally Posted by Doug I.

I have reported this as a bug to Kayako support. My staff started complaining about this due date changing after a status change was made immediately after upgrading to 3.11.01.

The setting in the admin control panel is useless as the due date gets changed no matter what anyway.
Doug

This issue (of the Reset Due Time setting not functioning) seems to have been fixed in v3.11.01 CVS, I believe as of 25th October. See my posts here for an explanation of how Due Times, SLA's and Statuses work together. Corrections/clarifications will be appreciated.

[Jamie Edwards]

This request has been implemented and will be available in Version 4.