“Do you get asked for this?” Let’s talk about it. Part I
It all starts out with an email. What? Yes, I know an email. Still the preferred choice for a lot of "unregistered" work to be done. But that is a topic for a different discussion, and blog.
This blog is about that email and how to handle these types of requests. In this blog I'll lay the ground for the upcoming Performance Analytics office hours July 15th 2020 where I will be talking and walking the audience through a good practice and solution for the following request:
 |
From: Chris Sent: Wednesday, May 6, 2020 4:16 PM To: Lisa |
|
Subject: Incident tracking Hi Lisa, Would it be possible to add a “date assignment group changed’ field to incidents? Use case: it’s helpful to be able to tell when a team was assigned an incident, because that’s when the clock starts for them on triaging and resolving the issue. Right now, I just get “created at”, but that really doesn’t tell me much given teams reassign so much stuff over to my teams late during the life cycle of the incidents. Cheers, Chris |
As Lisa, who manages the analysts and is responsible for any changes to the ServiceNow platform related to improvements for reporting and analysis purposes, this type of request is not uncommon. Often business leaders can’t get the information they (think they(!)) need and reach out to her to get this information flowing.
Before Lisa does anything, she will first analyze the request so far to better understand the ask, and maybe more importantly to better understand the result Chris wants to achieve. It is critical to not just do what gets asked before understanding the context and the objective because else you might end up wasting resources and quite possibly not delivering the best solution to meet Chris his objective. Howewer, before Lisa replies to Chris with a response she gets a second email that lines out a solution that Chris came up with.
 |
From: Chris Sent: Wednesday, May 7, 2020 9:16 AM To: Lisa |
|
In an ideal world I’d be able to query / view the assignment history of a record in a clean way: 4/1/2020: Created, Assigned to “Service Desk” 4/1/2020: Re-assigned to “Network” 4/2/2020: Re-assigned to “Hardware” 4/3/2020: Re-assigned to “Software” Etc. And the common query for “current state of the world” would be e.g. “show me all incidents that have been assigned to this team for more than a day that have not been dispositioned (on hold, waiting for customer, etc...)” So the real trick is: how do I formulate that query? I could have a related list of “assignment events”, or of SLAs, or similar, but building queries against those is always a bit rough. Having just a field on the record is easier, but suffers from the “bunch of fields” problem and lacks the full context. Record history (sys_audit) already has all of this data, but is not reasonably queryable. A single field on the table doesn’t give me historical data like a related list would. So all kinds of competing stuff going on there, may want some kind of a blend. Chris |
Aha, now Lisa already understands better what Chris is after. He wants the answer to the question: how many incidents are there that have belonged to my team for more than a day AND are not in a good state. Time to pick up the phone, schedule a virtual conference call or if possible meet Chris in person and get to the bottom of what Chris would like to achieve with this metric.
Turns out that there is a company wide initiative for all teams to make sure that all P3 incidents are resolved within 3 days. The company believes that his is a good strategy to mature the handling of the not so critical incidents.
I'll not go into a discussion at this point as to whether or not the above is actually a good strategy or not, rather I'd take it from here and look as to a good and solid practice to offer an as much as possible out-of-the-box solution. If you would like to know about the solution to the request join me during the office hours session July 15th 2020 or watch the replay after the 15th!
You want a hint? Ok, ok. It involves metrics, and in specific SLA Metrics and SLA Metric Breakdowns as well as out-of-the-box dashboards, reports and indicators for the various persona's like those responsible for these metrics as well as for the people working on incidents that can influence the metrics. See you there!
