If you work in IT long enough, you hear it on autopilot:

“Just put in a ticket.”
“Can you open a Jira for that?”
“Throw it in ServiceNow and we’ll take a look.”

On paper, that sentence is supposed to signal maturity.
We have process. We track work. We are grown ups here.

In reality, half the time it translates to:

“I want this to be someone else’s problem and I never want to think about it again.”

The result is predictable.
You end up with:

• 20 ways to ask for the same thing
• Forms no one understands
• “Urgent” tickets with zero context
• Random work getting done through Slack and email anyway

I’ve been on the receiving end of that mess.
I’ve also helped clean it up.

This post is about what I learned trying to turn “just put in a ticket” from a threat into something that actually helps people.

Step 1: Bad Tickets Are A Design Problem, Not A User Problem

It’s easy to blame users.

“They never fill out the form.”
“They always pick the wrong category.”
“They put ‘help’ in the description and call it a day.”

Cool. And who gave them a 34-field form with five different “Other” options and three priority dropdowns that don’t mean anything?

That was us.

If your ServiceNow or Jira intake is confusing, people are going to:

• Pick the first thing that looks close
• Slam everything in “High priority”
• Bypass the system entirely and DM you on Teams or Slack

That’s not because they’re lazy. It’s because the system is telling them, loudly, “I was not designed for actual humans.”

The moment I stopped treating bad tickets as a user problem and started treating them as a design problem, things got a lot easier.

The question shifted from
“How do I make people behave?”
to
“How do I make the path of least resistance also be the correct one?”

Step 2: Give Work Types Names That Humans Actually Use

One of the first things I had to untangle was the categories themselves.

You see stuff like:

• “Request – Misc”
• “Change – Standard”
• “Project – General”
• “Other”

Users do not think in those terms. They think in:

• “I’m new here and nothing works yet.”
• “I’m leaving and I need my stuff turned off.”
• “My app is broken.”
• “I need access to X.”
• “We’re changing something for a client.”

So instead of trying to teach everyone ITIL vocabulary, I started renaming things to match how people already talk.

Examples:

• “New Hire – Accounts, Email, Laptop”
• “Offboarding – Remove Access And Collect Equipment”
• “Access Request – Add / Change / Remove”
• “Change Request – System / Process / Client Facing”
• “Bug / Outage – Something Is Broken”

Under the hood, sure, that might still map to Incident / Request / Change / Problem with all the proper flags. But on the screen the user sees, it needs to read like English, not a certification exam.

If someone can’t tell which form to use in three seconds, you’ve already lost them.

Step 3: Design Intake Forms That Force The Right Context

Once the names made sense, the next level was the form itself.

Most intake forms fail in two ways:

1. They ask for too much random crap up front.
2. They don’t force the important information you actually need.

So for each request type, I asked:

• What do I absolutely need to know before anyone can work on this?
• What can we infer from the system instead of making them type it?
• What belongs in a follow-up question instead of the first screen?

Example: Access request.

Bad version:

• Big open text box: “Describe what you need.”
• Optional field: “System”
• Optional field: “Team / Dept”
• Priority dropdown no one understands

Better version:

• “What do you need?” (radio buttons)
  • Add access
  • Remove access
  • Change access
• “For which system?” (dropdown of actual systems, not acronyms only IT knows)
• “Who is this for?” (user picker, default to the person filling it out)
• “What should this person be able to do?” (short text, with examples shown under the field)
• “Who approves this?” (manager / data owner selector or auto-filled based on rules)

For onboarding:

• Start date (with a big note: “We need at least X days’ notice”)
• Job title / role
• Manager
• Location (remote / office / which city)
• Laptop type (with company standard options surfaced first)

If you design forms around the decisions you actually have to make, the tickets that come out the other side are usable the first time. You spend less time chasing people for basics and more time actually doing the work.

Step 4: Stop Letting Everything Live In “General IT” Hell

Another pattern I saw:

One giant queue. Everything goes in there. Everyone hates it.

