Incident Notifications

[Phases]

I have a quick question on Incident notification.

We currently have a process for notifying and updating our internal IT customers whenever a signifigant incident has occured.

The incident is fed to our service Desk and we send an email out to the customers and internal staff

[Cekir]

Could you please elaborate on WHY do you want to sent such information and WHO is its recipient?
_________________
Krzysztof (Chris) Baczkiewicz
IT Standards Support
Eracent

[UKVIKING]

While Cekir's question is valid

mine are

how many of these go out to the customers on a daily/weekly monthly basis

are the recipients the ones who should get the incident 'canned email' aka 'spam'

Are they receiving one for each incident that happens or alarm notice that happens

or

are they receiving one when there is a major issue.


continueing in another post
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[UKVIKING]

Notification of your customers is a triple edged sword

If you send too many, your customers/users think that you have a crap environment

If you send too few, your customers/users will moan about not keeping them informed

You need to find the happy medium as well as the appropriate type of notice

You provide/ask your customers for what level of involvement that they want.
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[Phases]

[Phases]

[Phases]

[UKVIKING]

First, consider your internal and external customers differently

If you have minor issues, web site it at the IThelp Desk web site with periodic updates

This will be good until the intranet is the issue going down.

Then it will be hard to email/ produces notices

then you need also a phone message system

unless using VoIP

What ever SD tool you are may have a external web site making portion to do reports

then each customer external can configure what they want

we did this with vantive 6 - 7 years ago
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[itilimp]

I think I posted on this previously, so briefly I agree with John that getting the balance right is important. Why not ask your customers what they want?

E.g.
For a major incident:
Start of: Publish to intranet, verbally inform the affected service owner, e-mail affected service users.
Updates: Publish to intranet, verbally inform the affected service owner
Closure: Publish to intranet, verbally inform the affected service owner, e-mail affected service users.

For a minor incident: Publish to intranet at all stages during lifecycle

Where the intranet/e-mail systems are down, use a calling tree to inform those that are affected by the downed service.

Also, I wouldn't use a form style for the e-mail. Keep it short and simple as a few sentences which people are more likely to read. State the problem, confirm that you are working on it and the time of the next update if the severity of the incident warrants it (avoid stating anticipated fix time as you may end up setting expectations to high then fail them).

In terms of automation, you could automate the publication to intranet, but I wouldn't advise automation of the notification e-mail personally. Keep it human from the service desk.

Hope that helps.

[StevenLynn]

We only communicate Major incident and we catagorise them 123,bronze,silver gold red amber blue whatever you decide on.

We send SMS to a registered group of individuals who have an interestin the effected services. Update are at timely periods with a customer facing sms and a technical sms, we also do email.

Maybe worth asking your customer base internal/external what they want to receive and then meet them in the middle.

set up distribution lists per service and then communicate template sms/email

Steve

[Globis]

This is an interesting evolution of a question. It started out as: what should my notification look like? It went through 'why notify?' and ended up as "where to post notifications and for what".

However, a number of interesting points and issues arose during the discussions:

1) if the notification is ugly (i.e. hard to read/understand/not relevant) etc.) people do not read it.

2) if the notification is annoying (too frequent, unsolicited, mis-directed) people will not read it.

3) if the notification is either of the above it may negatively affect the perception of the quality of the service.

So the obvious conclusion is that notifications should be easy to understand, attractively presented, properly directed and of an appropriate frequency. Easy!

Of course whilst the conclusion above is possibly accurate, it is as useful as a chocolate teapot.

So here's my 5p's worth:

All of these questions are related to the service. The Service Manager in consultation with the customer should decide these things. Each SLA should detail who is to be notified in the event on a service outage, how that notification occurs, etc. This will be different for different services. As lots of people said, ask the customer!

IMHO under-notification is better overall than over-notification. As Margaret Thatcher's husband once said: 'It's better to keep your mouth shut and have people think you are a fool, than to open it and remove any lingering doubt.'

Avoid automated notification systems for all but a very limited number of people. You do not want your incident management process becoming part of the problem, i.e. your system detects the network is slow, so it sends an email to 2000 employees saying the network is slow. Oh dear.

The network is swamped with email and gets even slower. Users smack their foreheads in wonder at the utter idiots in IT. I've seen this happen (both the emails and the smacked foreheads).

If a problem is major you do not need to tell people about it, they will already know. If a problem is minor, why tell anyone more than you need to?

If you have a reasonably IT-aware organisation create a status board of known issues and put it on your intranet. Publicise it: make sure your service desk tell people about it as part of each and every incident intake. Make sure it is up to date!

Done properly users will become used to checking the status board before calling the service desk, and it will reduce the calls to your service desk. Moreover it will reduce costs. You will be viewed by all as an ITIL genius.

Track number of incidents calls to the SD versus number of hits on the status board per service to measure this strategem's effectiveness.

Cheers,

Dave

[jpgilles]

very interesting and good points in this thread...

I am adding my 2c contribution:
By experience, most users are not interested with too much details on incidents. Their only issue is basically "does it work? Can I do MY work?"
The best (in my mind) I have seen in terms of user communcations were websites with very basic information, like:
* the list of the various services provided by IT (from the service catalogue) - one by row
* the list of the various customers /user community (one by column)
* for each intersection (1 "cell"= 1 service for 1 customer) a colored indicator with Green=OK (within SLA), Orange = degradated service , red: KO (unavailable) -very elaborated isn't it?
when orange or red , clicking on the cell allows to either get more information or get a link to find information ... What pieces of information are availble at this stage relates to everything said before on this topic.

Of course you need to plan for accomodation in case the page is not accessible....
_________________
JP Gilles

[Cekir]