Incident Management - define a 'sleeping ticket'

[diGit_S]

Hello guys!

First post here, hope anyone can help me out.

I'm looking for a standard (en thus emperic ) definition of a 'sleeping incident'.
How long should an open incident be inactive before you can call it 'sleeping'?

I need this for some reporting job.

Thx for any input!

Steven

[mnsmith]

Hi Steven - welcome to the forum

Can you define what you mean by a 'sleeping incident'? I've never come across the term before and I'm very sure it's not a standard ITIL term.

If my suspicions are correct and you mean an open incicdent that hasn't been update in a while, then I would really worry that you are trying to define these. If the incident is still open, it means that the user still hasn't has service restored - and if it's been open a while then it's likely you are failing to meet any SLAs (if you have them defined).

My suggestion is to forget about sleeping incidents and concentrate on increasing the % of incident that meet the SLA or if you have not SLAs get some defined.

Hope that helps

Mick
_________________
Mick Smith
Change, Configuration and Release Manager

[diGit_S]

Thx for the welcome.

Yeah, well... it's definitely not a standard ITIL term, it's rather something someone ranked up higher than me invented i guess...

Also, I'm new to ITIL, but eager to learn

SLA's are defined and are to be met off course.
Now we would like to check if there is a possibility that tickets are simply lost out of sight.

I'm very aware that this should not happen at all, but there is no automation in our ticketing application (yet) to avoid this (automated alert stage messages or so) and after all, we are all human aren't we

But I know the term seems very strange.
Nevertheless, I just need different views on this. What would you guys define as 'sleeping'?

[Diarmid]

Steven,

you seem to be saying that someone has asked you to report on sleeping incidents, and you don't know what is meant by that phrase, but you are happier to have us help you form some definition that will allow you to report stats on such incidents. Unless the requester, by some coincidence, has exactly the same concept in mind as you derive here, your report will, at best, be misinterpreted.

Would it not be better to have the term clarified by the person who is using it?

Let me offer some suggestions of a definition;

1. Latent incident.
2. Incident not yet resolved, but not currently costing the business (because, for example, the affected users are able to continue with equally valuable other tasks)
3. An incident that had such low impact that when it was not easily resolved, it got forgotten about
4. An incident with a delayed impact (for example a server has crashed, but it is out of service hours)

I'm not sure what value there would be in counting occurrences in any of these categories. but that is the key: for what purpose is this counting required; what aspect of service delivery will it measure?
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

[rpmason]

[Diarmid]

Ruth,

are you applying data from H2g2 to R. V. W.?

What would Douglas Adams and Washington Irving have made of that?
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

[Diarmid]

[diGit_S]