In this section, we're going to discuss what it takes to be successful on the Help Desk, or service desk in the IT industry. Follow along with me as we discussed four different categories that each technician needs to know. The four categories that we're going to look at are as follows. We're going to discuss good practices, bad practices, troubleshooting, and points to remember. Let's go ahead and start off with good practices by a technician on the Help Desk slash service this and this is for any company pretty much any company you contact whether A cable company oil and gas manufacturing doesn't matter. The Help Desk position is practically the forefront in representing it when anyone in your company has an issue they call the help desk, hey, my look is an opening or I'm trying to send an email and it's not going out or I need something recovered or I need my password reset.

The helpdesk is going to be the forefront of the IT industry. So this is why it's important that we discuss these four topics. Like I said, we're going to start off with good practices. Now, regardless of your industry, as stated before manufacturing, oil and gas, retail, different things like that. Most companies have policy for anyone on Help Desk before they close a ticket. Now this policy pretty much is as follows.

You have to attempt to contact the user multiple times before you can close the ticket. So that multiple contact detail can be multiple emails, voicemail, you run into them at the zoo parking garage, it doesn't matter. As long as you've tried to contact the user at least three times, then you should be covered. Like I said, it can be two emails in one voicemail, two phone calls and one email, different things like that. But it's always a good practice to try to contact the user multiple times. Most of the time users will put in a ticket stating that they have an issue and then it will be extremely hard to get in contact with them again.

Attempt to contact the user multiple times, will cover you on the Help Desk. Stating that you've done your job basically, you tried to reach back out in various different ways, and you're not getting any response back. Now, the second best practice, if you're on the helpdesk is to focus on what you can provide the user Now, sometimes when a user calls, and it's over a ticket that's been sitting in the queue for let's just say two weeks, and they haven't heard anything back, or they keep getting transferred from department to department, things like that. It's good to kind of put it into that. You don't want to keep sending the user around and he's hula hoops, or making excuses and things like that because you don't want to build that reputation as a technician in the IT industry. Your reputation will follow you depending on no matter what industry you go into, they don't have that many people in the IT industry.

So chances are you may run across various people as they progress in the IT industry. And so you want to be protective over your reputation. And like I said, versus constantly discussing what other departments did in different situations for the user. Of course, you want to let the user vent, but focus on what you can provide them now, they will greatly greatly appreciate that. Our third point is to explain to them what you're about to do. A lot of times, subconsciously, I've seen technicians kind of just automatically go in and fix the problem.

And then they'll get a complaint. And the technician will get mad and say, Hey, well, I fixed the problem. Why are they mad? Well, it's all about perception. If If my apartment is dirty, and I hire a me to clean my apartment, and I come home, and My watch is missing, even though the maid clean the apartment, I'm gonna think she's stolen. But if the maid tells me while she's cleaning that, hey, I'm going to place your watch in the drawer.

I noticed you left it out. This is where it is. When I come home, now I can find it. I'm not going to panic, I'm not going to lead a bad review. Whenever you're assisting someone. Let them know what you're going to do, hey, I need to recreate your profile and outlook.

I'm going to backup your PST s. Hey, I need to reset your Google Chrome web browser. This is going to delete your history. It's always best practice to verbally tell the user what You're going to do so they can brace themselves or perhaps is something important that they don't want you to tamper with. So you'll know to avoid that. Our fourth point, always inform the user of what you see. Now, why would this be important?

There's been situations I've seen in the past with PST files. Sometimes users create multiple PST files. And to them, they may have four or 567, PST mapped and outlook. their perception is that they have that many PST s. But actually, when you sort of go in and try to expand the PST, it'll say, oh, it can't be found. It can't be found. It's very important to let the user know that because let's just say you're migrating a user from one system to another or you're trying to troubleshoot different issues and outlook is good to, like I said, inform the user of what you see, hey, I see that you only actually have one PST file, I'm going to go ahead and remove these other imitation files or image or mapping attempts in Outlook.

So that way your outlook can run faster. And just an example like that, we inform the user what we saw, and we explained about what we're going to do. And we're focusing on what we're going to provide now. That's how you gain a great user experience from an end user. Now all of this means nothing if you do not do our very last point, which is update the ticket. If you don't update your tickets, and the help desk or service desk position or any position in it, it's almost like your work.

