School technology staff should follow these best practices when working in your help desk ticketing system.
Help desk ticketing systems are a great tool to streamline the daily management of school help desk tickets from teachers, students, and school administrators. They also hold a goldmine of data that you can use to drive decisions to provide the best technology possible for staff and students.
To make use of this data, you need to establish clear, standardized procedures that your technology staff can execute. Creating consistencies in processes and ticket data will allow you to identify SLA compliance, product issues, technician efficiency, and much more.
Whether your tickets are being created by technicians or your help desk product allows the end user to create their own ticket to initiate the support process, it can become a challenge if information isn’t documented consistently. Teach your techs to create clear, standardized summaries of tickets for easier reporting.
Summaries should be short (no more than 10 words) and have very specific references to the problem. (i.e. “Printer will not print” vs “User is in Excel and is unable to print a report, but able to print another report “or “Blue Screen of Death Error” vs “Computer will not boot due to Blue Screen of Death Error”). In the second example, you can see that we don’t need to know the computer won’t boot if there is a blue screen, the non-booting is implied. You will see that when your summaries are short and specific, searches for specific problems become easy and your reports tend to be much more organized and professional.
If you allow end users to input their own tickets, make sure you have a team member who can review the summaries and make necessary changes to help them adhere to the standard. You can also have the technician who picks up the ticket make the necessary changes if they have access to do so.
Technicians who are recording their work need to understand that clear and concise information is the goal when logging their work on a help desk ticket. The work log is the place for detail!
The work log should be a play-by-play that explains what the technician did to solve the issue (even if what he/she did was NOT what fixed the issue). Notes should be very detailed and explain clearly what happened, including screen shots of errors and links to resources.
Notes in the log need to be made at the same time or at the very least on the same day the work was done. Real-time information is important to the end user, and to anyone in the support group who is answering the phones and giving the status of tickets to end users.
The work log should have a standard format that all technicians understand. For example, if your system does not time/date stamp comments in the log – the technician should note it. Will the newest entries be at the TOP of the log or at the BOTTOM? How it is laid out is not as important as making sure everyone knows and understands the layout. This makes it much easier for a technician who picks up where another technician left off to understand the troubleshooting steps that have already been tried.
The final entry in the work log will in most cases also be what goes into the “resolution” field in the ticket. Resolutions should also be detailed as this content can be turned into knowledge base articles in many help desk ticketing systems. It is a good idea to refrain from using terminology that would not be understood by your end users when notating the resolution to their problem. Remember, a big part of providing technical support is to empower end users to understand and solve their own issues if at all possible.
Having clear processes in place for escalation keeps things moving smoothly and doesn’t allow for tickets to be put aside because the work is boring or too hard. Here are some examples of a standardized escalation policy.
New: Tickets in “New” status will be assigned within four hours of receipt. If you allow your technicians to choose their own tickets from a bucket of new tickets, some of them could fall through the cracks. Give one person (or make it a rotating responsibility) the task of assigning tickets that have not been self-assigned within the time limit. This policy will ensure that every ticket is assigned to a technician within an acceptable time limit.
Assigned: Tickets in “Assigned” status will be opened within 24 hours of the assignment.
Open: Tickets in “Open” status will be resolved or reassigned to the next level within 72 hours of receipt.
Tickets having an overall time of 10 work days in the “Open” status, regardless of escalation schedule will be reported to the supervisor for review.
The technical support environment is ever changing. Standards can become outdated very quickly. Hard and fast rules are rarely effective in the long run. It is important to meet with staff on a regular basis and review what is working and what isn’t. It is also good to give some flexibility for technicians to make judgement calls when needed – as long as things are discussed as a team later, everyone will still be on the same page and your help desk ticketing system will be the tool you expected.