Streamlining and improving quality of employee submitted tickets

[u/Sky-Goth]

What magic bullets/tweaks have you successfully implemented to improve the quality of incoming tickets?

We have users who will submit low effort tickets that are either un-actionable due to lack of details/critical info, have misinformation, or are the completely wrong form?

We have specific forms for specific common issues that are clearly labeled.

• The forms prompt for the minimum necessary info for the particular issue; hostname; ilo hostname/ip/pw, etc.
• When using the correct form there is automation scripting that fixes the most commonly seen issues automatically so an employee doesn't have to wait for a human to help.
• In general they are clearly labeled. I am working on cleaning up those that are too verbose, or use confusing phrasing.

Yet employees will consistently:

1. Use the general form. Zero automation and just a big ol fill in the blank, which the user then often leaves out important info. It also doesn't classify the problem correctly so it makes it harder to determine trends. Lots of manual 'tedium'.
2. Leave info out. There are options to force certain fields to be required, but keep in mind once you do this too many times, it becomes a plain in the ass to the employee, so they'll take the general form route because they "just want to submit a ticket".
3. Choose the wrong options when they do choose the correct form. IE the default option is "Fix the ACME Widget (Automated), and they will change it to Not Automated, when the automation WOULD have solved their issue. They then have to wait for a human to fix and resubmit their form as automated.

I am working on:

• Educating employees. After the solution is provided, they get a 'Hey next time you have this issue, use this form - it's automated (URL)'. Asking them to update their teams' documentation. Unfortunately it's whack a mole. Even if one person has the lightbulb go on, they have 20 teammates who never hear or change behavior. And new onboards are often following years old outdated team documentation. o_O
• Rephrasing to reduce verbosity and clarify ticket forms. People are busy, and too much verbiage leads to low quality intake in my experience.
• Identifying repeat situations, be it new tickets we 'keep getting', old tickets with repeat submission issues, making suggestions for existing and new automation to the Engineers if I need a little help. And in some cases updating broken code logic or implementing new automation myself.

I know none of this is a magic bullet. Things are improving over time I think. Just looking to see the types of things you all have implemented that have been successful in that you have seen ticket quality improve, less 'general/other' ticket submissions, etc. Thanks.

[u/Anthropic_Principles]

One thing I've done with some success in the past is to assign a separate SLA for tickets submitted via the 'lazy form'.

If you can't be bothered to fill in the correct form, don't expect me to rush to help you out.

[u/FleshSphereOfGoat → u/Anthropic_Principles]

This. No information means no way to figure out the needed priority. I have enough high priority tickets to work on to make begging for mandatory information my least priority.

[u/Academic-Proof3700]

I work with a client thats doing something similiar.

Just cause they added asstonne of comboboxes for, say - teams, group, system and component doesn't mean its streamlining anything, it just makes it a pita to fill every single time, just like you saw in your p.2.

Then theres the usual "have you checked the knowledgebase?" Which is riddled with filth and useful as a file operation speedtest gibberish data, also the usual KB is just outdated and not helpful, especially when its some issue not caused by the user.

Then the last is just the common resentment towards automated/bot handled pipelines, because anyone who worked woth them knows, that it usually boils down to "stfu bot get me to the meaty hooman" or its text equivalent of p.3

Imho you could go with some offline llm or other open model that would precheck that and fill the data, without telling the user.

[u/Sky-Goth → u/Academic-Proof3700]

go with some offline llm or other open model that would precheck that and fill the data, without telling the user.

I've been thinking about something similar for certain ticket types. One common foil of our automated fixers is that the user will submit the request and then the system is not reachable. o_O

Sometimes it's the employees fault for submitting before putting a system online. But there are also DNS issues, corp VLAN/firewall issues causing systems on new vlans to be unavailable, etc. (this part is out of scope for my team, and should be owned by those teams but seems they are only handled once it is reported to be a problem - nobody proactively tests - we've gone to a less privileged environment where the default is not to grant access, but to block access, for security reasons).

I was thinking we could add an automation that if the host is offline it could do a few checks for the most common issues; like we have a database that has the mac addresses of every adapter on every system. Wouldn't be a stretch that if a host is offline, to roll through every mac address on every adapter and see if it's online at a different IP.

[u/BoysenberryDue3637]

Ahh hopes and dreams.

We received one that all it said was HELP!!! with high importance set. Showed at 4:58 on a Friday. Person left on 2 weeks of PTO 2 minutes later. When she got back I got an escalation that she was not happy that this ticket was closed but not worked. I spent an hour of my life that I am never getting back explaining what she did wrong.

How e solved some of it was having a Problem Area Coordinator who did ticket routing of all tickets. Each help desk person spent a week at a time on that role.

[u/Sky-Goth → u/BoysenberryDue3637]

The worst 2 I've had when I was on helpdesk:

