With mass outage - when to stop logging individual incidents

[VooDu]

When an incident occurs that causes a mass outage, like the email goes down. SD starts logging incidents and could end up loggin hundreds of incident tickets. Should they stop at some point and create some type of incident ticket that covers the outage and not the individuals being disrupted?

I can see this from a couple of different perspectives and would like to hear some other opinions.

Thanks

[subh]

Hi VooDu,
This is subhash here. when we are confirmed that its not a single user issue. We should stop creating unneccesary ticket, and create a master ticket with Incident manager involvement.
Ex: if an exchange server is down.

This will save time and kep SLA in place as well.

Thanks.

[Diarmid]

There is a thread raised yesterday in the itsmfi forum on the exact same subject.

From a service management perspective, incidents are events not calls. To manage the incident you need the information that comes from calls, including who has been affected. There needs to be the capability to inform users when service is restored and there needs to be the capability to confirm that the restoration is universal and there needs to be the capability to ensure that the scale of the impact has not masked out separate incidents that perhaps had similar symptoms.

It may well be impractical to return every single call or to talk to every single user, and so you may have to rely on information cascading and on users still in trouble raising another call. But you cannot make a simple rule for this and therefore it is probably useful (or even very important) to record all calls that come in related to the incident.
_________________
"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

[SwissTony]

To back up what Dairmid has said I would recommend logging individual calls & referencing them to the master incident. These individual tickets could be closed directly as being covered by the master ticket, but gives you a record of how many users contacted you. However, this can take up the HD agents time, so the alternative would be:

If you have a phone system allowing for automatic messages to be played before the user gets through to an agent, explain the problem & that it is being addressed, & reference the master ticket number. Once resolved change the message to state that it is now resolved, & if users need to reboot or something you can make the explaination there.

If you are serving multiple sites, and one goes down, then you would know the number of users affected anyway.

[Diarmid]

Just as a little bit of fun, sometimes when something is fixed the users have to do something themselves to get back to normal. When that is the case, you want to consider the users who are away at the time but need to know when they return whether it is hours, days or weeks later.
_________________
"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