Measure Inactivity time considering a Schedule how it is meant to be

[Daniel Oderbolz]

Dear ITSM Specialists

A customer of ours has a requirement that sounds easy, but so far, I did not find a good solution using built-in functionality. 

They want to measure the time an incident is inactive, but considering a schedule (for example to exlude week-ends or bank holidays).

My first instinct would be to use metrics, but they are (for whatever reason) not schedule aware - not even with San Diego. I am aware of the exellent post Schedule Aware Metrics - Includes a full solution- shoutout to @Callum Ridley for the excellent work! That would be my preferred solution (but I would love to see it officially in the platform).

Another idea would be to use an SLA to do this, but how do I get it to start once inactivity start and stop once it ends?
It is not clear to me how to achieve this in a simple and understandable manner.

Last but not least I thought I could leverage an Inactivity Monitor. Here, I was surprised to learn that they do not use a metric, but rather that they create scheduled tasks and leave the time information encoded in the Scheduled task (seems a rather brittle implementation in my opinion).

After all, I thought that many other people would also like to measure inactivity and exclude non-business hours.

Did anybdy find a good (canonical) solution?

Thanks a lot & Best
Daniel

[Tom Sienkiewicz]

Hi Daniel,

I would first double check what we understand by Incident being inactive. The way this is implemented in the Inactivity Monitor is simply the time between any two updates of the incident record. I do not believe that summing up all of those "periods of inactivity" would give a meaningful value, since 99% of the time would actually be "inactive" 🙂 

Perhaps a slightly better approach to look at this would be to take the total time it took to solve an incident (e.g. from SLA - which follows a specific schedule), minus the time logged as working on the incident. The resulting difference would, in theory, be the "time inactive". Of course this is not precise due to the time worked logging, which will never perfectly reflect real work done. Also, this is not an "operational" perspective, it will not allow you to react in advance.

Coming back to the requirement, what is the goal here? Is it to just see for how long the Incident was left "untouched"? < - if yes, then perhaps a Business Rule or a Metrics script can do the job - as you have rightly mentioned in your post. But having a "total" inactivity time calculated is a more complex scenario I think. 

[Daniel Oderbolz]

Dear @Tomasz 

The intention is not to sum these times up, but to have a stop watch that resets every time the record is updated (by a non system user) - but only if we are in the schedule.

So let's say an incident was last updated on Friday 16:00. The Schedule includes Mo-Fri 8:00-18:00.

This means that the metric I am after has the value 1h by Monday Morning 7:00.

If the incident is updated then, the value is set to 0h and by 8:00 the clock starts ticking again.

This way, we can show for example all incidents that have not been updated (in the Service Time) since e.g. 20 hours (= 2 work days)

Thanks a lot for your help!

Best
Daniel