Shift Left: Transforming Incident Management

Shift left is an industry wave focused on moving many aspects of IT service and support towards the lowest cost option:

• Incident resolution to tier 1 analysts (service desk) or tier 0 (the end user)
• Fulfillment to automation or self-service
• Testing to automation, service desk, or end users

Benefits include lowered costs and can also lead to higher satisfaction as wait times for service and support are significantly reduced.

I will help you transform your consumers’ experience with incident management by integrating troubleshooting and knowledge into your service portal. With modern-day service portal technology, bringing true self-service to end-users is easier than ever before. In spite of this, many organizations will deliver context-sensitive knowledge to people logging an incident through the portal, but little else. The concept is rather simple: using a series of conditional questions/answers to drive customers to solutions, whether they use knowledge or not, while also providing a more descriptive incident to IT when they don’t find a solution.

More Service Channels vs. Self Service

One aspect of the shift-left movement is driving resolution from the tier 1 service desk to the tier 0 level, commonly known as self-service. While many organizations think this means giving end users a portal through which they can log their own tickets, that’s not really the outcome of most service portals, which commonly provide another channel through which an end user can request support. Self-service refers to the ability for customers to fix their own problem or fulfill their own needs without needing to engage a provider, not simply the ability to log a ticket.

Thus, while IT thinks that driving their consumers to a portal is offering them self-service, all they are achieving is providing an additional channel through which to obtain support. While this has its benefits, it is not the same thing as achieving the shift left. In the age of millennials, this is no longer enough. The table that follows demonstrates this.

Driving customers to a service portal is not the same thing as achieving the shift left.

Transforming Incident Management with Self-Service

The difference starts with understanding the end user’s journey from issue or question to resolution and scripting it into the service portal application in the form of conditional questions, instructions, video clips, and automated solutions. There are a few key needs to be able to do this:

• The instructions/knowledge for this need to be documented. Ideally, this is a step that translates knowledge from article format to an incident form, so the knowledge has to be known to do so.
• The knowledge needs to be broken down into steps, each one of which has a decision point to the next set of steps and a path through the incident form.
• Key stakeholders need the ability to work with customers to evaluate their response to the questions and work through all scenarios that could occur, addressing and incorporating each journey.
• Tools must have the ability to run videos and automated scripts. At the very least, video capability is desired. Automated scripts that kick off utilities a service desk analyst would use to fix simple issues merely increase the likelihood of resolution by the end user (increase true self-service odds).

With these in place, there are just a few simple steps to making this happen:

Step 1: Decide Where to Begin

It can be daunting to take on the entire universe of support in one gulp, so focusing on the top 5 or 10 issues handled at the service desk is a great way to start. This can then be expanded over time using Agile-style development techniques. This may be driven by those common topics for which you have already developed knowledge, in order to shortcut the process. 

Starting with the top issues provides the biggest bang; it sometimes seems like the top 10 issues make up 80% of call volume, so starting with the top 10 is a great way to take on this initiative. Once the list of top 10 calls is gathered, survey the knowledge available on the topics.

Next, gather the stakeholders together including:

• The application or technical teams needed to resolve the issue/question when it is received
• One or two end users who have submitted tickets for the issue
• One or two members of the service desk and/or knowledge management team

With this team in place, first make certain there is documented knowledge available on each topic, or create the knowledge. Have the end users test it and provide feedback on whether they understand it. Also work with the technical teams for scripting any automated solutions that represent steps a level 1 or level 2 analyst would use to provide resolution.

Step 2: Create the Journey Maps

A journey map is a step by step graphic representation of the possible routes a customer will take through the process, including all logical branches. In short, it’s a visual representation of the path the process will take. The journey maps are developed using the knowledge articles referenced previously. Essentially, they start with the steps needed to perform a task or troubleshoot a problem. The continuing process depends on each answer and leverages conditional questions to step the end user through their journey until the issue is resolved or completes with submission of the incident. This is also where the end users come in. Have them walk you through the steps they would typically use to try to fix their issue and then have them walk you through using the knowledge article. Pay close attention to any language or steps they find confusing. The goal is to break the solution into small, manageable steps using graphics and videos as needed. The graphic below is a simplified journey map answering the question “How do I create a signature for my e-mail?”

