I work in IT. A big part of my job is using a ticketing system to document and track what I do on a daily basis. If you work in an office, you might have had to ask the IT person for help. They might have given you a response along the lines of, “Did you make a ticket?” Maybe you got salty about it because you just told them there was a problem to their face. Maybe you even told them what the problem was right then and there. “Can’t the IT person just help me instead of making me do this extra step?” The thing is, they can, and they would probably love to, but there are two reasons why you would need to create tickets.

1. In the event that you aren’t available right that second, the issue will at least be known to the IT folks, and they can work with you to schedule a time to help.
2. Tickets are how the IT department provides a paper trail to management of what they do and where they go.

“Wait. Why can’t the IT technician just make a ticket for the thing I asked about?” We can, but it doesn’t quite hold the same weight as a ticket that was created by the actual person affected. If someone has persistent issues with their equipment, having a paper trail helps to prove that the person needs a new computer to their supervisor. Not to mention, depending on how busy the day is, the technician may not have time to actually document everything they have done in the order they did it.

Tickets are an integral part of any IT technician’s day. But there is a prominent issue in every IT department with the use of ticketing systems: quotas. The day ticket quotas are implemented is the day the quality of the IT department goes downhill. I have seen it happen many times before. While I understand why some metrics are in place (ensure tickets are resolved in a timely manner, and which systems are having the most problems), having a hard quota usually backfires in a frustrating and cyclical way.

Inevitably, this leads to frustration and resentment from the technicians, especially the ones who were trying to get their numbers up honestly. I can’t tell you how many times I have heard about people stealing tickets or making tickets for rerouting tickets.

If you’re curious about how a ticket can be stolen, most ticketing systems use the following “states” of progress: In Progress, Resolved, and Closed. When a ticket is Resolved, it can still be edited just in case something changes. A few days later, the ticket is Closed, and can’t be edited. Technicians that want to steal a ticket can edit the ticket, assigning it to themselves before it closes. But there is normally a record of who edits what in the ticket notes.

How those infractions are dealt with varies, but usually, the artificially inflating of tickets gets ignored. The numbers are going up; who cares how it’s happening?

The end users care when their computers aren’t fixed. Technicians care when they need to dedicate chunks of their day to writing notes and closing tickets. And management does fuck all until the right person (usually in c-suite) complains. That is when management cares how the numbers got so high.

In my opinion, an IT help desk shouldn’t be quantified based purely on numbers. It’s very easy to inflate those numbers and this causes the work done to be reflected inaccurately. Taking small audits of the week’s work and urging end users to submit their own tickets would help middle management better examine the work being done and how to improve.

…But I’m just a mid-level technician. What I think doesn’t matter in the eyes of Quotavion, God of Metrics, Lord of Numbers, and Destroyer of Morale (PRAISE BE HIS QUANTITY).