The (non)sense about the Incident Tasks functionality
Our goal is to take away frustration in people’s working lives. That is what the platform we use is intended for. Unfortunately, we are spotting a trend regarding the use of the Incident Tasks functionality that has the complete opposite effect. Using this functionality to route tasks is expensive, inefficient, highly administrative, typically adds to incident resolution times – making end-users unhappy – and dilutes from the true intent of the functionality.
Based on our successful Vanilla Approach, we are helping organizations to move away from a heavily customized version of ServiceNow to an out-of-the-box version. In doing so, we encounter the issue of how to utilize the Incident Tasks functionality. In heavily customized instances, incident tasks are often used by first-line service desks to route work to other departments. This is usually common practice in organizations that have outsourced their IT operations. Although you can work this way, we strongly advise you not to. Here’s why.
Quickly jump to:
Assigning work vs responsibility
According to ITIL, the goal of incident management is to ensure a service is restored ASAP. As most incidents have a single cause and will be solved by a single group, it is essential to ensure that the right department or group is assigned to quickly resolve the incident. Service desks are usually endowed with the task to assign the correct group. They should use the Assignment Group and Assigned To fields in ServiceNow, instead of using the Incident Tasks functionality. In the latter case, it will be unclear who is responsible, nor does it convey the same level of urgency. For anyone with a long list of multiple tasks, we all know that additional tasks will end up at the bottom of the pile. And you won’t feel responsible for it. However, this is different when you have been assigned a high-priority incident record where your group is solely responsible for resolving the issue.
Tracking work vs. Service Level Agreements
Some argue that, for service desks to control the incident resolution process, it is important to keep the incident assigned to their group. But we believe that service desks will then use the wrong data or table. You don’t want to trace work. You want to measure something much more important: Service Level Agreements (SLA’s). Based on the time needed to solve an incident, service desks define whether they need to chase a group to speed up resolution. What service desks need is insight into which incidents are at risk of not meeting target SLAs. And they need to know who to chase. If you have the task and SLA in the same view, it will boost the efficiency and effectiveness of the service desk. And it eliminates the need for complex reporting of multiple incidents and incident tasks.
More vs. less work
Others argue that the use of the Incident Tasks functionality is necessary to get multiple groups involved. If most of the incidents have a single cause, creating multiple incident tasks will only multiply the amount of work and increase the likelihood that more than one group unnecessarily investigates an incident. Plus, information about the resolution will be stored in separate tasks instead of one single source of truth: the incident. This makes proper end-user communication more cumbersome, and easy to forget. Furthermore, a very human reaction could be to wait until others have figured out what the cause of the incident was. This all leads to:
- Higher administrative load for the service desk
- Longer resolution times
- More time spend on coordinating tickets
- More time spend by groups on researching incidents that are not in their control to resolve
Furthermore, splitting an incident into different tasks complicates communication between different resolver groups. In a single incident record, all relevant information and history is directly shared with the assigned group.
Status quo vs. continuous improvement
The most frequently used KPI for Incident Management is reducing the resolution time, as it increases end-user satisfaction. This is typically done by:
- Limiting re-assignment count (ticket ping-pong)
- Lowering average incident handling time of a group*
- Ensuring tickets are automatically assigned to the right Assignment Group
For years, ServiceNow has had a very powerful reporting functionality to measure, report and influence the factors that contribute to faster resolution times. In recent releases, ServiceNow has added Machine Learning capabilities that correlate incident descriptions to the most likely Assignment Group for automatic ticket assignment. And here’s the catch: this is all based on the Assignment Group field. So, if you use the Incident Tasks functionality to divide tasks, you forego all the benefits these features can bring you. That means you are fostering a status quo, instead of driving continuous improvement.
True intent: Major Incident Management
If the above makes sense, how can you be in favor of a way of working that equates to more work and retains a status quo? In case you are advised to use the Incident Tasks functionality to route tasks, think twice. Only when a revenue model is applicable based on volume of work (tickets, tasks or hours) might this improper use of the Incident Tasks functionality be justified.
* ServiceNow provides a fantastic feature for this: Metric Timeline.
Join 1400+ ServiceNow professionals
Sign up to our monthly Flow@Work Exclusive newsletter to get free access to our expertise and lots of tips and tricks to make work flow on the Now® Platform.
