About the Knowledge Base
Search all the Knowledge Base
Testimonial: I have found that the new HDAA Knowledge Base reduces the time it takes me to research industry stats & reliable information for the ITSM sector. It’s easy to use search functionality encompassing KCS principles, helps to filter & tailor my searches more accurately & there are numerous new services now available through the website. Every time I return to the site there is new information published. Very impressive.
Chris Powderly, Support & Services Manager, Allens
supportworld , ITSM , service management , selfservice , incident management , customer experience
No Result Found
Shift left is an industry wave focused on moving many aspects of IT service and support towards the lowest cost option:
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.
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.
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:
With these in place, there are just a few simple steps to making this happen:
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:
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.
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.
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).
There are two distinct advantages to transforming incident management in this way:
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.
Phyllis Drucker is an ITIL® certified consultant and information leader at Linium, a Ness Digital Engineering Company. Phyllis has more than 20 years of experience in the disciplines and frameworks of IT service management, as both a practitioner and consultant. She has served HDI since 1997 and itSMF USA since 2004 in a variety of capacities including speaker, writer, local group leader, board member, and operations director. Since 1997, Phyllis has helped to advance the profession of ITSM leaders and practitioners worldwide by providing her experience and insight on a wide variety of ITSM topics through presentations, whitepapers, and articles and now her new book on the service request catalog, Online Service Management: Creating a Successful Service Request Catalogue (International Best Practice). Follow Phyllis on Twitter @msitsm.
No Result Found
- Contact Us
- IT Membership
- Support Centre Association
- Comparison Guide
- Price Guide
- Membership Conditions
Training & Workshops
- Training Courses
- Recent Workshops
- Cancellation & Transfer Policy
- ITIL Training
- ITIL Foundations
- Support Centre Consulting
- Service Desk Consulting
- Help Desk Consulting
- Media Kit
- Update your details
- New account
© Copyright HDAA. All rights reserved.
HDAA - Energising the Service & Support Profession
Help Desk Association Australasia Pty Ltd trading as HDAA
T: 1300 130 447 T: +61 (0) 2 9986 1988 F: +61 (0) 2 9986 1330
E: email@example.com W: www.hdaa.com.au A: PO Box 303, Turramurra NSW 2074 Australia
ABN: 20 088 292 755
Our Services: ITIL | ITIL Training | ITIL Foundations | IT Membership | Service Desk Association | Support Centre Association | Support Centre Training | Service Desk Training | Help Desk Training | Support Centre Consulting | Service Desk Consulting | Help Desk Consulting
ITIL® and PRINCE2® are registered trade marks of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
RESILIA™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
The Swirl logo™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
DevOps Foundation®, is a registered mark of the DevOps Institute.
HDI® is a Registered Trade Mark. HDAA is the Australasian Gold Partner of HDI®.
KCSSM is a Service Mark of the Consortium for Service Innovation™.
Apollo 13 Insignia image by 'NASA Johnson' (copyright-free) June 2017 via https://www.hq.nasa.gov/alsj/a13/images13.html
WEB DEVELOPMENT PARTNER