IT Help Desk Policy

Why do I need a helpdesk ticket policy?

Without a helpdesk ticket policy in place, employees with either be severely overutilizing the ticket system or underutilizing it. Either way, the company will be losing out on productivity and efficiency. Crafting a policy can be tricky so we put together some features that all helpdesk ticket policies should contain.

Support tickets should be deliverables, not questions

Questions should be asked either via instant message, email, or phone call. A support ticket should only be created in the event a deliverable is being saught. As such, the ticket policy needs to explain what the company considers to be a deliverable worthy of a ticket.

Here's an example that distinguishes between a deliverable request (aka support ticket) and a question (which should be emailed).

Email: Malcolm cannot figure out how to attach a document to a project in Super Easy CRM.

Ticket: Malcolm attempted to upload a document but received a message stating that the file was too large to upload. He would like the ability to upload a larger file.

Use a standardized naming convention

If users are given complete creative control over ticket names, the help desk team will receive all manner of inconsistent nonsense in the queue. A standard way of naming things makes it easier to identify the deliverable being requested and makes analytics much easier.

A sample naming convention could be: [ Impacted System/Hardaware ] [ Type of Issue ] [ Business Process/Department Impacted ]. With this, a ticket could be named 'Super Easy CRM - Unable to delete leads - Marketing'. Be sure that the titles aren't too wordy. Most ticketing software will allow users ample space in the description section to provide details.

Manage expectations by publishing turn around times

Everyone wants their problem fixed yesterday but that isn't always possible in most cases. As such, users will need to know the approximate times they can expect certain issues to be resolved.

Problems impacting mission critical resources like the company CRM or payroll system will likely be addressed immediately. Whereas issues with secondary monitors may take a few days to be addressed. Even if users are not happy with the turnaround time, they should at least know what it is.

Use a knowledge repository

Good ticket platforms like Super Easy Tickets allow users to create a knowledge repository. This is a great place to store how-to guides for fixing common problems that arise with the organization's tech resources. The information housed here can also be used to make end user troubleshooting guide.

If utilized properly, this repository will be more valuable than Google when it comes to resolving problems at the organization.

Severity determines priority

Priority must always be given to tickets that are generated due to business-critical resources failing. Even if there are other tickets ahead of them in the queue, problems that have the potential to cause widespread damage must be addressed first.

Change requests vs Support Tickets

Change requests and support tickets are similar in that most will require teams from IT to get involved. But this is where their similarities stop. Tickets can be initiated by any user at any time.

Change requests, however, should only come from those authorized to make changes to business processes and resources. In most cases, the change will require financial investment (in either monetary form or labor from staff). As such, someone with authority over the company's finances will need to

Make your ticket system work for you

Ticket systems contain all the company's technological problems and wishes for the future. If you are looking to increase efficiency, there is no better place to look than the organization's problem wiki! With a solid helpdesk policy user issues and requests will be resolved quicker and easier.

More Articles...