Document Findings, Actions and Outcomes

Video Activity

Document Findings, Actions and Outcomes The last step in the troubleshooting process is documentation. However, this should be a task performed throughout the entire process. You'll learn why it's both unprofessional and unsafe to assume you will remember everything you need at the conclusion of this or any other troubleshooting process and how the...

Join over 3 million cybersecurity professionals advancing their career
Sign up with

Already have an account? Sign In »

5 hours 33 minutes
Video Description

Document Findings, Actions and Outcomes The last step in the troubleshooting process is documentation. However, this should be a task performed throughout the entire process. You'll learn why it's both unprofessional and unsafe to assume you will remember everything you need at the conclusion of this or any other troubleshooting process and how the development of a discipline pattern of notation and note taking will make a world of difference to your ability to perform task accurately and more thoroughly.

Video Transcription
now, our last step in our troubleshooting theory process is going to be documenting our findings, actions and outcomes. Now, throughout our entire dhe troubleshooting process, we want to make sure that we're fully documenting everything that we're encountering because we don't want to get to the end of our troubleshooting process and then
say, Oh, well, what was that that I did before? What was What were those questions that I asked? What were those symptoms of this problem?
We want to make sure that as we're troubleshooting as we're going through, everything we're constantly documenting were constantly, constantly writing down or typing down so that we'll be able to have a very full, clear documentation. And we won't be rushing at the end in order to try to finish it up and make it clear.
Now, don't assume you'll remember, so this can apply to don't write all your documentation at the end as well as don't not document, because you just assume that you'll remember how to do this later.
If you run into this problem once and you perform a certain a certain set of actions that solve it, you may not encounter the same exact problem until
a couple weeks. A couple months later, you may not remember all the exact steps you performed, and you may perform them incorrectly. Or you may end up having to waste time to re research how you perform certain steps or how you exactly change certain settings. So it's best to document everything, even if you think well, I'll probably remember this later.
Just the have that as your reference just to be able to make sure you remember it because you have it written or type down,
I'm gonna make sure that you document your solution that anyone else could read it. So if someone else were to take your documentation and try to apply it to the same exact problem, you wanna have it written in the way that anyone could follow that it would need to be in a logical step of sequence. It needs to be detailed enough so that anyone else who may have
no experience with
the this particular issue, they may have helped desk experience. They have desktop support experience like you, but they may not have gone through this. A same exact issue will be able to take your document and be able to use your steps in order to solve the problem.
And then you want to make sure that you've document everything when you die. You doing your documentation? That's just this does not just include your solution. You don't want to. Just at the top of the page, put
monitor would not turn on. And then, at the bottom of the page, put
reinstalled driver.
There were some steps that happened between when he found out the monitors would not turn on to the bottom. When you ended up reinstalling the driver you want to put in your causes and symptoms. You want to put in that the monitor did not turn on and these were some of the symptoms when you when the person tried to turn on the monitor.
You know, I may have had some flickering. They had some issues on the monitor, and then the monitor went back off.
You wanna put in your attempted solutions, you had them check the cable, you had them check to see if it was possibly the monitor was bad, and then you would put your in your correct solutions. Maybe you booted into safe mode with a stain envied with standard V g A. And that solved the problem. The monitor now came on and he said, Okay, I'm pretty sure it's the driver.
Then you went in and you updated the driver. You insult and reinstalled the driver
and then everything worked properly. So and then you want a document Which driver? It was. Which version? The driver was where you found the driver. If it wasn't out on your network somewhere, so that if someone has to follow you up later, they confined that driver in the same location. They can read and reinstall it, and they don't have to go through all the exact steps that you did
in order to solve the issue.
But say that they see your issue. They see your documentation. Your solution doesn't work. One of your attempted solutions may work for them.
The driver may have not been the issue for them, but it may have been the cable, or it may have been the port on the monitor. So you want to make sure that you're documenting everything your attempted solutions, a cz Well, as you're. Of course, you're so your actual solutions, but also your attempted solutions.
And then, lastly, when the document any follow up our maintenance that you perform any any time you go up afterwards to the individual or any preventative maintenance that you suggest needs to be performed on this computer, you want to document that so that there's a record of that preventive maintenance that you're recommending.
So thank you for joining us here today on cyber dot i t. Today. We talked about troubleshooting theory, and we talked about how Internet education takes patients veracity and dedication the an Internet staining for identify our problem. Identify what the issue is on our computer.
E stating for establish a theory of probable cause. We want to research what the issue is. We wanted to start eliminating variables, and we want to establish the actual issue that's happening.
And then we won't use the word tea for takes and T is going to be a test. Our theory. When we test our theory, we take a theory that we established when we did our research and we go ahead and we test that we see if that's the actual theory and then pee for patients. We have our plan of action we
put in place our plan and we
take that theory that we tested and we made sure that the OK, yes, this is our theory and we create our next steps. We say what we need to do in order to fully solve this problem and we implement that. And then finally we have our next we have V, uh, we have our verify our full system functionality. We want to make sure that what we were doing before what
our user was trying to do on their computer, they can still do
and that implementing our plan hasn't caused any other issues on our computer. And lastly, we have dedication D r d d is going to stand for documenting everything. We wanna make sure that we not only document our problem in our solution. We document everything from
when we noticed the problem when the problem started.
It's all the way through our troubleshooting are researching and any attempted solutions that didn't work and then all the way until the end of our maintenant preventive maintenance and are following up with the user and following up with the particular issue.
So hopefully you'll be able to take this information and help you to be able to troubleshoot a little bit better. Hopefully you'll be able to understand troubleshooting theory and how we eliminate variables. And hopefully we'll hear from you guys and we'll get a little bit better acronym to use. And hopefully we'll see you here next time on cyber dot i t.
Up Next
Troubleshoot Critical Systems

Diagnosing system malfunctions and finding a solution is an important skill for help desk professionals to develop. Expand your knowledge of the troubleshooting theory in less than an hour.

Instructed By