In this section of the course, we're going to be covering trust, but verify what makes a good ticket versus a bad ticket. And three examples of how to properly describe issues after we have resolved in for the user. When I first got into it, my manager told me very simply, he said, these laptops and desktops, whatever. These are only tools. Our users come to work. And we just want to use these tools.

When these tools have a problem, you're the thing standing between them and then completing their job. I say all this to Say, whenever we're dealing with our users, it's important that we trust what they're saying, meaning we don't belittle their feelings. But it's also important that we verify what the users are saying. For instance, you have to understand like our users, they don't know how to speak our language. Word, we're the ones in it. When you're going to the doctor, it's hard to describe, oh, my back hurts when I turn this way.

And for some reason, when I lay down, we don't know how to translate the issues that we're having to the doctor. So it's the same thing for us. Our users, pretty much sometimes don't know how to translate what's going on with this tool that they're trying to use. So it's important that we trust what they're saying. But even more important that we verify the issues that they're having. Let's go ahead and take a look at scenario one.

A ticket comes in and it's subject is I can't log in help. Now this is an example of a bad ticket. The person just opens the resolution and says users unable to log in. There's no information here, there's no detail of what happened. Or what particularly the user having problems log into. This is where we trust what the user is saying.

But we also have to do the job of verifying that the user can't log in. Now, after we contacted the user, this is what we discovered. We contacted the user and verify that the user is able to log into their local system. The user was not able to log into their office 365 account. We reset the user password and verify the user was able to log in successfully. So we see here at least Two times we had to verify something with the user.

It also went ahead and noticed that it wasn't the particularly local system, but office 365. And there's also kind of a giveaway that the user didn't really explain the issues properly. Because if the user couldn't log in, they wouldn't have been able to go in and submit a ticket. So we know at that point, something was a little fishy. Let's go on to scenario two. scenario to this subject tick is my computer is infected, I think.

Now a bad ticket would have something like the user system is infected, told us to shut down the computer. There's no information here that any actual work has been completed. Nothing saying that the user logged in nothing saying that. You connected to the user. You just told us to shut down the computer. Now, that doesn't help the situation, nor does it help the user be any more efficient because at the end of the day, when something isn't done, they're going to say, It told me to shut down my computer.

So we trust what the user is saying. But it was time for us to verify that the user system is indeed infected. And once we contacted the user, this is what we got. We contacted the user and verify that the user system is not infected. We asked the user to describe the potential infection on the system. And the user informed me that she is getting a pop up from Outlook.

To reset her password. We connected to the user system, assisted in the password reset and verified the system was not infected. So we see here once again, we verified At least two different things about this situation. We also know that the user was just having problems with Outlook. And then to go ahead and further assist the user by getting rid of the annoying pop up by helping them reset their password. And last but not least, scenario three.

The subject is the laptop is running extremely hot, and I want a new one. Now, this is a little bit more disgruntled employee, maybe a VP or someone like that, that pretty much has the position to say I just want a new one. But sometimes it just because our users have a certain status in the company, it's still important for us to think for them in these type of situations because the downtime that a VP would go through on getting a new laptop would hurt him a lot more than trying to troubleshoot this issue. So this would be the example of a bad ticket, we submitted requests for a new laptop to desktop support, then it has to go out and it has to be approved and the laptop has to be imaged and then it has to be assigned to the VP, all this other stuff.

So we trust what the user was saying that his laptop was running hot. But now, we had to verify why it's running hot. Now after an hour investigation, this is what we discovered. We visited the user office and inspected the system assigned to the user. Observing the environment. I noticed the fans of the system were covered in dust.

We clear the fans of dirt and debris and compressed us with compressed air and verify that the system is cooling. We inform the user we will follow up in 24 hours with the status update. So now you can start to see the difference between a good ticket In a bad ticket, and also in the process, just with these three users, your credibility as an IT professional begins to work, grow. It's all about details, details, details, details and move moving on from there. It's always important that you trust but verify. I hope you guys enjoyed this course.

I will see you again in the next one.