Jump to content

SLT/Within Response Time fields not re-evaluating


Michael Sharp

Recommended Posts

When a response is made on a request and the priority is changed, the SLT and Within Response Time is not overwritten.  I guess the field is not changed in the database?  This feels like a defect to me?  Scenario created as follows:

  1. Request raised with an 8 hour response time (P4 SLA)
  2. Request responded to within 8 hours
  3. Request priority adjusted to P1 SLA (10 minutes response time) - should now be marked as a failed SLA

image.png.425aef9c39a0f6227ebbba898b290dc9.png

@Bob Dickinson tested following our discussion earlier

Link to comment
Share on other sites

@Michael Sharp

52 minutes ago, Michael Sharp said:

Request responded to within 8 hours

Is that a "Mark/Stop Response Timer" BP node? I assume so since I don't see how otherwise...

Part of any "Stop Timer" node is to remove the respective timer from the system timers. One of the effects of this is that this timer can no no longer be user for any further calculation because it no longer exists. Therefore if a request timer is stopped, any subsequent SLA/SL change will not reevaluate the respective timer in any form. With your example above, if you marked (stopped) the response timer at 1 hour, it will be marked as "SLA met" based on the 8 hour target. The subsequent SL change with the 10 min target will not recalculate the previous mark, the request will remain as "SLA met".

However if, for example, you have a 10 min SLA and the user picks up the request 20 min past, the SLA info will show as "SLA or Target breached and still ongoing" (or something along these lines). If you then change the SL to an 8 hour target the SLA info will be adjusted and will not longer display as breached. But this only happens if the timers was not yet marked/stopped. Same logic applies, and following the 8 hour example above, if the SL is changed at 7 hours (so within 8 hour target) to a SL with 10 min target then the SLA info will now say "SLA or Target breached and still ongoing". Again, this only applies to a timer that has not yet been stopped.

Link to comment
Share on other sites

@Victor that's correct - I wanted to change that breached/met based on the adjustment of a priority.  Moreso so a report could be presented more accurately (whether negatively or positively).  I'd quite like a button there that only Helpdesk Managers can use to recalculate/adjust the breached/met as I do understand why it isn't a feature for engineers to avoid foul play.

Regards,

Mike.

Link to comment
Share on other sites

Hi @Michael Sharp

Sorry for the misinformation earlier - Victor is quite right, in that as soon as the "Mark request as responded" node has been reached in your process, it cannot be overriden. If you change the Priority (and therefore the SLA) however many times before that node, it should recalculate correctly - but as soon as that node has been reached in the BPM, that is the point at which the met/missed value is recorded and cannot be subsequently amended. Sorry if I suggested otherwise this morning 

Kind regards

Bob

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...