"The Internet Is Broken" - The Ticket That Changed How I Think About IT Support

Ticket subject line: "The internet is broken."

No description. No steps to reproduce. Just vibes.

I braced for the worst. Rogue router? DNS meltdown? Entire infrastructure deciding it was done?

Nope.

Her account had been disabled for two days. She'd been staring at a "your account is disabled" screen since Monday. She assumed it was a company-wide outage. Didn't want to bother anyone.

Two. Days.

Four minutes to fix. One AD attribute. Done.

Then she apologized for submitting the ticket.

Said she wasn't sure it was "a real IT problem."

That One Hit Different

Somewhere along the way, someone made her feel like her problem wasn't worth asking about. So she sat quietly for 48 hours, locked out, not wanting to be a burden.

The technical fix was the easy part. One attribute in Active Directory, flip it, account re-enabled, done. I could do that in my sleep.

But the fact that she waited two full days? That's not a technical problem. That's a culture problem. And it's one that shows up in IT organizations more than we want to admit.

Why Users Don't Call

When I think about the users who don't submit tickets, the pattern is almost always the same:

They've been dismissed before. Someone once told them their issue wasn't important, or they got the vibe that they were wasting IT's time. Once is enough to learn the lesson.
They don't know what's "real." Most users can't tell the difference between a network outage, a disabled account, and a browser cache issue. If they can't name the problem, they assume it's not worth reporting.
They've internalized the hierarchy. IT is busy. IT has "real" problems to deal with. Their little issue? Probably not important enough.
The process itself is a barrier. If submitting a ticket requires navigating a portal, filling out 12 fields, and choosing from a dropdown of categories they don't understand, they'll just suffer in silence.

Every silent user is a signal. Not of a minor inconvenience, but of a support system that isn't reaching the people it's supposed to serve.

The Hidden Cost

Two days of lost productivity. That's what this ticket really cost. Not the four minutes it took me to fix it - the 48 hours she spent working around it, or not working at all.

Multiply that across an organization. How many people right now are sitting with a problem they're not reporting? How much productivity is being lost to silence?

In higher ed, where I support 30+ institutions, I see this pattern at scale. Faculty who can't access their LMS the week before finals. Staff who can't get into ServiceNow to process payroll. Students who assume the portal is "just slow" when their account is actually locked.

These aren't edge cases. They're the quiet majority of IT failures - the ones that never become tickets because the user gave up first.

Being the Kind of IT Pro People Actually Call

The harder part, and honestly the more important part, is being the kind of IT professional people actually feel safe calling. That means:

Never making someone feel stupid for asking. There's no such thing as a dumb ticket. If it's blocking their work, it's real.
Following up after the fix. "Is everything working now?" takes five seconds and builds more trust than any SLA metric.
Explaining what happened in plain language. "Your account was disabled" is more helpful than "I toggled the userAccountControl attribute." People remember how you made them feel, not your technical vocabulary.
Making the ticket process as frictionless as possible. If someone can email, chat, or call and get help, they will. If they have to navigate a portal designed by committee, they won't.

The technical fix is always the easy part. The hard part is building the kind of relationship with your users where they actually tell you something is broken before they've been suffering for two days.

What I Took From This

Metrics matter. FCR rates, CSAT scores, ticket volume - I track all of it. But the metric I think about most is the one I can't measure: the tickets that never get submitted.

Every time I close a ticket, I'm also trying to make it easier for the next person to open one. Because the worst outcome in IT support isn't a hard problem. It's a user who needed help and didn't ask.

This post is based on real incidents from my work supporting 30+ higher education institutions. Details have been generalized to protect privacy.