Use of Awaiting States forTickets

[toddbaskett]

Hi All,

First time poster on this community and some of you may find the following questions boring for this community, but I'll ask them anyway because I know I'll get great discussions and insightful responses from everyone.

As we mature our ITSM processes, we are in need of more clarity for use of some of our default states, which we applied back when we adopted ServiceNow Calgary some years ago. As we have expanded and evolved the platform, and our maturity with service management, we find that more detailed process, and subsequent use of the “Awaiting States” needs to be clarified. This is needed to ensure ticket don’t get lost in the shuffle due to being “paused” for lengthy durations or just outright abandoned. My questions are as follows:

1. Awaiting States: Rather it be an incident or request (catalog task), in general, what does everybody find is the acceptable time to have a ticket remain in an awaiting state and leave it there (3 days, 3 weeks, 3 months..?) Now I know SLAs should come into play in the equation, but if a ticket is awaiting "something", isn't the SLA paused anyway? We are trying to further delineate our awaiting states, and how long they should be permitted to stay in such a state, due to things like client/evidence or vendor/equipment response times.
2. Awaiting Problem: This state presents a unique set of challenges for us that I really hope to get comments on.
3. If an incident is pending a problem record closure, does the incident stay in pending problem state until the associated problem record is closed? If the goal of incident management is to resolve the customer’s impact as quickly as possible, are there reasons for keeping two records open for the issue (incident and problem)?
4. Say we only created problem records for issues where a workarounds exist and is communicated to the Service Desk. Would you mark the related incident resolved (by way of the workaround), or maintain an Awaiting Problem state status until the problem record is closed. With a workaround in place, would the Awaiting Problem state pause the SLA clock or should it keep counting?
5. As an industry standard, would it be expected that the incidents related to its problem would in fact be a child of the problem record (if possible) to further automate any problem resolution process and fully resolve any child incidents with a single canned resolution coming from the problem record to all child incidents. We currently employ this relationship between our Major Incident and child incidents, and can then resolve them, but wasn’t sure if closing a problem record can/should close out child incidents.

Thanks for your thoughts,

Todd

[Goran WitchDoc]

Hi Todd,

I'll try to answer your questions 😃

1. When I was a customer we used awaiting user for showing that we were waiting for the user to come back with some kind of information. Only when you where awaiting the user the SLA was paused. If we were "onHold" for some other reason, the SLA towards the customer still ticked. When it comes to how long I think I remember we had something like this. After 1 week after being in "awaiting user" a reminder mail were sent out. then if nothing happen in another week (2 weeks in total) we closed the incident.

2. Guess this is just a title 😃

3. I would say that the incident is kept open until a workaround has been found. Then the incident can be close and the problem continue to work for the root cause. But the incident should be kept open until a workaround is found. This is a good tool for problem management to understand how big impact the problem has. should I work on the problem with 100 open incidents without a workaround or the problem with 300 closed incidents that has a work around...

4. See nr3. I would mark incidents are resolved if a propor workaround has been used. Awaiting problem is only when there isn't any workaround to be used. So as long as it's awaiting problem, the SLA ticks since the user is still having the incident open and can't work.

5. There is a relationship between incident and problem. and in that case the problem is the "parent" since a incident can only be connected to 1 problem (OOB). There is OOB functionality to e.g. communicate out a workaround when it's been found to all it's incidents etc.

That was my 10 cents 🙂

 //Göran