By Hank Marquis
UPDATED JAN. 3, 2007: ADDED LINKS INCIDENT PRIORITY CODING
UPDATED DEC. 11, 2006: ADDED LINKS INCIDENT CLASSIFICATION

Service Desk staff performing Incident Control provides the initial support, investigation and diagnosis to resolve incidents.  The IT Infrastructure Library (ITIL^®) says that key to Service Desk effectiveness is efficient Incident matching.

Unfortunately, the ITIL does not say exactly how one should implement matching!  Luckily, hidden deep with the ITIL, there are some clues, and they lead to a very effective method for matching: the diagnostic script (or script).

A script is an expert system using structured questions to collect data.  Scripts let non-experts make expert decisions. 

Using scripts dramatically improves Incident classification, diagnosis, and matching while greatly improving the accuracy of Incident assignments and escalations. 

Scripts provide optimal guidance to resolve Incidents in the least time possible with the most accuracy.  Following I explain what they are, how to create them, and how to use them.

Scripting 101

A diagnostic script is a powerful tool that provides the staff performing Incident Management activities step-by-step directions for gathering information, classifying and categorizing (a.k.a. matching), and escalating or forwarding.  Technically, a diagnostic script is an "expert system".  Following is a nice definition of an expert system:

Typically 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 confuse "expert system" for "software" and to think that without a sophisticated software product you cannot use scripts.  Don't be fooled however!  You can benefit from scripts without any software at all.  One of the most effective diagnostic scripting systems I have ever used was paper-based -- each staff member had a workbook with questions and jumps to sections with workarounds and resolutions based on the answers to the questions asked and data gathered.  Of course, automating this process can improve its usefulness, but even if you don't currently have a software solution in place you can still produce and benefit from diagnostic scripts.

The steps in the script help staff collect the right information in the right order.  Then, based on the information gathered, the script directs them to ask more questions, gather additional data or take an action.  Consistent collection of data is crucial for successful Incident Matching.  Scripts offer much more than matching however -- scripts can dramatically improve the operation and performance of the Service Desk, Incident Management and Problem Management.  

As every Incident handled by a script receives the same handling, the Process Manager can create useful reports about the accuracy of the script.  It is critical with scripting to use a standard coding scheme when opening and closing the Incident.  This is important since the coding of the Incident (e.g., how to handle the Incident) is a direct result of the script.  Thus, when the Incident closes, if it turns out that the resolution was something other than what the script predicted, the process manager can identify the errant performance and address any issues by modifying the script.  Over time such scripts become very effective.  As the scripts effectiveness improves, so does the efficiency and accuracy of resolving Incidents.

Benefits of Scripts

Scripts let managers simplify, standardize, and optimize the ability to rapidly diagnose and resolve Incidents.  One of the main benefits outside of improving the operation of the Service Desk is a marked improvement in operations and Customer satisfaction.  The benefits of using well managed scripts are many and include:

• Quickly coordinating restoration of IT Service

• Facilitating resolution by non-expert staff

• Minimizing duplicated work to gather information

• Improves Customer satisfaction

• Gathering only the information required

• Promotes organization learning

• Increases IT Service availability

• Helps reduce staff turnover

• Reduces Incident resolution times

• Provides for self-help systems

• Supports new services quickly with low costs

• Enforces best practices

• Reduces training requirements

• Produces valuable management information

• Increases efficiency and effectiveness of Problem Management

Those unfamiliar with scripts often think it will be difficult to impose on staff or that Customers won't like answering scripted questions.  This does not have to be the case at all.  You can find an example of scripts that everyone likes in the airline industry.  Consider the pre-flight scripts pilots follow.  Passengers understand pilots follow rigorous scripts so they don't overlook something.  Passengers are important, so airlines use scripts.  If your Customers are important, you too should use scripts.

As both a Customer and User of airlines, I understand that they are taking their time and following the script for our mutual benefit.  When implemented correctly, IT staff, Business Customers and Users accept scripts because they know they are going to get the fastest resolution and highest quality IT service.

Getting Started with Scripts

The Incident Manager has the responsibility to develop, maintain and improve Service Desk scripts.  Many common Service Desk software tools and products support computerized scripts.  You can also create scripts yourself, using common office word processing or drawing tools.

