Doccumentation
Ticketing Systems and Documenting Your Work
(Required)
en
Process Documentation
Let's take a look at examples of good and not-so-good documentation. Here's the deal; you encounter a strange issue when helping a user out. This issue happens so often that you and your colleagues have encountered it. No documentation is the worst documentation. Imagine if it took you hours to figure out an issue to a problem and you didn't write it down. Your colleague encounters the same issue and takes hours to figure it out, then he also doesn't write it down. This can go on and on. It only takes a little bit of effort to create documentation and it can save you so much of your time, your company's time, and your users time.
This isn't the best example of documentation. The problem that IT support specialist stated isn't specific and it leaves you with more questions than answers, and while it tells you what we'll fix an issue, it doesn't tell you how. Documentation should be straight and clear cut. Your reader shouldn't have any questions when following the instructions you listed. Now, this is a good example of documentation.
It starts off with a very specific and clear problem. It gives you background information on what the issue is. It even gives you the exact instructions on how to fix the issue, including which settings to navigate to and where. Remember, always write documentation that makes it easy for your reader to follow.
Documenting in Ticketing Systems
Now that we've talked a little bit about documenting processes, let's talk about how you write documentation in ticketing or bug systems. You don't have to leave a full example of process documentation for every ticket you handle. If you encounter the same issue, just write the documentation once, then refer back to it. One of the more important aspects of writing documentation in a ticket or bug, is that you leave an audit trail to see what worked and what didn't. Let's take a look at some examples of awesome documentation and not so awesome documentation in ticketing and bug systems.
This isn't helpful at all since we don't know what the issue was or what the IT support specialist did to fix it. If someone stumbled upon this ticket with the same issue, it would be pretty useless.
This is an example of a great ticket documentation.
The tech described what the issue is, what caused the issue, and the specific steps they took to resolve it.