How to improve adoption of the IT service desk software

Do you remember the time Facebook changed its layout? And all the opposition it brought about? Used to the old layout, the ‘updated’ one was faced with resistance and a whole lot of cribbing. In hindsight, I bet we don’t even remember how hard it was for us to accept that change. Do we even remember the old layout? I don’t.

Implementing a IT service desk software is actually easy – believe me, it really is. I’ve personally worked with many organizations – especially ones moving from an email system – and the actual product implementation takes less than week. Most of my customers are actually worried about how they can get their users to start using the portal.

The toughest part of implementing a new service desk software is actually getting people to use it.

Expectation: End user has a problem > They log in to your service desk portal > Access knowledge base > Solve their problems > No ticket!

Expectation of an IT service desk

Sounds easy right? In a perfect world, yes!

Reality: End user has a problem > They email the service desk or worse, walk up to an agent and hover over them
Reality of IT service desk

Why does this happen?

Usually, the entire service desk software is set up by the agent or the admin team without taking the end-user perspective into consideration. The feedback, if obtained, is usually from their peers or management who also don’t really understand how it is to be a requester. It’s not that they aren’t empathetic, it’s just that they’ve been on the other side of the service desk for way too long.

What can we do about it?

IMO, there are two ways to go about helping end-users easily adapt to the new service desk software.

  1. Involve your intended end users in the implementation phase. They’re your customers after all.

Taking a leaf out of my favorite TV Show, Silicon Valley, the founder (Richard Parker) builds a file compression app and beta tests it amongst his peers who also happen to be tech geeks. He receives amazing reviews from everyone who tests it out, and jubilantly launches it into the market. After the launch, he sees that the actual user adoption is far from expectation, and finds it hard to believe that it didn’t work out. Richard is convinced that ‘everyone’ loved his app but he doesn’t realize that ‘everyone’ for him does not include non-tech people.

Think about it – the app was developed by geeks and tested by geeks but intended for regular people. How can it possibly be appealing to the target audience without them being involved in the building process? No one could give you better feedback about the software than its intended end-users.

You could get volunteers from different teams to use your new system and get honest feedback before implementing it. The feedback will make you think in directions that you would otherwise never. With the volunteers feeling more close to the product, they’ll automatically want to encourage their peers to use the same system. This effort will pay off in the long run when they resort to using self-service extensively and you’ll inevitably be relieved of handling those basic tickets.

A great way to spread the word about your implementation – nothing motivates employees like a secret project involving only a select few members. Which makes it much more exciting than a run-of-the-mill service desk implementation project.

  1. Always speak your end-users’ language while setting up the service desk

We’ve said enough already.  Say the IT guys creating the UI don’t really understand or give much thought about their users. You can take a wild guess on how that interface is going to turn out – an interface filled with enough technical jargons to confuse your users who couldn’t care less about SLA or CIs.

Keeping the end-user personas in mind is imperative while implementing and designing the service desk portal – it’s what drives adoption within the organization. For instance, “Report your issues here” reads much better than “Log an incident” on the end-user portal. While these terms may sound really simple, your users may be technically savvy, or not. You need to write whatever is meaningful and familiar to the audience, and not for yourself.

One Such Example

Take a look at both these ticketing forms. Which one are you more likely to fill out?

Good vs Bad Service Desk

The ticket form is a great way to talk to your end users. Some companies do it brilliantly! I’ve seen end user forms configured with dropdown content like “My laptop doesn’t work,” or “My printer doesn’t work.” It’s more familiar and relatable to the end user, which will in turn make them want to use the portal, and not walk up to the IT team.

Still not convinced? Here’s how the knowledge base plays out for better support

Knowledge base is hard to get right in any organization – it’s more than just another FAQ forum. It’s not just about populating the knowledge base with self-help articles but also writing it succinctly and in a way that your end users understand. If your end users are anyway going to walk up to with questions about the articles, it defeats the purpose of a knowledge base.

By adding visual elements like images, screenshots, GIFs and videos, and tracking their usage to identify improvement areas, you can easily boost the adoption of your portal. Ideally, the only time they should be reaching out to you about a KB article is to appreciate its readability – as if that’s going to happen, but hey you never know.

Most of the modern service desk software allow for complete customization of the end user portal. From the ability to modify texts to overhauling the look and feel of the portal to suit your branding policies, you can do much more now to make support easier for your end users.

All right, this sounds good but is it really going to work out?

Frankly, you won’t really know till you try it out. We’ve established that it is hard to get users on a new platform. But it’s proven that it’s definitely easy if the platform is made for the end user rather than the creators of the software. Not to mention that service desk implementation is a continual process and there is always room for making things better.

The problem with changing the way an existing system works is that it’s almost always welcomed with defiance. But once you get past the initial discontentment, it’s as if the change had never happened. Of course, it was easier with Facebook for lack of other options.

There you go! In my experience, these are a couple things that have direct impact in improving service desk adoption across the organization. What would you like to add to the list? Drop a line right here, and let me know your thoughts about the article.