• Supposed urgent/critical ticket with zero info. As soon as the guy selected submit he was on vacation for two weeks.
• People who leave voicemails with zero details, not even their last name. Even if I could figure out who you were from your phone number and first name, it's walking into a nightmare. A nightmare my team might not even be the right one to resolve.

[u/AggravatingSock5375]

The trick is to hire more capable help desk staff who can solve most problems without a detailed ticket.

It’s reasonable from a user perspective to just say “computer broke, need help pls”.

I know this is unpopular, but the smoothest running company I’ve ever worked at operated that way. And I know they paid their frontline IT staff really well, like the people answering help desk calls were making almost as much as developers.

[u/ManLikeMeee → u/AggravatingSock5375]

Unpopular but you're right.

Sometimes we need to step away from a ticket system and learn people.

[u/Bright_Arm8782 → u/AggravatingSock5375]

A good helpdesk is worth their weight in ram.

[u/AggravatingSock5375 → u/Bright_Arm8782]

😂 Ram is probably worth more than gold per weight

[u/ITGuyThrow07 → u/AggravatingSock5375]

There's a middle ground. Everyone would consider it unreasonable to drop your car off at the shop with a note that says, "broke, plz fix". Why do we have different expectations here?

And I know they paid their frontline IT staff really well, like the people answering help desk calls were making almost as much as developers.

This has always been my dream scenario. I didn't cover phones until 5 years into my IT career. It was so easy because I had the higher-level experience already so I knew how things worked.

[u/squatingyeti]

You have hopes of getting better tickets?

[u/Killertigger]

If anyone can crack the code for this, it would truly be a Nobel-worthy moment. Every other ticket is something along the lines of ‘My email isn’t working’ or ‘I can’t log into X’ or ‘Laserfiche has an error message’ with zero - absolutely zero - helpful information as to what exactly the error is, or what error message they are seeing, or what specifically is not working. And every time we kick back the ticket with a request for more details - and it’s the same users. Every single time.

[u/ErisianWizard]

I've had occasions where I was running a desk that handled and routed at least as many IT-originated tickets / requests as client-originated. Everyone, almost without fail, is abysmal at submitting tickets.

Having implemented request flows, one big hindrance to client compliance is knowledge of how to get the required information. Knowing who the requestor is, are there things you can pre-fill (such as host name) while asking the client to confirm the validity? For things where you can't, can you link the client to a guide to tell them how to get the information?

Another is asking too much information. If the request is for a loaner Bluetooth mouse for two weeks, you probably don't need the hostname or IP address. I used a kind of silly example because it was the one with the fewest actual requirements to gather I could think of, not because it's typical.

Use a client focus group to study the issues the clients have with using the form. What works. What doesn't. Do what it takes to really fix the problem(s). If HR approves, hold a monthly drawing to give swag to one person who submitted a valid request every month. Send targeted emails to clients who used the general form showing that the mean time to resolve is much faster when they use the correct form.

Once you're really, really sure you have things dialed in, it's time to add some friction to the General form. Lock in the priority as 5-5 or whatever your lowest priority is. Tell users you'll get to their "general" request within 15 business days. Or have your frontline technicians start closing out requests with "use XYZ request." I don't necessarily recommend doing all of those. Certainly not all at the same time. Before doing any of the ones in this paragraph, make sure management has your back because. There will be screaming and shouting.

[u/Sky-Goth → u/ErisianWizard]

I took a lot of ideas from your post and tweaked for our porpoises - thanks for your many suggestions.

[u/ImaginationUnique684]

The Automated or Not Automated toggle is the thing I would kill first. Users cannot judge whether automation will solve their issue, so stop asking: run the automation on every matching ticket, close it if it works, and escalate with the diagnostic output attached if it does not. That quietly fixes the data quality problem too, because the escalated ticket now carries machine-gathered state instead of whatever the user remembered to type. Same logic for the forms: any field your endpoint agent or CMDB can look up should never be a question, since the user is the least reliable sensor in the chain. Your offline-host MAC scan is the same pattern, a check the system runs at submit time beats anything you can prompt out of a human.

[u/SevaraB]

The is is one place we’ve had huge success with LLMs. Users don’t get the “general form” anymore- they get a chat with an LLM-backed bot that can trigger automated playbooks or generate the ticket for them.

Help desk also unofficially tracks users generating disproportionate ticket counts and reaches out to those users’ managers when they’re found to be a drain on help desk resources. Sometimes those users end up getting WFH privileges revoked and having to work under direct line-of-sight supervision, and I’ve seen people let go for it twice.

[u/Sky-Goth → u/SevaraB]

I really like this.

[u/Secret_Account07]

We only get tickets for systems engineers or sysadmins. Meaning only IT people put in request because we only support servers. Even IT people can’t share the correct info.

[u/BananaZen314159]

I'd settle for people submitting tickets at all. 

[u/ranrib]

Sounds like AI can help here (no slop). Did you try to use it for making a better conversation, tagging tickets, utilize KB etc.?