Jump to content

Resolve time met but the request is still breached - Resolution timer


Recommended Posts

 Hi,

I've scanned the forum to see if anyone had already posted this issue, but could've missed it, so please do point me to it if this has already been raised.

One of our managers ran a report for the month of March and came upon a discrepancy whereby even though the request resolve by and the date resolved were met, the within resolve time criteria was still appearing as breached (see attached spreadsheet)

We applied the Pause Resolution Timer enhancement on the 2nd of March so these calls should adhere to this setting - we confirmed that the enhancement works after the latest update released on the same day

One thing we did notice for the tickets where this issue exists is that the resolution missed is way in the future, well after the call has been closed and timers ended

is this a known issue?

image.png.44effeb8977f17a09ee9c7da0b7bb229.png

 

Application Support - resolved calls by analyst - with SLAs_629.xlsx

Link to comment
Share on other sites

Hi @Rashid.Ahmed

It does look incorrect but its pretty hard to confirm from the screenshot, sometimes changing an SLA after a target has already been missed etc can result in this view for example. 

If there has not been an SLA change to cause this scenario, if you have the "Incident Management Full Access" role you should be able to click on the blue button under "Service Level" to open the SLA update popup.  To the bottom right of the popup there is a diagnostics button which will show a list of the primary SLA actions e.g. pause/resume etc.  It might be worth checking that to see if that shows when the pause and resume took place and when the resolution/fix target was marked to see if that highlights any reason for the above.

Kind Regards,

Dave

Link to comment
Share on other sites

Hi @David Hall

Sorry about the belated reply

So i've given your instructions a go and using the above ticket as an example i can see that the timer was paused once i resolved the issue, it was then marked as fixed when the ticket closed automatically on the 30th

The system then resumed the timer almost immediately, is that correct?

I can see that this was the case for the other tickets mentioned in the spreadsheet too- Pause once resolved, then Mark Fixed and resume almost immediatly

image.png.d24a623d9d2d1835feb70677bc98c5e0.png
The ticket is pretty simple in terms of the tasks and the timeline - see below

image.thumb.png.1d0a51c1a2e3214a61c0c490dc227827.png

Link to comment
Share on other sites

Hi @David Hall

Further to my update above

The escalate row has the following info attached to it:

 

{
  "detail": "Resolution Timer Escalated\r\n* The target resolution time has been changed from '''[2021-04-07T15:55:00.000Z]''' to '''[2021-03-29T15:55:00.000Z]'''",
  "flowcode": "smSLMEscalateResolutionTimer",
  "prevSysTimerElapsedWorkingTime": "PT0S",
  "prevSysTimerElapsedTime": "PT6S",
  "prevSysTimerslcName": "ServiceDeskDefaultCalendar",
  "prevSysTimerstartTime": "2021-03-22 17:52:40Z",
  "prevSysTimerstate": "1",
  "newSysTimerElapsedWorkingTime": "PT0S",
  "newSysTimerElapsedTime": "PT0S",
  "newSysTimerslcName": "ServiceDeskDefaultCalendar",
  "newSysTimerstartTime": "2021-03-22 17:52:46Z",
  "newSysTimerstate": "0"
}

And the Resume status set by the system states this:

{
  "detail": "The resolution target has been resumed",
  "fixTime": "2021-04-07 13:25:06Z",
  "previousFixTime": "2021-03-29T15:55:00.000Z",
  "systemTimerElapsedWorkingTime": "PT2H31M58S",
  "systemTimerElapsedTime": "PT181H39M18S"
}
Link to comment
Share on other sites

  • 2 weeks later...

Hi @David Hall

We are controlling the pause/resume resolution timers function via the Service Manager Settings:
image.png.85012969126204bf54782ef5cb0ee982.png
 

Continuing to use the ticket SR00034450 i've been using for screenshots in this post

In the BPM for this call, the 'classification stage' is the only place we have Timer Type nodes set; we don't have timer nodes set in the 'Fulfilment & Closure' stage
The timer nodes we have during this stage seem to only be nodes to start the timer
 

image.thumb.png.adc54a75d027b6706d767869afc7228f.png

 

 

Link to comment
Share on other sites

Hi @Rashid.Ahmed

I've still not been able to fully replicate locally but I have a suspicion it could be down to the fact the request was raised out of working hours and then escalated immediately before any time elapsed.  I'm just trying to recreate that scenario to see if I can confirm whether that is the reason for the resolution time being incorrectly reset.  Will let you know when I can confirm or not.

Kind Regards,

Dave.

Link to comment
Share on other sites

Hi @David Hall

Thank you for coming back to me

Your update above got us looking at all the calls that are breached like this again

1. We can definitely see calls raised via the self service portal, during working days/hours

2.  We could see that Hornbill was still registering that the resolution was met in some way, as when you hover over the breach you can see when the call was actually closed by the system and when all the SLAs should have been taken off pause and stopped ticking complely

image.png.d9520c61b3082a4c52827db283ecee99.png

3.  With just this ticket as an example (we have many since the resolution timer pause change was made) you can see that this call was due breach on the 29/03 at 4:55pm. It was actioned and set to resolve on the 23/03 11:01am

The call had around 6 days 19 hours left in the SLA - the real time taken to action the call minus off the 7 day SLA for this call.

It looks as if Hornbill is placing the call on pause until it is ready to auto-close, but then decides to carry on counting down from the date of closure

The date in the future is what the breach time would be if the call was re-opened on the 30th and left to tick over

image.thumb.png.06ae2ba3186e025ac847d2886d798305.png

Link to comment
Share on other sites

  • 2 weeks later...
Posted (edited)

Hi @David Hall

Apologies for the various chasers

Just to let you know, Some more examples from April of Service Manager incorrectly recording a call as breaching the resolve timer when it clearly hasn’t.

image.png

Edited by Victor
Personal data included in screenshot
Link to comment
Share on other sites

@Rashid.Ahmed this is a bit more difficult to troubleshoot just via a forum conversation. Although you don't usually have access to this type of support as an Essentials Customer, due to the investigation we need to perform I will raise an internal request with our support team to progress this further. You will receive a notification in this regards shortly.

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...