Incident Manager Weekly Checklist

I recently contacted a customer – an Incident Manager – whom I'd spent some time helping with his Incident Management procedures. He told me that things were going fine, but that some staff were not calling customers back within the 1 hour target of logging Incidents set down in the SLA (or not recording they had done so), and so he'd needed to sent a couple of emails.

I was strangely pleased to hear this, as it meant he was acting as an Incident Manager should – using the weekly checklist we'd drawn up to monitor that procedures are followed and following up where they aren't.

In an earlier post my colleague George asked "So What do Incident Managers do all day?".

An Incident Manager must ensure that the Incident Management process is documented, so that service delivery staff know what it is. They must also take charge of making sure that staff are aware of these procedures for example, through training, workshops, role plays, meetings, and so forth.

But all of this effort is pointless if no-one is actually following the procedures, so as Incident Manager you need to be checking that they are.

Following a weekly Incident Manager's checklist is a simple way of ensuring that such checks are systematic and regular. In addition, checklists provide important evidence that your Incident Management processes are working. In other words, they can be a Key Performance Indicator (KPI), with which you can supplement management reports to back up your recommendations for changes. (See "Some Service Level Management (SLM) Key Performance Indicators (KPI)").

So what sort of things would you include in an Incident Manager's Weekly Checklist? To be fair, you obviously must base your checklist on the documented Incident Management procedures you are providing to your staff (for example, your Operations Manual). After all, how can you expect people to follow a procedure you've never written down?

Clearly, procedures will vary from one company to another, but the following checks are typical from my experience, and will get you started with your own list. (Tip: For the benefit of yourself and other readers, I'd recommend you format your own list as a checklist, with tick boxes and spaces for your comments):

1. Take a sample of Incidents logged by different agents during the last week. Check the quality of the Incident details logged:

  • Have all the details listed on your call logging script been captured?
  • Has the correct priority been assigned?
  • Has the correct Configuration Item (CI) been recorded?
  • Is the description of good quality? (You need to break this down further by looking at whether standard questions were asked – version number? error message? - if appropriate description templates were used, if multiple Incidents are being described in one Incident, etc.)
  • Was the Incident correctly assigned?

2. Take a sample of Incidents logged within the last week and assigned to different agents. Check that your procedures have been followed with regard to responding promptly to Incidents logged:

  • Did the assigned agent respond to the customer within the target response time set out in your SLA?
  • Did they make the response in the correct manner (for example, if you have specified that agents should try phoning the customer before sending emails, have they done this?)

3. Take a sample of Incidents resolved by different agents within the last week.

  • Is there evidence that the agent has contacted the customer to notify them of the resolution?
  • Was a good quality resolution description provided, explaining clearly how the issue was solved (not 'done' or 'I fixed it').
  • Has the correct Cause code been attributed to the Incident?

4. Look at all Incidents during the last week where the resolution target was missed. In each case, try to determine the reason and note this against the Incident.

And so forth. Your own checklist might continue with checks on whether correct escalation procedure had been followed, a review of how any Major Incidents or Complaints were handled, etc.

Tags: 

Categories: