The usual way an IT automation project starts: someone counts the queue, picks the biggest category, and automates it. Six months later the same number of tickets arrive and get closed faster. The team is not less busy. The budget conversation next year is harder, not easier, because the obvious win has been spent.

The reason is that ticket categories describe what was asked, and the thing worth automating is why it was asked.

Sort by cause, not by category

Take one month of closed tickets — that is enough, and it is data you already have. Put every one into exactly one of four buckets.

1. Should be self-service. The user could have done it themselves if a door had been unlocked. Password resets, group membership, licence assignment, a shared mailbox. High volume, low judgement, and each one costs a context switch on both sides.

2. Should never have been raised. Something upstream is broken and this ticket is the symptom. A weekly export that fails every Monday. A form that times out for anyone on the VPN. Fifty tickets a month from one cause, filed under five different categories, which is precisely why nobody has noticed they are one thing.

3. Real work, badly plumbed. A genuine request that takes twenty minutes, of which eighteen are copying between the ticket, the directory, the HR system and the asset register. The work is legitimate; the typing is not.

4. Actual expertise. Somebody’s judgement was required. This is what you are paying an IT team for, and it should be most of what they do.

What the sort tells you

The proportions matter more than the totals.

If bucket 1 dominates, you have an access-and-permissions design problem, and the fix is a self-service path with approval — not a faster human.

If bucket 2 has any weight at all, stop and fix the cause first. Automating the response to a recurring failure is the most expensive possible way to live with it: you have now built and must maintain a machine whose only job is to keep a broken thing tolerable.

If bucket 3 dominates, that is the one AI and workflow automation are genuinely for. The judgement stays with your team; the copying, routing and document generation stop being manual.

If bucket 4 dominates, your queue is healthy and your problem is capacity, not tooling. Nobody will sell you that answer, so consider it a free one.

Where agents actually fit

The word “agent” is doing a lot of unearned work at the moment, so plainly: an agent is useful where a task has many small steps, clear success criteria, and a safe stopping point.

Joiner-mover-leaver is the canonical example. Twelve steps across four systems, every one of them checkable, and a natural halt if something looks wrong — which then becomes a ticket for a person, with the first eleven steps already done.

The counter-example is anything where the stopping point is unclear. If “done” requires knowing whether this exception is acceptable for this customer, that decision belongs to a person and always will. Automating up to the decision and stopping is the win. Automating through it is how organisations lose trust in automation permanently.

The leaver problem

Worth naming on its own, because almost every organisation has it and almost none of them report it as a ticket.

Someone leaves. The accounts are disabled eventually. The licences are reclaimed at some point. The laptop comes back when someone remembers. None of this generates a ticket, because the person who would have raised it has gone.

It is invisible in a queue-based analysis, it is an audit finding waiting to happen, and it is the single cleanest automation in IT: one approved trigger, a fixed sequence, a complete log.

What to do this week

Export last month’s tickets. Put each into one of the four buckets. Count them.

If you would like a second pair of eyes on the result, send us the shape of it — categories and volumes, no content needed. We will tell you which bucket is really yours, including the case where the answer is that you do not need us.