auremar - Fotolia
When an IT system crashes, end users are often the first to know, and then alert operations staff. While that might sound odd, ops team members do not actively use all of the products that end users do day-to-day, which makes user reports of performance issues the first sign of larger or local problems.
This process presents multiple challenges, as the users who report issues expect an almost instant fix from IT help desk staff. This expectation can create a nightmare for admins who have seconds to determine the source of the issue and how to address it. If they delay these steps, problems, and help desk tickets, escalate quickly, which drags in management -- and that is never ideal.
Make the first minutes count
The first few minutes of incident response are critical to prevent help desk escalation. With that first ticket or phone call, an IT team can shine or fail.
One of the most common tools to use in these situations is a call script. The problem could be that coffee spilled on a laptop, and the troubleshooter on the other end of the phone will follow a script, and ask the user if they turned the machine off and back on again. While it can frustrate users to walk through a list of steps they've tried already, scripts ensure IT teams don't miss any details or spend time on issues they could otherwise solve quickly. The key to strike a balance between scripted responses and interactive dialog is to listen to the user. While it's important to move quickly, don't jump to a fix without first listening carefully to what the user says.
Fine-tune incident management
IT teams can't pause or adjust time -- but they can change how they use runbooks to streamline incident resolution.
Start with the intake, which sets the path forward for the issue. Listen fully to user problems as they come in. It's important to remember that not all customers are the same, from what they do to what they know. As the problems come in, staff should be able to search runbooks for certain keywords or phrases that can help them determine the path to take -- for example, should they start with a scripted response, or bump the issue up to a higher level right away?
If the end user mentions they completed several of the steps normally outlined in the entry script, don't repeat those actions. The same logic applies when the user is an executive who doesn't need to perform the same steps as other employees. Identify key statements such as, "I have tried x, y and z" -- rather than claims that something doesn't work -- to know if a different path is needed.
Internal resources for incident management
To prevent help desk escalation, maintain a library of past issues, so IT staff can quickly research common problems and make proper routing calls. In addition to this internal documentation, offer a self-service wiki page for customers. While both of these options can facilitate incident resolution, they are only valuable when management regularly refreshes and updates them.
To enable self-service issue resolution, and to ensure ops staff have what they need to resolve problems quickly, documentation of both the issue, and its remedy, are critical. This process differs from creating a ticket and using it as a template. Help desk tickets are documents to solve a single issue. Ops staff need time to create an issue resolution document, which both enables customer self-service and reduces the need for help desk escalation. These documents shouldn't take hours to build -- there's the original ticket for reference -- but it still takes time to make them useful. And too often, the ops team is already on another call once it finishes the first one.
This loop traps IT operations teams. The better documentation teams have, the more efficiently they can resolve issues and provide self-service. However, documentation takes additional time, which creates opportunity for help desk escalation. The only way to break this cycle is to give ops staff time to create problem resolution documents. This change will most likely increase help desk escalations initially, but they should taper off as the library grows. It will be difficult, but enterprises will see the benefits, such as faster issue resolution, more self-service and a shift from ops teams firefighting to a calmer state wherein they can continue to enhance the runbooks and wikis. That first step is painful, but current runbooks are simply not a scalable model and face devastation when an enterprise loses one or two employees.