Incident management is one of the most crucial aspects of ITIL.

When a service is disrupted or fails to deliver the promised performance during normal service hours, it is essential to restore the service to normal operation as quickly as possible.

Thankfully, there is a clear, optimized process to handle service disruptions that enable IT teams to communicate effectively and resolve almost any incident without unnecessary delays.

In this Process Street checklist, we have adapted the standard process flow to fit our super-powered checklists format.

What this means is you can complete and review the entire process in real-time, approve tasks as needs be, store and link to important data such as incident tickets, and focus only on what needs to be done in your specific situation thanks to our conditional logic feature which will customize the checklist depending on the severity of the incident.

Its the simplest, most effective way to resolve incidents and maintain data integrity.

Let's get started.

A little info about Process Street

Process Street is superpowered checklists. By using our software to document your processes, you are instantly creating an actionable workflow in which tasks can be assigned to team members, automated, and monitored in real-time to ensure they are being executed as intended, each and every time.

The point is to minimize human error, increase accountability, and provide employees with all of the tools and information necessary to complete their tasks as effectively as possible.

Once they've approved the document, it's then time to do what you do best: Supply great services to paying customers!

Incident identification:

Enter basic details of the incident

Incident logging:

Log the incident as a ticket

Ensure the incident has been logged as an "Incident Record" within your ITIL system.

This way the incident's status can be tracked, and a complete historical record maintained. 

The ticket should include information such as the user's name and contact information, incident description, and the date and time of the incident report

If possible, incidents should be matched to other Incidents, Problems, and Known Errors to keep data well organized.  

Approval: Incident has been properly logged

Will be submitted for approval:
  • Log the incident as a ticket
    Will be submitted

Categorization & prioritization:

Categorize the incident according to your system

Categorizing and prioritizing the incident is critical to determining how the incident will be handled. 

Categorization allows the service desk to efficiently sort incidents based on their categories and subcategories, and can also trigger automatic prioritization. This is particularly important if it is a major incident that requires an urgent response.

Note-down the category of the incident below as well as in your ITIL system. 

Prioritize the incident

Next, prioritize the incident. 

This is determined by two key factors:

  1. Incident urgency
  2. Impact on users

In short, urgency is how quickly a resolution is required, and impact is the extent of the potential damage the incident may cause as long as it stays unresolved. 

Enter the levels of priority in the form fields below.

Depending on your system, you can either determine a single level of priority by weighing up both factors or you can use the priority matrix (displayed below). 

Approval: Incident has been categorized properly

Will be submitted for approval:
  • Prioritize the incident
    Will be submitted
  • Categorize the incident according to your system
    Will be submitted

Initial diagnosis:

Run through standard troubleshooting questions

Now its time to make an initial diagnosis of the incident and hopefully resolve the issue without having to seek support escalation and delay the resolution of the incident. 

The first thing to do is run through standard troubleshooting questions to see if there is a simple, known solution that can be applied. 

Perform thorough investigation

So it's been identified that this is not a simple, previously experienced incident. 

Therefore, a thorough investigation needs to be conducted to understand what's going on.

Once you have completed the investigation, it will be clear whether or not support escalation is required to resolve the incident.  

Use the text field below to enter notes from the investigation

Develop initial hypothesis for the issue

What is causing this incident?

What needs to be done in order to resolve the incident as soon as possible?

Write down the initial hypothesis below.

Determine if the issue needs to be escalated

Now, determine whether or not the incident needs to be escalated to the next tier of support staff. The required support may be functional, hierarchical, or both. 

Most incidents should be resolved by the first tier of support staff and should not make it to the escalation step. 

Support escalation:

Escalate the issue (functional)

Contact the relevant personnel to receive support as soon as possible. 

A typical example of functional support is sending an on-site technician or seeking assistance from certified support staff. 

Escalate the issue (hierarchical)

Contact the relevant personnel needed to receive hierarchical support. 

A typical example of defined escalation levels in terms of hierarchy is:

  • 1st level support
  • Incident manager
  • Manager of data processing center
  • CIO

Approval: Incident has been escalated as necessary

Will be submitted for approval:
  • Escalate the issue (functional)
    Will be submitted
  • Escalate the issue (hierarchical)
    Will be submitted

Investigation (final diagnosis):

Test the initial hypothesis

Test the initial hypothesis to confirm whether or not it is correct. 

Initial hypothesis: {{form.Initial_hypothesis_following_investigation}}

Determine final diagnosis

Determine the final diagnosis so that staff can apply a solution whether it be changing software settings, applying a software patch, ordering new hardware, or whatever else may be required to fix the issue.

Resolution & recovery:

Resolve the incident

At this stage, the incident should be resolved and the service desk confirms that the user's service has been restored to the required SLA level. 

Approval: Incident has been resolved

Will be submitted for approval:
  • Resolve the incident
    Will be submitted

Incident closure:

Confirm classification details are accurate

Before closing the ticket, its important to make sure that the initial classification details are accurate for future reference and reporting. 

Maintaining data integrity must not be overlooked once the incident has been resolved. Details still need to be checked to make sure the closed ticket is completely accurate. 

Close the ticket

Link to incident ticket: {{form.Link_to_incident_ticket}}

Good work! Now that the incident has been resolved and data integrity has been verified, you can go ahead and close the ticket. 


Sign up for a FREE account and
search thousands of checklists in our library.

Sign up for a FREE account and search thousands of checklists in our library.