Pages

Thursday, June 6, 2013

Good Documentation in Help Desk Tickets, or Lack Of...

I work in a somewhat large I.T. environment where work and responsibilities are distributed amongst each team. There are teams for development, server, network, help desk, and so forth. At the time of this writing, I am a member of the network engineering team. Our entire I.T. organization also uses the same work order system or "ticket system" for tracking issues, problems, and user requests. In each "ticket", we are all expected to make notes and track our work especially adding in our troubleshooting notes and what we did to resolve the ticket. But there isn't a week that goes by where our team is assigned a ticket where there is ZERO information to go off of. If you follow my articles on this site, you are already aware that I pretty much expect "the 5 questions" to be answered in each ticket before it is escalated or re-assigned to someone else. I also expect these questions to be answered by myself and yes, I do make mistakes sometimes. But I want to bring up an internal problem that we all face too often in our I.T. roles where we completely drop the ball on writing decent documentation.
So, what are some examples of poor documentation in a help desk ticket? Here are a few:

#1. The help desk receives a call from a customer\user about a problem with their computer where they cannot access the internet. From the activity logs, we see that the ticket remains in the help desk queue for several hours, and is then simply assigned to the Desktop support team to resolve with no troubleshooting notes. Then, a person on the desktop support team takes ownership of the ticket. The ticket sits in their work order queue for a few more hours, then that person assigns it to the network team with a note that says something to the effect of "PC can't get online. Please check the wall jack." This is where the activity trail ends.

#2. A desktop support team member creates a new ticket for a user because the user is unable to print to a network printer in their department. According to the activity log in the ticket, the desktop support team member noted the error that appears onscreen when trying to print from the user's computer and also has a screenshot attached to the ticket. The ticket was in the desktop support ticket queue for one hour, then was escalated to the server team with a note asking them to reboot the print server.

#3. An developer on the web applications team opens a ticket for a customer and assigns it to desktop support asking them to assist a customer that is having issues trying to access the company's website. There are no further notes and no details about the problem the customer is experiencing.

In the first scenario, we don't know if this is a widespread issue or if this is a problem localized to the customer's computer. We also have no idea what troubleshooting was done by the help desk or the desktop support team member. The network team member must now go through troubleshooting 101 all over again because there was no information on what was done in the ticket.

The second scenario is similar to the first. The first question that should have been answered in this ticket is "Is this a widespread problem, or is only this person having a printing problem?" Long story short, the problem was local to the desktop (Windows Print Spooler problem) and should have been handled at the front end.

The third scenario highlights internal communication problems. Sure, there are good reasons why developers shouldn't be contacting a customer directly. But the developer needs to help guide the desktop support technician in the right direction so they aren't entirely lost.

Based on the information from the scenarios above, it is clear there is a serious breakdown of providing proper documentation. We all are very busy and we all do work very hard, but having a lack of documentation hurts everyone. Saying the "I don't have the time" excuse isn't an excuse at all - it is a cop out. The primary rule of working in work orders or help desk tickets is this:

If it isn't in the ticket, it never happened. Just imagine that you were working on a problem for a customer and you resolved the problem and closed out the ticket without putting in your work notes. If the customer called back to complain they are still having the same problem, it would appear that you literally didn't do any work. Now imagine that you are working for a company that was being wrongfully sued by a customer due to a ticket you worked on. If you had proper documentation, you would have little to worry about. The second rule about documentation in help desk tickets is also very simple:

The ticket needs to tell a story. Work notes in a ticket need to be meaningful and somewhat easy to understand in case someone else reads your notes (especially your manager). Proper notes in help desk tickets is usually proof that you are working hard, as well as learning on the job. What you or your boss should be able to do is open a closed\resolved ticket and very easily be able to read out who did what in that ticket, as well as read the actual resolution of the ticket, almost like it is a story.

Leaving out the resolution in a ticket and just saying "Fixed" or "Done" doesn't count as a proper resolution to the story.

Make it count.Some facts about help desk tickets:* A help desk ticket can be as useful as a knowledge base article. There have been many times were I fixed a problem for a person and the issue came up 6 months later. I've been able to go back and look up how I fixed the problem, helping me get the customer back up and running quickly instead of "re-inventing the wheel" all over again.

* A help desk ticket can be used as a learning tool. For example, if you are on the help desk and had to escalate a ticket to another team, as long as the proper resolution was saved you can go back and read it further increasing your knowledge.

* A help desk ticket can be used in court. There was a time where a ticket I closed was used in court. Thanks to the documentation in the ticket, I helped save the company I worked for millions of dollars in fines. If the work notes were not there, I may have been fired.

* A help desk ticket can help improve your typing and communication skills. Writing good, even lengthy, documentation in a help desk ticket can be cumbersome and frustrating sometimes but the value it adds to your verbal and writing skills is priceless. With better documentation skills you can communicate what you want to say quickly, as well as help you choose proper words and descriptions to use.

Now, I know that I have heavily focused on documentation only in help desk tickets, but the same concepts outlined in this article applies to app bug reports (saying "It don't work" is a useless bug report), customer facing articles, and so forth. That is all that I have to say about documentation right now. I hope this convinces you that writing good documentation is important even for help desk tickets and that you will think twice about saying "I don't have the time to document" or "It takes too much of my time to do this".