Here are some notes from the interview with John on the 5 major pitfalls of major incidents.
Tagging the incident with the right category ensures that it is assigned to the right team to be resolved if it needs to be escalated by the service desk and can help with prioritisation of incidents.
70% of initial incident categorisation is incorrect, which can mean that the incident is assigned to a team wrongly and bounces between teams.
Make sure your service desk knows how to categorise incidents through training or with an effective configuration management system.
Correct categorisation of incidents can also aid analysis by problem management teams to enable root cause analysis. The best practise for reviewing incident categorisation is to verify it once the incident is closed (record closure).
The most common issue with incident categories is having too many or too few. Too few categories can lead to not enough information being recorded, and too many categories can lead to confusion and mislabelling of incidents. The example John gives of too many categories is a client of his with over 400 categories. When auditing he found that 92% of incidents were in the ‘other’ category as the service desk team had found the list overwhelming. As well as having categories, it is important to consider that they should be multi-level and based on incident impact which escalates with severity and verified on record closure.
Most organisations don’t realise how much incidents cost them.
There are 4 major costs of incidents –
When an incident is received by the service desk that they cannot rectify themselves it gets passed up to second or third line support or a third party support provider. Shift Left is defined as moving things back downstream to the service desk or even to self-service.
There are often three main reasons the service desk cannot rectify the issue:
By giving more power to the Service Desk and putting more information on resolved incident tickets can mean that less incidents need to be escalated and as the service desk is often cheaper to run, and have more capacity, than second or third line support this can provide a cost-effective solution.
According to leading frameworks such as ITIL, incident priority is based on impact and urgency but impact is hard to measure. Most systems use number of users affected to assess impact, but a better way to measure it could be based on the actual application or criticality of that application. If it has few users but is central to the business it is potentially more urgent than an application with hundreds of users that isn’t central to business function. Another factor to consider is the potential reputational damage to the company in the event a small incident recognised by customers as reputation is arguably the most damaging impact of an incident. The last one John talks about is regulatory impact (such as in finance) where reports not submitted accurately or on time could have financial repercussions.
Quite often, service desks are providing the service they believe business or customers need without validation via a service level agreement (SLA). Outsourced IT services will almost always have an SLA, but internal services don’t often have a SLA so users reporting an incident might believe that the service desk is only working on their incident, where in reality a service desk might actually be working on 200-300 open incidents. They may also believe the incident will be fixed within half an hour. SLA often include to a priority system and as a general rule high priority incidents are often resolved within 4hrs with the lowest priority incidents being up to 5 working days. Users reporting incidents will probably then call back within about an hour as no set time-frames have been published so there is no management of expectations. John has found that up to 70% of calls to service desk are ‘chase-calls’ to check on the status of an incident.
We were thrilled to have John join us for this interview and are very grateful to him for sharing his experience with us.
To get in touch with Neil email email@example.com
To get in touch with John email firstname.lastname@example.org
Find us on Anchor to subscribe on your favourite podcasting platform!
Klaxon is an intuitive, simple platform to provide fast and powerful communications when you're faced with major incidents. Schedule your personalised demo today and try it free for 30 days.More Posts