Why Are We Still Building Ticket Factories?

Most IT organizations measure themselves by how fast they close tickets. Almost none measure themselves by how many tickets never needed to exist in the first place. That difference is the whole problem.

The ticket factory problem

Walk into almost any IT operations review and you'll hear the same metrics: average time to resolve, first-contact resolution rate, backlog size, SLA compliance. Every one of them describes how efficiently the organization processes tickets. None of them ask whether the ticket should have been created at all.

That's the ticket factory model. Demand arrives, gets triaged, gets routed, gets worked, gets closed. The factory is judged on throughput. Faster is better. More automation is better. A bigger, more efficient assembly line is the goal — even though the product coming off that line is, by definition, a failure that already happened somewhere in the business.

Nobody designed IT operations to work this way on purpose. It's what happens when an organization optimizes the step it can measure easily — resolution — instead of the step that actually matters: whether the underlying condition that generated the ticket gets removed.

Speed is not the same as value

AI is now being layered onto this model at scale. Copilots draft responses. Agents triage and route. Chatbots deflect simple requests. All of it makes the factory faster. Very little of it makes the factory smaller.

That distinction matters more than it sounds. A ticket factory that resolves issues in minutes instead of hours is still a ticket factory. It still assumes that a steady stream of tickets is the natural state of IT operations, and that the job of technology is to process that stream more efficiently. If anything, a faster factory can mask the problem for longer, because the pain of slow resolution — the thing that usually forces leadership to ask harder questions — disappears before anyone asks why the demand exists.

The enterprises that get real value from AI in operations are not the ones that automated their ticket queue. They're the ones that used AI to understand why the queue exists, and then made large parts of it disappear.

Eliminate first. Automate second.

This is the core discipline: before you automate a category of work, ask whether it should exist at all. Most operational tickets fall into one of three buckets. Some are avoidable — caused by a process gap, a bad default, a missing piece of self-service that forces a human request where none should be needed. Some are resolvable by the platform itself, if the platform is instrumented well enough to see the problem coming and act on it automatically. Only what's left after those two categories are addressed is a legitimate candidate for automation.

Run automation first, without asking that question, and you get a well-oiled machine for doing the wrong thing faster. Run elimination first, and automation becomes a much smaller — and much more valuable — problem to solve.

What this looks like in practice

In practice, eliminating ticket demand starts with treating tickets as data about the business, not just workload for IT. Every recurring ticket type is evidence of a gap somewhere: in the platform, in the process, or in what users are able to do for themselves. Categorize before you automate. Separate administrative demand — access requests, password resets, routine provisioning — from operational demand — incidents, degraded performance, capacity constraints. They fail for different reasons and they get eliminated in different ways.

For administrative demand, the fix is usually self-service and better defaults: if a request is predictable and low-risk, a human should never have had to file a ticket for it. For operational demand, the fix is platform intelligence: instrumenting systems well enough to catch the precursors to an incident before it becomes one, so the ticket is prevented rather than resolved. Only after both of those levers have been pulled does it make sense to ask what automation should handle for whatever demand remains.

Organizations that do this in order — eliminate, then resolve at the platform level, then automate — don't just get a faster ticket factory. They get a smaller one. Fewer tickets, not just faster tickets, is the actual measure of operational maturity.

The real question

The question worth asking in every operations review isn't "how fast are we closing tickets?" It's "why does this category of ticket exist, and what would it take to make it stop existing?" That's a harder question. It's also the only one that leads to an operating model built around outcomes instead of one built around throughput.