How to increase usage of self-service portal for incident logging instead of emailing the Service Desk

An open discussion on issues related directly or primarily to the service or help desk.
Post Reply
DanDan
Newbie
Newbie
Posts: 1
Joined: Thu Jun 24, 2021 6:38 am

Thu Jun 24, 2021 7:41 am

Hi All,

I am looking for ideas how to promote to our employees the usage of our Self-service portal for incident logging and request management.

Today, majority of the incidents are reported via email to the Service Desk. We would like to shift left and increase the self-help usage.

Thank you!


User avatar
Corde Wagner
Senior Itiler
Senior Itiler
Posts: 56
Joined: Fri Nov 10, 2006 7:00 pm
Location: El Dorado Hills, California
Contact:

Wed Jul 21, 2021 9:29 pm

Great question!

I’ve experienced this challenge in several companies, and without a doubt, shifting users to tickets instead of email must have an executive mandate that it will happen. That said, assuming you’re your helpdesk is transcribing emails, phone calls and walk-ups into your ticketing system, here’s the basic and successful approach we took in multiple companies:

Concurrently:
o Make sure your end user portal for “self help” is as friendly as you can make it. Holding sessions with key stakeholders to gain their feedback if the portal really is friendly will go a long way. Make any and all improvements possible to ensure the end-user experience is as easy and positive as you can make it.
o Sell IT management on the need to mandate the transition (over time) by showing them the impact of not using self help and the positives for all users submitting their own tickets. If they agree, prepare whatever presentation that your management needs that will be shared with leaders for the other groups that you will require to switch from email to self help ticketing.

Cons:
• Emails are (almost) always missing key information and that forces the helpdesk to call the person sending the email. Tickets come with info by the person submitting the ticket. As you know both email and the ticketing system will present issues for the helpdesk if the GAL is not accurate, but emails likely won’t have call back phone numbers, full name, location, and other key information.
• Emailing a request or an incident means the timing for submitting and responding gets lost when the helpdesk enters the information into the ticketing system. Not having accurate submission date/time and other ticket information will surely hurt (or kill) your chances of providing accurate performance metrics.
• Not putting the email into a ticket virtually ensures some will be lost and/or forgotten by the helpdesk. (This you likely already know. 😉)
• Can’t prioritize email like you can with tickets based on categories, impact, urgency, etc.
Pros:
• Shifting the responsibility for creating tickets (e.g. shifting left to the customer) will save costs for the helpdesk. Not having to create a new ticket from each email will give back time to the generally small helpdesk staff.
• Metrics! You can’t get a viable metric from email like you can from ticketing system. For example, the “submit” of the ticket will provide a time stamp of when the incident or request was entered by the end user.
• Ticketing systems don’t lose tickets (the helpdesk teams may not pay attention to the ticket backup, but full email boxes has to be worse).
• The end user puts in the information you need into the ticket, reducing the need for the helpdesk to call just to get basic info.
• Priority tickets can be triaged faster and easier
o Begin training or provide refresher training for all IT helpdesk and support teams on how to manage their tickets and queues (before and after the email option goes away). Make sure the IT teams know why email is going away. They will have a need to know what’s in it for them to make this move, so be sure they are clear that it will help them but also that it will happen. Even IT teams resist change, so all teams must be on board.

Next
o Internally, have a plan and start the count-down to the day that IT will disable/remove the helpdesk email box.
o With support of IT management, begin the awareness program that email submission to the helpdesk will end by a specific date. I found even basic research on “organizational change management” (OCM) best practices to be helpful in knowing how to advertise, communicate and sell the move to ticketing. Some examples:
• Use the IT News Letters to make people aware
• Have the IT leader make the presentation at the company meeting(s). Do this every month before disabling that option.
• Make sure that leaders emphasize that calling the helpdesk will still be available (if it will), it’s only email that won’t be offered.
• Be sure the IT leaders have the information they need to sell the pros and cons that matter to the end user (not necessarily management). Prepare the message with the audience (end-user) in mind because they want to know “What’s In It For Me” (WIIFM)… this is very important!
• Put up posters
o Offer multiple seminars for how to use the self-service portal. This can happen in the weeks just before the move so that the information is fresh in peoples minds and you’ve had as much time to make improvements to the process and portal as possible.
o Identify and train “super users” or key stakeholders from each department, that will help people if after the switch they still don’t know how to submit a ticket.
o Some number of weeks before removing the option, add a notice as an auto-reply from the Helpdesk email box reminding the end-user that this option will be going away on XYZ date.

Implement the plan to remove the email option
o Make sure everyone in the helpdesk is prepared and on the promised date, remove the email option. Be sure they understand that people will be upset, and they should be supportive but firm that email is no longer an option.
o IT teams must not allow people to email or call them directly for the end-user to get around making their own tickets. To this point, as part of “Shift Left” working, all IT teams must realize they are responsible to make a ticket for anyone that emails, calls, or walks up to them. It’s my experience that non-helpdesk IT teams don’t want to make tickets for others, so their having the end-user make the ticket will make it so they don’t have to create the ticket for them.
o Early Life Support: Have members of IT make the rounds to ask how things are going and to answer questions. Change is difficult, so having people to help will ease some of the angst of your making the change.
o Set dates after the go-live to review how things are going. Make necessary improvements in training, documentation, etc. Be sure to look at metrics and how they can be improved too.

I hope this helps. I’m sure there’s more and I know this was too long, but I think this covers the important areas that will help you the most.

(apologies for the formatting, it's a cut-and-paste from a Word doc)
Corde Wagner
ITIL 4 Managing Professional - ITIL v3 Expert - v2 Red Badge - VeriSM-Plus - Certified Agile Service Manager
User avatar
Corde Wagner
Senior Itiler
Senior Itiler
Posts: 56
Joined: Fri Nov 10, 2006 7:00 pm
Location: El Dorado Hills, California
Contact:

Thu Jul 22, 2021 10:05 am

FYI, I posted your basic question over in the r/ITIL Reddit community. There are some good responses there that you may want to check out too.

Good luck!
Corde Wagner
ITIL 4 Managing Professional - ITIL v3 Expert - v2 Red Badge - VeriSM-Plus - Certified Agile Service Manager
Post Reply