Never took place. There's no proof. It's your word against theirs. If you explain to the user what you're about to do, update that in a ticket, if you're going to inform them if you just inform them of what you saw, update that in a ticket. If you ran into the user at the zoo on the weekend, and you've let them express to you, the different issues they've been having all week, and you say, I'm going to get with you Monday, Monday morning, make sure you put that conversation in the ticket, contacted user over the weekend, user stated that outlook constantly crashes when he opens will troubleshoot issue when users available, date and time. Always update your tickets.

I can't stress that enough. Now that we looked at five different ways that you can implement good practices on the Service Desk, we're going to look Get a few bad practices that I've seen that have been implemented in the Help Desk service desk position. Now, our very first point, I've seen this at multiple companies, even when, let's just say you contact your cable company or phone company, it's very common for the person on the phone to treat you, as if they're never going to see you in person. Like you're disposable, like, Oh, I'm sorry, this happened to you, but I'm going to lunch. Because they know they're probably 500 miles away from you, you're never going to reach them. So the level of care isn't there.

But in a corporate environment, the users will run into you, in like I stated in the last section, your reputation will begin to follow you. And you don't want that to happen. And so you'd never want to treat users as if you're never going to see them in Like they're disposable. Our second practice is pretty a simple one. But it kind of provides a better user experience. You don't want, even though you're working on fixing the user issue, try not to allow complete silence on the phone.

If you do, place them on hold, let them know, Hey, this is going to take a while I'm going to place you on a brief hold, would you please I'll inform you give me about 10 minutes. majority of the time, they'll say okay, but when it's usually just dead silence on the phone, the user isn't really having a great experience. And the reason why I'm explaining this is because the users may not explain this to you. But majority of times when you close the ticket, they're sent a survey and the survey will say how has your experience been now Your reputation with your supervisor manager begins to stack up. So one of the fundamental parts of being on the helpdesk or service desk is about the experience of the user. And you always want to explain the current status step by step.

If you're going to place the user on hold, you can place them on hold, come back in maybe five minutes and say, Hey, I'm still working on the issue. I'll be back soon. Majority of time, they'll say, okay, 10 minutes may go by again, come back and explain the use of Hey, I'm still working on it. I'm just a, b, and c is going on and we're trying to fix a BMC. It's all about the user experience. A third point, which is a very, very bad practice, this will kind of get you in trouble very soon, is closing tickets unresolved.

Now, in the first section we discuss in a good practice is to attempt to contact the user multiple times, which is fine. If you've contacted the user multiple times, and you documented it, majority of companies will say it's fine to go ahead and close the ticket, even though the issue hasn't been resolved because you attempted to contact the user. But you don't want to just close tickets unresolved, because you're trying to increase your ticket count, or beat someone else on the Service Desk out of tickets or things like that. Because the users will get extremely angry at that. And next thing you know, your manager directors get involved. Why is this being closed, different things like that.

So that's one of the more major bad practices that I've seen implemented in the Help Desk position. Now our last point, is something that's starting to become more frequent in the IT industry. When I first got in the industry. I've been in It industry for about 10 years now 10 or more. When I first got in the IT industry you couldn't escalate any ticket to any department. Without details.

You had to state everything that you've tried us a contacted and said outlook is freezing, attempted repair, attempted to unmapped PST files and reopen outlook attempted to restore to a previous date and time, different things like that. Then it was okay to escalate the ticket to maybe the server team or the network team or desktop support. But you always never escalate a ticket without details. That's something that like I said, is becoming more and more a common practice. But this isn't something that we're going to practice. Now, we're going to dive into troubleshooting.

As stated in before, this help desk and service desk is the forefront of the IT department. So troubleshooting skills is going to be very important. Now when a user calls, if they're just complaining, I won't say complaining but venting about their past issues. It's kind of easy to start, maybe Daydream, if you're, if you're not really interested in what they're stating, or it's early in the morning, or it's 30 minutes before you come home. So it's very important to understand the why. Why is the user calling?

Sometimes a user can say, Hey, I put this ticket in, and my outlook is still freezing. This has happened. I've been transferred. This is going on a B and C. But why exactly They call do they want their issue fixed right then and now? Do they want to speak to someone above you? We have to figure out exactly why they're calling.

That's going to be the first point of troubleshooting. Always figure out the why. Now, the second point is very important. All you always want to ask the user when did this begin? Because that's going to tell you a lot about the situation. If it happened two weeks ago when the server crash, okay, now we know we have a timestamp.

You want to build a timestamp when it comes to troubleshooting. When did this issue begin? user says it began two weeks ago. Two weeks ago, you remember the server team sent out an email saying, hey, exchange is down. If you guys run into any issues, let us know or Two weeks ago, someone sent them an email and they double clicked it. And now the system has been running weird ever since.

