If you've ever worked in IT support, you know that the ticketing process is about the only thing that keeps the idiots at bay, spamming support directly with the most inane issues.

You may be quite adept with computer machines, but work a few days in IT support, and you'll understand why there is a ticketing process.

I worked in IT. I had two techniques for people with inane questions -- number one, acknowledge their request and tell them they are in the queue, then follow up the next day asking if they still need help. Usually they had either figured it out or asked a friend by then. Number two was to just teach them where to figure it out for themselves as a ticket update, and then close it out the next day.

If they actually came by, we would just help them and then file a ticket for them to track our work.

There is no reason to force people to file tickets before you help them.

They absolutely should force people to file tickets before helping them, if the IT department is understaffed (which is an entirely different problem).

Understaffed or not, if you want to be perceived as a cost center that gets in the way, sure require tickets to do any work.

If you want to be seen as a force multiplier for the business that helps people get work done quicker, then actually help people and do the record keeping on your time, not theirs.

Yeah so you have people doing primary business work[1] doing the work of support people[1].

[1] Primary business, the shit the makes the money. [2] Support, shit that is done only to support #1.

Yes and no.

I think at least a part of that problem is that the usual support ticketing process infantilizes users. If you call in and the first question is along the lines of "is it plugged in? have you tried turning it off and on again?" then of course your next ticket will take that level of questioning into account. And call in even for a switched off monitor next time. Because they wouldn't ask that question if that wasn't their job to fix, right?

Also, of course users will try and fail to fix issues themselves. They should be applauded for the intent and empowered to be successful next time (if possible). Instead they are usually berated for failing and breaking stuff along the way. Which leads to the usual sheepish "I didn't do anything, I didn't touch it, it always was broken like that".

Of course there is a minimum number of imbeciles. But most people can be educated and empowered, so they do behave like adults when dealing with problems. "The system" just has to give them that chance.

I agree entirely, and thank you for providing a more thoughtful analysis.

My experience: when tech support are (very) competent, (very) patient, (very) people-loving people, left to do their work in a low-turnover place with no ticket system, it is (very much) more efficient in the short-term, and absolute magic in the long-term.

It's been a long time since I've worked in a support-adjacent role, but IME it was always less about "keep[ing] the idiots at bay" and more about covering the ass of the help desk.

Things that take a support person 5 minutes are the bulk of the job, and those things have to be accounted for. If you slack on that, people will make their own determination of what constitutes a "simple" issue, you'll wind up with most of the issues the help desk solves not showing up in their metrics at all, and it looks to the higher-ups like the support people are just lazy.

In the places I've worked, support always _loved_ the "idiots" because their problems were simple. Being able to resolve a ticket by putting in a single screw, telling the person to turn on their computer, or initiating a password reset was the easiest kind of win you could get.

Maybe, but I’ve noticed there’s a big difference in IT departments who will open a ticket for you/do it together, vs. ones who will only confirm that they won’t talk to you until you go back to your desk to open a ticket. I started my career in IT and have worked in both kinds. Some IT departments really have an us vs. the world mentality.

Needing tickets is just reality. Companies see IT as a cost center so they need to justify their existence, which they do with tickets. Creating tickets itself doesn’t need to be adversarial, but the process can be used to try to get people to leave you alone (or at least make it onerous to do so) if that’s what you want.

When you see this, this is almost always a management vs IT issue, and you're just suffering the fallout of it.

With this said, if the management demands IT has tickets, this is something that must be reiterated to every employee. "If you go to IT without a ticket, they cannot and will not help you"

While you as an employee may not have been adversarial, it is extremely common for angry users demand help right now for their life ending issue that's more important than anything else in the world! You know, they need that PDF printed right now... While you happen to be working on the server that's keeping 100 other people from working.

I was the IT support tech who would input tickets for people instead of insisting they call/walk-in with a ticket. The result was management gaslighting my ticket numbers as artificially inflated and being highly critical of my work. Wound up on a PIP.

(Realistically, everyone outside the department knew me by name. They would call and ask for me any number of ways including outright lying. They'd tell me I was the sole source of any problems getting solved! "Everyone else in that department can't do a thing.")

Please just put tickets in before you reach out to IT and have the number ready. Print it off, even.

Around here, I as a support guy could theoretically open a ticket. But I'm shielded by policy, so users cannot call me directly. Instead they will reach a call center (same for emails) where tickets are written down, classified and assigned. It usually takes an hour from initial call until I even see the ticket.

Not really. The process is what keeps IT guys from being overloaded by 5 people competing who is going to push them harder so that their issue take priority. Or simultaneously screaming at them when they will be done. And it prevents them from drowning in issues reported by multiple channels (mail, chat and phone) spending time trying to organize them into single queue or figuring one which mail has additional information to what was said in which phone call.

Process like jira tickers are literally the thing that improves quality of life of non-idle IT worker.

Your example is actually example of the above. You want your screw to be treated as #1 priority right now. Allowing the technician to finish what he was doing and only then get to your request is not fast enough. But, with that being the norm, work becomes jumping between tasks and trying to finish three things parallelly. It becomes impossible or super ineffective to finish larger tasks.

It's been my experience that IT management want to see metrics and dashboards for everything. The want to be able to plan, allocate resources, and justify purchases and staff.

How many of these did we do, how many of those, how long did it take to close this type of ticket, etc. So while the technical people could fix things on the spot, they are not allowed to due to the demand for metrics and tracking.

I can see both sides of the debate, but there needs to be a good balance. We can get stuff done and provide metrics without too much overhead.

They wants metrics for everything but surprisingly they always refuse to measure the time people are using to fill those tickets and time spend in meetings everybody dislike.

> how long did it take to close this type of ticket

About ten times as long as wihout using the ticket system and involving middle management

This was my experience too when working in IT for a little bit. Many were happy to just sort problems out there and then but I could clearly see they were being reprimanded by HR for fixing issues without tickets. However, there was one callous and jaded printer technician who basically wouldn't even speak to someone unless they had a ticket opened.

Why would HR care whether an IT support staff was following the IT team's ticket process? HR is there to recruit, help hire, help fire, explain benefits packages and vacation policy, sometimes address workplace personnel conflicts, sometimes help teams budget salaries, and so on. IT's policies are made and enforced by IT management/leadership. I've never heard of any company where HR had any input whatsoever into an internal engineering or support team's processes.

Different organizations have different structures and different distributions of responsibility. I could absolutely see some places having HR be the place where metric-based policies originated, even for the IT team—and even over the objections of the head of IT. Especially if it's a place where the head of HR is a VP/C-suite, but the head of IT is just a Director. (Shockingly, not everywhere sees IT as being as important as other divisions.)

lol - you'd think that HR would be there for these things in most organisations, but in many they are petty bureaucrats. HR are not your friends.

They are not your friends, but also they very rarely have even ability to care about internal processes of various departments. As in, your boss may need HR to supervise as he is trying to take disciplinary action against what he perceives as you not following internal rules.

But HR themselves wont check whether you do jira tickets or whether you do something else. For HR, IT is one of many departments with own set of rules that HR does not get to decide.

Real fun when your review is all about number of tickets closed. You get bitter quick.

I expect I could game that system pretty effectively.

That’s the depressing part. You gotta be an ass to game it

Ticket count dictates headcount, work that isn't tracked with some kind of elaborate process isn't actually work nowadays.

Bureaucracy and paper pushers always get in the way of doing actual work.

It's called metrics or kpi.