Instructor: In this lesson,
we're going to talk about the final step
in the troubleshooting methodology,
which is step six, documentation.
Now, CompTIA calls this document the findings,
actions, and outcomes,
and this really is all about documenting what was wrong,
what you did about it,
and what can be done to prevent it in the future.
Now, every organization is a little bit different
in how they do their documentation
for all the different problems
and issues they've had inside of the company.
Now, at my company, we use a trouble ticketing system
that's dedicated to this that allows us
to document all of the problems, who it's been assigned to,
what they did to fix it, and what the solution was.
In addition to that,
we also have our own internal knowledge base
where we can gather all of our troubleshooting steps
and all the things we've learned in the past
as we've been troubleshooting different issues.
Now, in addition to that,
we also have an area called our Frequently Asked Questions,
and this is an area which has a bunch
of different support articles based on the questions
that we get from our end users on a daily basis.
It took a long time to build up our knowledge base
and our Frequently Asked Questions,
but it is something that is really helpful,
especially for new technicians as they join the team
because they can go look through
our Frequently Asked Questions and our knowledge base
and learn how we do business and how we solve issues.
When you work as a technician,
your organization may or may not have a knowledge base,
frequently asked questions,
or a trouble ticketing system,
depending on the size of your organization.
These days though, even small organizations
can get a great trouble ticketing system
for a very low cost or even free in some cases.
There are lots of them out there, including Freshdesk,
Jira, Help Scout, Intercom, and many, many others.
Now, which one you use really doesn't matter,
but the idea is the same.
You want to be able to document your findings,
your actions, and your outcomes.
Now, another part of this
is that you don't want to wait necessarily just 'til the end
to do this either.
As you get assigned a ticket
and you're identifying the problem,
you should be going back into the trouble ticket system
and documenting what you've identified,
what were the symptoms you saw,
what do you think is the probable cause of this issue,
and then as you keep moving through the steps,
you want to keep updating this.
If you're dealing with a small problem that can be resolved
in one sitting,
you're probably not going to have to update the ticket
for each and every step.
But if you're dealing with a larger problem,
then it's really important to be documenting this inside
of that trouble ticket system.
Another reason that the trouble ticket system
is so important, especially in large organizations,
is it allows you to do trend analysis.
This will allow you to be able to figure out
what are the common themes or problems
that your organization is suffering from.
For example, in one organization I was in,
we found that 90% of our phone calls for trouble tickets
had to do with people needing their password reset.
Now, that was a huge amount of person hours
that we were dedicating simply
to resetting people's passwords.
So we decided that as a trend,
this was not a trend we liked,
and we ended up working with our developers
and our system engineers to create a password reset option
that people could reset their own passwords.
And this dropped our trouble ticket load about 90%
as soon as that system went live.
So this documentation can be really important
in identifying areas of continual improvement
for your organization as well.
Another side use of this trouble ticketing system
that you're using to document your findings, actions,
and outcomes is that you can actually document the amount
of work you've been doing.
Now, this can be a good thing or a bad thing
depending on how much work you're doing,
but I can tell you personally as an IT director
and running a help desk with 150 people in it
supporting over 15,000 users,
that we used our trouble ticket system all the time
to help justify the fact that I needed more people
to support those 15,000 users.
And this was because we started seeing the volume
of our tickets going up.
As we started looking at it, we found
that it was because there was new systems being installed,
and often, the organization would spend money
on new systems, but they wouldn't spend money
on training its users,
and so that led to more calls to the service desk,
and that's fine as long
as we can get more people to answer those calls.
Otherwise, the entire system starts to grind to a halt.
So keep this in mind.
The more you can document, the more you can justify
what you as a technician are doing
as well as the larger help desk staff that you're a part of,
and this can help identify times when there needs
to be more resources put into your service desk system
to be able to hire more folks
or to increase the skill level
of the folks you have to be able to answer those calls
in a better and more efficient way.