When Nobody
Owns IT

The Situation

The office has 18 staff, one IT contract vendor called in for major failures, and no internal system for anything smaller. When a printer jams or a workstation loses network access, the resolution path is: notice it, mention it to whoever is nearby, hope they mention it to someone with the credentials to fix it. Sometimes that chain works in an hour. Sometimes it takes three days.

I came in as a coordinator and watched this happen a dozen times before I started keeping notes. The notes revealed the problem.

The Problem with Reactive IT

Without a log, every issue looks like a one-off. The printer jammed again — but "again" exists only in people's heads, and people's heads disagree on how often "again" actually is. There's no timestamp, no resolution path, no record of whether the same machine failed in the same way two weeks ago.

The practical consequence: you can't prioritize by impact because you don't know impact. You can't make the case for replacing a failing printer because you can't demonstrate the load it creates. You can't identify whether a "training issue" is an isolated knowledge gap or a rollout that nobody fully understood.

Every systemic problem stays invisible because the only data you have is anecdotal.

The Approach

I built IT Logger — a lightweight internal ticket system designed to answer one question: where is IT time actually going?

The requirements were deliberately minimal. No ticket queue, no SLA tracking, no ITIL compliance. Just: who reported it, what department, what type of issue, what priority, when it was logged, and when it was closed. Everything runs locally — Python backend, Flask for the UI, SQLite for storage. No external dependencies, no licensing costs, no learning curve.

The harder problem was adoption. A system nobody uses is just documentation debt. I designed the intake form to take under two minutes, with a small dropdown set for issue type that forced categorization without creating friction. Staff could self-report or I could log on their behalf. Either path worked.

What the Data Showed

After the first month of logging, the distribution was clear enough to act on. Below is a sample from the ticket log — names anonymized, issue types cleaned up but representative of the real breakdown.

The Pattern

Printer issues account for the largest single category of IT load in the office, and they concentrate almost entirely in the Legal Assistants department — a group with high document throughput and shared hardware.

What looked like random friction was a systemic gap. The same two printers appeared repeatedly. One was past its rated duty cycle. The other was a network printer with a configuration that disconnected under a specific set of conditions — conditions that occurred daily.

The training issues told a parallel story. They weren't random knowledge gaps. They clustered around a document management software rollout that had happened six months earlier without a structured handoff. People had built their own workarounds, and those workarounds didn't match the system's design.

The Outcome

Visibility. That's the whole outcome, and it's enough.

Before the triage system, leadership had a vague sense that IT issues were a time sink. After a month of logging, they had a dashboard: issue volume by type, by department, by priority, by resolution time. Printer-related issues were consuming roughly 40% of logged IT time. The two highest-volume machines were both past their recommended replacement window.

One printer was replaced. A 90-minute training refresher was scheduled for the document management system. Two recurring issue types dropped off the log entirely. The contract IT vendor now gets a summary report before each visit instead of starting every call from scratch.