Major Incident Process

[steck24_00]

How do you do a major incident in Service-Now? Would anyone be willing to share their thoughts and experiences?

[gflewis]

We have been managing Incidents in Service-now for about 2 years, but only using Problem Management for about 6 months, so our implementation has been somewhat evolutionary. We use Severity to flag our major incidents. (If Severity is not empty then it is a major incident.) We considered using a separate table, but decided it was too much process overhead. Time is of the essence when you are dealing with a major incident, so you want to keep your forms and process streamlined. We tried a checkbox field on the incident form to flag major incidents, but abandoned it when we realized that it was redundant with the Severity field. We use an ACL to lock down Severity so that only the Network Operations Center can create major incidents. (In practice many incidents start as normal and then get escalated to a major incident by the NOC.) UI policies based on the Severity cause certain fields such as Incident Manager to appear for major incidents. Other fields which are mandatory in all other cases become optional for a major incident.

Our Help Desk uses incident parent-child relationships to tie incoming calls back to the major incident. For example, if there is a major incident and they get 10 calls related to it, then there will be 11 Incident records: a master record that is used to manage the major incident and a child incident for each caller. When the master incident (parent) is resolved the children are resolved automatically.

Each morning our operations groups will review any major incidents from the prior day and open a Problem ticket if there is not one open already. The problem ticket is assigned the same Severity as the corresponding Incident. The major incident now has two numbers: an incident number and a problem number.

We hung a "Problem Task" table off the Problem table to track all the follow-up action items related to the major incident.

One nice thing about having two tickets (an incident ticket and a problem ticket) is that the close date on the Incident indicates the date/time that service was restored whereas the close date on the Problem indicates the date that all the follow-up action items were closed.

[JohnJasinski]

How does your large organization handle major incident notifications / communications? In SN or outside SN?
Do you use both notifications and on-call rotation inside SN?

[vicijh]

I've used a couple of approaches.   For my immediate stakeholders we added them to the watchlist so they were automatically notified of updates.

For the more senior stakeholders we used a templated email that would go out to an agreed distribution list.   A copy of the email would then be attached to the Parent Incident ticket as evidence of the comms

[Danny Mortense1]

You might want to take a look at the Incident Alert Management plugin (Incident Alert Management - ServiceNow Wiki). This is probably what you are after.

[eric_bull]

This is my recommendation for all customers with MI's:

New Call - used to triage all inbound phone calls and chat/connect sessions. From here the decision is made to create INC, REQ, status update, general inquiry, hang-up or wrong number.

INC - modify the form to allow "escalation" of an INC to an MI. Capture important details that distinguish the INC as a "Major Incident" and use those fields and others to pass data via UI Action and underlying Business Rules to MI. Once the escalated Incident is approved as an MI, the workflow creates an MI with a parent PROB.

MI - Build MI form on the 'TKT' table. Out of the box, this table is extended off of Task. This supports the architecture that MI is truly just a "Return to Service" INC under escalated SLA timeframes with 2nd and 3rd tier resources and laser focus from the business. A PRB record is created for every MI because Problem Management becomes the mechanism for tracking end-to-end all of the INC related to the MI for calculating overall business impact as well as the discovery of the Root Cause and long-term resolution via Change Management.

I would be glad to set up time to go through this workflow if anyone is interested.

Respectfully,

Eric Bull

Delivery lead