Now, you know, more details and you can troubleshoot a lot better. It's all about details. Now another point is not to incriminate. But you want to inquire if you notice that every time a certain user prints a file, the system hangs or no one else can print. You don't it's not really good practice to confront the user and say, Hey, are you the one doing this? Because majority of time you can easily find out who's causing a print jam or who's trying to print 500 pages by accident.

But it's always good to inquire. Don't incriminate inquiring meaning once you find out what exactly is going on, offer the user guidance. Let's just say it's Betty from accounting. And every time she tries to print, she's in the habit of double clicking everything. So every time she hits print, she double clicks it or this or whatever. If you just come straight out and ask her, are you the one causing these problems?

He's going to get defensive until you know. But if you ask her, Hey, I've noticed that a lot of printing is going on from your department, and I see that your name kind of popped up on a few of the print jobs. It seemed like it's a lot of documents that came out. How would you feel about if, you know I kind of walk you through different ways that you can accomplish this printing in a more successful way. Now you have the users trust now they're not so afraid to say yes. It's been me, I'm sorry.

I just don't want to look stupid. So I haven't asked. Like I said, it's all about the user experience. And you always want to get permission from the user. You always want to get permission whether it's mapping a printer, offering guidance to the user, telling them in the beginning, as in good practice, telling them what you're about to do different things like that. If it's okay to delete certain files, if it's okay to view certain emails, you always want to verbally or written only get permission from the user.

In a lot of these practices are in place to protect you. Because if something gets deleted, anyone can say I never granted you access to do this. This wasn't your concern. Now you've caused more problems then you've tried to fix And you'd never want to eliminate options for the user. Sometimes when users call with an issue, you don't want to just say, I'm sorry, I can't fix that. Or no, there's no way we can just go ahead and do what you're asking.

You never want to eliminate options. You can be honest and say, I'm sorry, I'm not familiar with that. But I'm going to look into it. And I'm also going to get another team involved. You don't want to create roadblocks or speed bumps for the user. Eliminating options tend to cause a lot of frustration because they're relying on you.

You know more than them about technology the same way a mechanic may know more about cars than you are a chef knows more about cooking food than you so it's always Good Practice in troubleshooting, not to eliminate options, both for the user and for yourself. Now, what are the good points we can take from this? Well, our first good point is don't lie, or guarantee. Just explain. You don't want to lie to the user and say, Oh, yeah, we fixed that. And you know, this happened a BNC happen.

Because chances are, the truth is going to come out in IT industry, you can't really lie. Or you can't guarantee anything. Sometimes, a user may ask you that flat out. So you're saying after this, everything is going to work. You can say to the best of my knowledge, it's going to work or it should work. The reason being, is because you're not responsible for technology.

Technology is just a tool you're not responsible for if you fix an issue and then use it goes home and download another virus. Now they saying that you guarantee that this issue would be fixed. You just want to explain to the user, what's been done, what you can do, and what they can do to avoid the issue in the future. Now, that brings up a good point for our second thing we can take away from this. You are not a magician. You're a technician.

You're not a magician, you're a technician. We don't perform magic to the user. I'm pretty sure it looks like magic because they're not exactly tech savvy. But it's important to never adapt that mentality. Of course you want to be proud of the good work that you do. But getting big headed in the IT industry only last about who knows, maybe 20 seconds, because there's always going to be another issue.

So the last person, you can be Superman, and the next person, you can be the villain. So, as stated, it's not magic, you're just a technician. We all are. So if you keep that in mind, you'll notice a very smooth pattern of successful repairs. Now, last point, is very important, especially when it comes to other departments. It's important to keep in mind everything that we discuss here today.

For this point, every conversation is an interview. And I'm going to say why I learned this when I was on service desk, and then I got promoted to desktop. And then I got promoted to Senior as a system administrator, and then I got promoted to server administrator. I realized this from one of my managers stating that every conversation is an interview. If you build a reputation of closing your tickets successfully with resolutions, walking the users through your experience, leaving out all the bad practices, the best ways to troubleshoot, a lot of people will start to notice this. So when they come to ask you, hey, how did you fix this issue?

Or What did the user mean by this? Now you're going to have that reputation that can get you promoted, because every conversation becomes the interview, meaning you're building a reputation of success. Everyone's going to know how smart you are, how good you are at troubleshooting the best practices you implement that will carry you very far in the IT industry. I hope you guys enjoyed this course. I will see you again in the next one