Rashid.Ahmed
-
Posts
21 -
Joined
-
Last visited
Rashid.Ahmed's Achievements
-
Hi @Mohamed, @Victor, For us at Milton Keynes Council there doesn't seem to be a correlation between request type, Service and Incident request types are affected Following the recent update, we are being impacted by : Tickets are not updating the Response SLA Status Tickets are not updating the Resolved SLA status - See examples below Regards Rashid
-
HR & Finance Service Manager - Hornbill adaptation
Rashid.Ahmed replied to Rashid.Ahmed's topic in Service Manager
Thank you @Gerry for your quick and comprehensive reply!! I've had Hornbill Customer Success get in touch with me by email today and I've have got them in contact with our IT Business Solutions Manager and our Desktop Manager to discuss the exact requirements Thank you again for being extremely helpful and pointing me the right direction Cheers again Rashid- 2 replies
-
- 1
-
-
- service manager
- logging call
- (and 2 more)
-
Good Afternoon, We currently use Hornbill Service Manager at Milton Keynes Council IT, to log, process and record all issues raised by council officers. We also have the Employee Portal, currently only available internally (only the council network as it requires Office 365 authentication) which is used by council officers to log these issues for investigation, monitor the progress of their tickets and also contains a FAQ area for useful IT information. **Officers can log in on a private connection, using a personal device, but only if they log in using their email and password not using SSO** A proposal has been put forward by the councils Finance and HR departments to bring in these to service areas into our existing IT instance of Hornbill Service manager, under our current subscription. To bring in both Finance and HR, the setup must meet the following conditions: Tickets must be kept separate and in their own queue from the existing IT tickets Must be accessible to technicians in HR and Finance across domains – HR and Finance officers are spread across a mixture of Milton-keynes.gov.uk domains as well as Northampton and Cambridge domains It needs to be accessible to those mixed domain officers using SSO Is this possible? What additional components are required to make this work? What are the issues with this setup? Regards Rashid
-
Hi @David Hall Has there been any further developments regarding this issue? Is this potentially a bug? Should we roll back the resolution timer change? Do let me know Regards Rashid
-
@Victor My apologies Victor, I'll be more mindful of what i post on the forum in the future Your linked post is really helpful to outline what shouldn't be posted on the forum - i've passed the info onto my colleagues too :)
- 19 replies
-
- 1
-
-
- servicemanager
- timer
- (and 4 more)
-
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.
-
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 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
-
Hi @David Hall We are controlling the pause/resume resolution timers function via the Service Manager Settings: 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
-
Hi @David Hall Thank you David, really appreciate it! Kindest Regards Rashid
-
Hi @David Hall Just wondering if this has been found to be a bug or if a fix can be proposed? Regards Rashid
-
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" }
-
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 The ticket is pretty simple in terms of the tasks and the timeline - see below
-
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? Application Support - resolved calls by analyst - with SLAs_629.xlsx
-
Resolution Timers - requires changes to BPM and settings?
Rashid.Ahmed replied to Rashid.Ahmed's topic in Service Manager
Thanks for investigating this David! Regards Rashid -
Resolution Timers - requires changes to BPM and settings?
Rashid.Ahmed replied to Rashid.Ahmed's topic in Service Manager
Hi James, We gave this a go last night and unfortunately it still keep the resolution timer ticking even after the call is closed Below is an image showing the settings we enabled (basically matching the image you provided earlier) , what the status of the resolution timer looked like at each stage of the call and finally the report (after the call was closed) confirming the fact that Hornbill still doesn't the resolution has been met. Any advice on how we can get past this issue would be really appreciated Regards Rashid