Steps 1 to 3 in this journey map could also have a link to a video demonstrating the on-screen experience of embedding the signature. Most important in this map is the end question, “Were you successful?” Not only does it enable the incident to be opened, it also offers an opportunity to measure how many people successfully used the tip vs. the number of incidents opened to a support team.

This is a rather simplistic example, but consider an issue printing to a local printer. The end user can be walked through simple checks with questions like, “Have you tried a different cable?” If the answer is no, they can be asked if there is a cable they can use. A no might open an incident to a tech to swap out the cable, while a yes would lead to another troubleshooting question. When/if an incident is actually opened, all of the questions and answers are submitted with it, so the technician picking up the ticket knows what they’ve tried.

The route through the question and answer may also help determine where to land the ticket. Up to a certain point in a journey may route to a service desk analyst; further down the journey might route directly to a level 2 technician. It’s this level of complexity that is the reason for the journey mapping. It’s critical to capture each route or use case for each answer to a question or for each instruction, and plot the course the effort should take next.

Step 3: Create the Incident Form

As described above, once the journey maps are complete they can be translated into an incident form within the application. This will require a combination of instructions and questions that generate the conditions corresponding to the journey map. While the example used in this blog is very simple, the corresponding form might also be very simple. But for true technical issues, the form will include several questions with each next set of questions driven by the prior response. Here’s an example of what the incident form might look like for the email signature example:
 

It may look a lot like a knowledge article, except that when an actual troubleshooting example is used, there would also be questions, with their responses being logged. On completion of the form, the final “helpful” buttons drive creation of the incident or logging of the successful attempt.

Embedding graphics and videos can help end users with any complex steps, and where a utility is needed, scripting can enable the end user to run the utility (for example, executing a spyware cleaner at an appropriate time to help with slowness). When an incident needs to be logged, all of the information captured during the process is submitted to the incident as text in a description field (or variables on the form, depending on the tool).

Transforming Incident Management

There are two distinct advantages to transforming incident management in this way:

1. According to MetricNet, the cost of self-resolution is approximately $2 per instance vs. $22 at a level one service desk or $62 at desktop support! This cost estimate can help when building a business case for the cost of building the incident forms and the adoption case for the effort internal resources will invest. All it takes is an estimate of how many calls could be deflected as a result of the incident wizard and then calculating the savings.  More service desks won’t actually eliminate headcount with this as there’s never enough staff to get all of the work done. But the team member who comes off the phones can work on more strategic work that has more value, like building more knowledge and designing the content for additional incident wizards. Over time, this strategy could assist in stabilizing staffing levels in the face of continued growth by reducing volumes in some areas as new services are introduced.
2. The efforts done to instrument true self-service represent the first step towards moving to chatbots for resolution of problems through a service portal. The common misconception about chatbots is that you turn them on and they start providing support. The truth about them is that you have to instruct the interaction from start to finish. With this in mind, the incident wizards that an organization builds are the first step to building the chatbot logic. This logic is very similar to the incident wizard logic, with escalation into an incident if the chatbot interaction fails to resolve the issue working with the user. It’s worth noting that chatbot interactions can also transition to a technician via chat. If the chatbot is named and given a personality, it can act like a level 0 agent, passing the chat to a level 1 agent and ultimately to an incident.

While this value proposition addresses benefits from a service desk point of view, there’s also a huge improvement in the customer experience, particularly in those organizations where wait times and service desk hours drive the need for a self-service channel. While people wait, they can be advised to try the portal as a means of gaining assistance and work with an incident wizard while waiting, and they might resolve their issue along the way.