Regardless of the method of presenting the script to Service Desk staff, the actual diagnostic scripts can come from several places, and a good starting place for the creation of scripts is the technical staff, perhaps organized by Problem Management. 

The ITIL gives the responsibility for maintaining a Knowledge Base of Known Errors to Problem Management.  This Knowledge Base enables organizational learning and speeds resolution of new Incidents if any similar Incident has occurred before.  A knowledge base organized by topics and keywords allow for fast matching of Incidents, and the more keywords matched, the more likely the match. The data collected using the script "fills in the blanks" for topic and keyword matching.

Following are five (5) steps leading to good diagnostic scripts:

1. Assemble a scripting team.  Since Problem Management maintains the Knowledge Base it makes sense to involve them in script creation -- Problem Management is the locus of technical repair and resolution activities.  Also consider including other technical specialists or anyone else who has expertise in diagnosing Incidents or Problems.  Include members from the Service Desk, Customers and Users as well.  This last step is vital as many times Users and Customers have different words or descriptions for the services they use.  Their insight is invaluable to create a script that Users and Customers accept and support.
    

2. Select candidates for scripting.  To get started with scripts, find a category of Incident that often slips past or escalates from the Service Desk and goes into Problem Management or a technical area.  If you don’t have formal Problem Management, look for those Incidents that come from technical groups after they work directly with a customer.  Look for the most common Incidents that Service Desk does not or cannot today handle.  Another starting point for scripts is the Knowledge Base maintained by Problem Management.  If you don't have a formal Knowledge Base, you probably have some form of manual system, or have someone who knows how to handle certain kinds of Incident or Problems.  Develop a list of candidates and focus on those that occur frequently and where the expertise to diagnose them resides outside of the Service Desk.
    

3. Document the script.  Have the technical group or subject matter expert prepare a set of questions and actions that would allow the Service Desk to diagnose the Incident, recognize a Problem or at least gather enough information to accurately route the Incident with data sufficient to speed its resolution.  Usually, subject matter experts are interviewed to determine the steps the expert would use to make a decision.  Sometimes if better to follow experts and takes notes as the experts go about making decisions.  Often this reveals that the expert was not aware of all the steps, questions or activities actually used.  This is technically called a "task analysis".  A task analysis relies on "task decomposition", or breaking tasks down into parts.  Once a task is decomposed, you can create see work flows and the decision process used to obtain a result. 
   
   The following eight (8) steps describe the process of decomposing a task to prepare a diagnostic script:
   
   1. Identify the task to decompose (from #2 above)
   
   2. Split the large task into 4 to 8 subtasks, each subtask should have a specific objective and action
   
   3. Make a flowchart drawing of the subtasks
   
   4. Decompose each subtask as required, creating more flowcharts
   
   5. Have the expert check the flowcharts, revise as required
   
   6. Augment the flowcharts with screen shots or copies from manuals, and so on
   
   7. Expand the flowchart with textual instructions, directions or explanations as required to make it readable
   
   8. Have Service Desk "try out" the script to make sure it operates as required
    

4. Market your scripts.  For highest compliance, market your "expert system" to Service Desk staff, other IT departments, Customers and Users.  Explain the benefits of the new system.  Leverage the idea that scripts provide stability and ensure important details are not overlooked.  Fully describe the new system, how it was made, its objectives and how it will be used.  If you selected a good candidate for initial scripting and involved the business in its creation this will set up a "quick win" with demonstrable positive effect on the business.
    

5. Start using the script.  Once the script is complete, tested and functional, start using it.  Monitor the results closely, making sure that staff follows the procedure contained in the script.  There may be some resistance to this at first, but once staff becomes familiar it should be seen as a very good tool.  Over time staff will internalize the script so you must be diligent to ensure its proper usage and that nothing gets skipped.  Also important is to monitor the open code (based on the script diagnosis) and the close code.  If the close code is not aligned with the open code then either the script is incorrect, or staff is not using the script correctly.  In either case, you must intervene and resolve the issue.

    

Entire Contents © 2006 itSM Solutions LLC.  All Rights Reserved.