| Author |
Message |
![[Post New]](/Sysforums/templates/default/images/icon_minipost_new.gif) 13/04/2011 12:35:08
|
Jeremy Phillips
SysAider
Joined: 04/09/2010
Messages: 17
Location: Davis, California, USA
Offline
|
Howdy--
The short version of this is: Is there a way to reset a timer to 0 via an escalation rule?
The long version:
I have used a combination of statuses, timers, and escalation rules to create the following workflow:
1. When we need additional information from a customer, we set the status on the service request to "Awaiting Response." There is a "Waiting for Customer" timer that tracks how long a service request has been in that status.
2. We have an escalation rule that checks for service requests with "Waiting for Customer" timers at 168 hours (1 week), then notifies the customer that we are waiting for them to respond and sets the status to "No Response Pending Closure". We have another timer that tracks the time spent in the "No Response Pending Closure" status.
3. We have another escalation rule that checks for service requests with the "No Response Pending Closure" timer at 336 hours (2 weeks), then notifies customers that their request is being automatically closed and sets the status to "Verified Closed".
The problem I'm running into is when a customer actually does respond after steps 2 or 3: because the two timers keep incrementing, and because the two escalation rules are looking at the total time on each timer, the customers immediately receive the two automatic notifications again, and the ticket is immediately closed.
So, is there a way to reset the timers as part of the escalation rules?
Failing that, is there some other way to handle this?
I would consider using the "Reopen Count", but it's not uncommon for a ticket to have been reopened more than once for other reasons, so that's not a reliable indicator.
The other idea I had was two use one of the custom integer fields to manually keep track of the number of times the SR has gone through this loop, but I don't think that the query building is sufficiently flexible to do these kinds of comparisons.
Thanks for any suggestions.
Best,
Jeremy.
|
|
|
13/04/2011 15:15:02
|
Inna
SysAid Customer Relations
Joined: 24/06/2010
Messages: 745
Offline
|
Dear Jeremy Phillips .
What you should do is simply creat another status - "Client resonded" then go to preferences > integrtion > email tab and set this status as a reply this is it this will stop the counting becuse this status will be opan/active status. see screan shot attached
Thanks Inna
![[Thumb - Capture.JPG]](/Sysforums/upload/2011/4/13/ae91b0c92cd74aec6473cc37d0162203_9788.jpg__thumb)
|
| Filename |
Capture.JPG |
|
| Description |
|
| Filesize |
104 Kbytes
|
| Downloaded: |
6 time(s) |
|
|
|
13/04/2011 17:02:02
|
Jeremy Phillips
SysAider
Joined: 04/09/2010
Messages: 17
Location: Davis, California, USA
Offline
|
We actually have a "Customer Responded" workflow, and that's exactly what we're doing (sorry--should have mentioned that in the original post).
The issue is that after the customer responds, we frequently end up needing to go back to them for yet more information. As soon as we set the status back to "Waiting for Customer" again, the escalation rules fire because the timer on "Waiting for Customer" is already past the escalation threshold from the previous run through the workflow.
J.
This message was edited 1 time. Last update was at 13/04/2011 17:02:32
|
|
|
16/04/2011 07:31:48
|
Joseph Zargari
VP Customer Relations
Joined: 26/03/2006
Messages: 518
Offline
|
Hi Jeremy,
In general, timers are meant to count time for making statistics later, so resetting it would make the statistics unreliable. Therefore, it is impossible to reset them.
I reviewed your scenario and found it incredibly similar to what we're doing with our helpdesk (after all, we're all doing pretty much the same, aren't we?).
A small correction to your escalation rules would do the trick. Instead of running it based on the timer count, you can run it based on the last modify time of the service request (if the customer doesn't respond nobody will change the service request and change the timestamp of the last modification).
In case I'm not clear, let me paste your steps 2 and 3, but with the changes I'm proposing:
2. We have an escalation rule that checks for service requests 168 hours (1 week) since last modify time, then notifies the customer that we are waiting for them to respond and sets the status to "No Response Pending Closure". At this point the last modify time is restamped by the escalation rule to the time of the escalation.
3. We have another escalation rule that checks for service requests with status "No Response Pending Closure" 336 hours (2 weeks) since last modify time, then notifies customers that their request is being automatically closed and sets the status to "Verified Closed".
I propose that you keep just one timer for awaiting customer response that will count the time service request are in BOTH statuses, as they both represent a state of waiting for the customers' responses. That way you can later run report to show how much time service requests are being delayed because the customer didn't reply.
I hope that helps...
Joseph.
|
|
|
18/04/2011 10:44:10
|
Jeremy Phillips
SysAider
Joined: 04/09/2010
Messages: 17
Location: Davis, California, USA
Offline
|
Thanks, Joseph. I'll give it a try using the last modified date.
My only concern with that is that we do sometimes add activities, notes or other additional information to service requests while we're waiting on additional information from the customer. But really, that will only extend the time until the escalation rules are initiated. So I think it will still work for us most of the time. I may put in a feature request for a new variable that measures the time since the last customer contact, since that would be ideal for this use case.
Best,
Jeremy.
|
|
|
![[Up]](/Sysforums/templates/default/images/icon_up.gif){kind=icon}
![[WWW]](/Sysforums/templates/default/images/icon_www.gif){kind=icon}