• Security changes in the same queue as “please fix my mouse.”
• Client-facing project work sitting next to “install this font.”
• Dev work for ServiceNow or integrations buried under printer issues.

That’s how you end up with important stuff stalled because it looks exactly like everything else on the board.

The fix is boring but necessary: slice the work along real boundaries.

Instead of one “IT Request,” split it into things like:

• “IT Support – Something Is Broken Or Not Working”
• “IT Change – We Are Changing A System Or Standard”
• “ServiceNow / Dev – New Workflow, Automation, Or Integration”
• “Security – Access, VPN, MFA, Or Policy Questions”

Under that, you can still route assignments and use one team, but the intake makes it obvious what bucket something belongs to.

It also makes reporting sane. If leadership asks “How much time are we spending on security vs general support?” you have an actual answer instead of vibes.

Step 5: Tie Tickets To Change And History So Knowledge Doesn’t Die In Chat

One of my biggest frustrations early on was watching real work happen in Slack, Teams, or email, with tickets being treated as a checkbox.

• “Opened ticket”
• 40 messages in Teams
• “Resolved” with a one-line note: “fixed it”

Cool. In three months, no one remembers what “fixed it” was. Then the same issue comes back and you’re starting from zero.

Part of cleaning up our processes was forcing more of the real story back into the system:

• Link change requests to the actual implementation tickets
• Link bugs to the change that caused them
• Paste summaries of key Slack threads into the ticket before closing
• Write real resolution notes, not just “done” or “see logs”

Format that helped:

• What the user saw
• What we found
• What we changed
• What we would watch next time

You don’t have to paste the entire Teams novel, but you should at least leave a breadcrumb trail.

Future you will thank you when you are staring at an incident at 2 a.m. wondering, “Haven’t we seen this before?”

Step 6: Automation Should Move Work Forward, Not Just Send More Emails

ServiceNow, Jira, whatever you use, all have automation. Most teams only use it to send more notifications no one reads.

You can do better than that even with simple rules.

Useful automations I like:

• Auto-route tickets based on request type so they land with the right person by default
• Auto-set priority based on impact questions (“Is this blocking all users or just you?”)
• Auto-add checklists or subtasks for repeatable flows like onboarding / offboarding
• Auto-comment with next steps for the user (“We got your request. Here’s what happens next and what we might ask you for.”)

The test is simple:

If the automation went away tomorrow, would anyone besides email servers notice?

If not, it’s noise, not value.

Automations should be doing actual work for you: assigning, tagging, reminding, creating child tasks, enforcing approvals. Not just blasting out “ticket updated” spam.

Step 7: Change The Culture From “Throw It Over The Wall” To “Design The Flow”

Tools matter. But culture matters more.

“Just put in a ticket” becomes toxic when it means:

“I don’t want to think about this. Let the system eat it.”

The healthier version sounds more like:

“Let’s capture this properly so it gets to the right people, in the right order, with the right info.”

That’s a mindset shift.

For IT, it means:

• Pushing back (nicely) when someone wants to bypass the process “just this once”
• Fixing the intake when you see patterns of confusion instead of blaming users
• Treating workflows like living products you can iterate on, not one-and-done projects

For everyone else, it means:

• Understanding that “open a ticket” is not a punishment, it is how we make sure work doesn’t vanish
• Giving enough context that the first person who sees it can actually help
• Using the tool as the source of truth, not just a graveyard for IDs you paste in Slack

Closing This Out

ServiceNow, Jira, and all the other alphabet soup tools can absolutely be black holes where work goes to die.

They can also be the backbone of a clean, predictable flow where:

• People know how to ask for help
• IT knows what’s on fire and what can wait
• Leadership can see where time and effort actually go

The difference is not the logo on the login screen. It’s whether anyone has taken ownership of the design.

If you are the one sitting in the middle of the chaos, buried in tickets, you are also the one in the best position to fix it.

Rename the things.
Simplify the forms.
Slice the queues.
Capture the history.
Automate the boring parts.

Bit by bit, “just put in a ticket” stops sounding like a threat and starts sounding like what it was supposed to be in the first place:

“Let’s do this the right way.”

‍