My first day on the service desk was frightening. 

I had learned so much to get to this point. 

Now I have to answer calls and provide a service on the spot?! 

Anyone could be on the other end of the line. 

It could be a receptionist with a simple password reset, or it could be the company Director with an urgent, business-critical failure. 

I had no idea what to expect.

But then, I logged in, and the calls came flooding in.

I didn’t have time to react. I learned on the spot.

Countless mistakes were made. But I learned from each and every one.

Now, I’ve been awarded as one of the best Service Desk Analysts in the country. 

Here are the 5 things I wish I could go back and tell myself on that very first day.

Service Desk Analysts are the front-line troops. 

They’re there to face whatever comes, and they very rarely know what is actually coming.

Let’s put you in the position. It’s the start of your shift.

Your first call is a user who can’t access a business-critical application. You remote on and see a really weird, obscure error message.

The stakes are high. You need help.

I’ve been in this exact spot countless times as an Analyst. I’ve also been on the receiving end of these escalations as a 3rd Line Specialist.

Asking for help in the correct way is an absolutely crucial skill to learn.

When asking for help, you should always include:

• A screenshot of the issue or request
• Extensive troubleshooting notes (see our troubleshooting guide here – TO BE ADDED)
• A suggestion to pick their brain

Here’s a bad example of asking for help:

“User gets this error message (screenshot attached) when launching Citrix. Can you help?

Here’s a good example of asking for help:

“User gets this error message (screenshot attached) when launching Citrix. I’ve reinstalled it, searched Google and our knowledgebase but can’t find any information. It works fine for their colleagues with the same set up. Could it be a backend permissions issue?”

Why the first example is bad

Escalation points are busy people and they assume the analyst has covered the basics before escalating. 

If you haven’t troubleshooted the issue, they will reply back with a very simple response (“Has the laptop been restarted?”). 

It may be some time until you get another response.

Not only does this negatively affect resolution times, it presents poorly to the end user, who will see an analyst come back multiple times with simple questions or troubleshooting.

Additionally, and I’m being brutally honest here, it reflects poorly on you. It shows a lack of effort on your part. 

Why the second example is good

An escalation point sees that example and is instantly engaged. They are more likely to provide a thought-out, tailored response.

Even more important than that, is the benefit to you and your skillset. 

If you are delving deep into every obscure error message or request you come across, you will gain vast amounts of knowledge and experience.

Every now and again, you actually resolve the call yourself. This saves valuable time from escalation points, and you get to share the resolution with colleagues.

Using this method, I have significantly reduced the load on the Service Desk and 3rd line teams during Major Incidents (MIs). 

Either I find a fix for the MI myself, or I provide valuable information to escalation points.

But how do you troubleshoot and engage with the caller at the same time? The next section will help with that.