Seven Steps to Improved Incident HandlingScripts may be old-school, but they work, writes ITSM Watch columnist Hank Marquis of itSM Solutions.
The IT Infrastructure Library (ITIL) describes how incident matching can improve the efficiency, effectiveness, and economy of service restoration.
If you don't use scripts, it becomes hit-or-miss, and the result is often mis-classifying an incident and sending it to the wrong tech group (maybe it goes to network instead of software development). This just makes IT's work harder and causes pain for customers since the first thing the tech usually does is to call the customer and ask whatever questions they need to get the data. Plus, the incident takes longer to resolve.
While the ITIL does not provide a prescription for matching, practical experience and pragmatic thinking leads to a very effective method for matching: diagnostic scripts.
So, using scripts gets all the data up front, lets you route to the right group, and lets the right group fix the problem without bothering the customer. If the customer is happy, everybody is happy. That is incident matching in a nut shell.
The first reaction most inexperienced IT people have to scripts is negative. They think scripts suppress creativity. IT managers often think staff and customers will not like scripts. But customers do like effective scripts: We prefer airline pilots use a script before take off, for example. We like Doctors to follow a rigorous script to make sure they have not overlooked anything, right?
The same can be true for IT. Scripts simply make sure we collect the right data, in the right order, so as not overlook anything important.
Remember that scripts are true expert systems. They are useful anywhere variables combine in repeatable ways. Scripts let a non-expert make an expert decision. After developing several scripts, you can even allow users to diagnose their own issues if they want.
Whether paper-based or software-driven, scripts dramatically improve incident classification, diagnosis, and matching while greatly improving the accuracy of incident assignments and escalations. A script is really an expert system, which can be defined as a set of rules or a decision tree which aids an individual to make good decisions in an area where that individual is not an expert.
It is easy to think an expert system requires software, and it is true that automating scripts with a software solution will improve functionality and allow a thorough examination of a knowledge base of past incidents, problems, and known errors, perhaps even changes.
However, if you do not have a software system, you can implement and benefit from a paper system. Perhaps the most effective script I have ever seen was a manual system.
In either case, a script is just a tool for consistently gathering information, classifying, categorizing, and escalating or forwarding. As every incident using the same script gets the same handling, similar incidents get the same open code. With a consistent open code, a manager can track the scripts utility by comparing open and close codes.
If the resolution (closed code) is not what the script indicated (open code) then the script needs attention. Otherwise, the script worked to resolve or route the incident is minimal time.
This focus results in very effective and efficient handling or routing of incidents. Getting the incident resolved or routed to the right functional area quickly improves customer satisfaction while reducing IT workload.
Whether you use a paper or software driven system, you must create, tune, and tweak your scripts. It is easy to do with word processing and drawing tools. A good starting place is technical staff, and if you have it, the problem management process (ITIL assigns knowledge base/script creation to problem management).
The seven steps to scripts:
Start a script team. Start with whoever performs technical repairs, and include anyone with experience diagnosing incidents or problems. Be sure to include service desk staff, customers, and users as well.
It is vital to include users and customers because they often use different terms than IT and including them helps create a system they accept and support.