Reducing repeat tickets

A helpdesk that resolves the same ten issues every week is working hard and achieving nothing durable. Each ticket is handled correctly, closed within target, and the cause remains untouched.

Finding and fixing those causes is the highest-return work a support function can do, and it does not require new tooling. It requires looking at the tickets you already have in a different way.

Find the repeats

Start with the last three to six months of tickets and group them. Not by the category field, which is usually chosen quickly and inconsistently, but by what actually happened.

Two practical approaches:

Group by resolution text. Tickets resolved with similar actions are usually the same underlying problem regardless of how they were categorised or described.

Group by affected system or application. Then read a sample from each group. Patterns become obvious quickly.

For each group, calculate volume, total time spent, and how many distinct users are affected. Rank by total time. This list is almost always shorter and more concentrated than people expect: a handful of causes typically accounts for a large share of the workload.

The causes behind common repeats

Password and access problems

Usually the largest single category. The causes vary and each has a different fix.

Frequent expiry policies drive volume directly; current guidance from most authorities favours longer-lived passwords with strong authentication over frequent forced rotation. Account lockouts often come from a saved credential on a phone or a mapped drive continuing to present an old password after a change: worth identifying specifically, because users cannot diagnose it themselves.

Self-service reset removes a large share of the volume, but only if enrolment is high. Enrolment during onboarding, made mandatory, is what makes it work.

One application generating disproportionate tickets

Read twenty of them. The cause is usually one of: a genuine defect that needs the vendor, a workflow that is confusing enough that people get it wrong, missing training after a change, or a performance problem people report as errors.

Each needs a different owner, and none of them is "handle the tickets faster".

Printing

Reliably in the top five and reliably under-analysed. Common causes include drivers that fail after updates, queues on a server nobody monitors, devices that drop off the network, and users defaulting to a device in another building.

Often a small infrastructure change (updating the deployment method, monitoring the print service, correcting default assignments) removes most of the volume permanently.

Onboarding and access requests

High volume and highly repetitive. The cause is almost always that access is requested ad hoc rather than derived from a role. Someone joins, gets what their predecessor had, then raises three more tickets over the following month for things that were missed.

Defining a standard access set per role, applied at onboarding, converts several tickets into none.

Connectivity at a specific site or for a specific group

Tickets described as "internet slow" or "system down" that cluster around one location. Usually a genuine infrastructure problem that nobody has correlated because each ticket was handled individually.

Grouping by location is worth doing routinely for this reason alone.

"How do I" questions

Not faults, and frequently the largest category after access. High volume means the interface is unclear, the change was not communicated, or documentation is absent or unfindable.

Documentation only helps if people can find it. A knowledge base nobody searches is not a fix.

Turning analysis into fixes

Take the top three, not the top twenty. A list of twenty improvements gets none done. Three get done.

Give each a named owner and a date. These are projects, not tickets, and they need to be tracked as such. Left in the support queue, they lose every time to something urgent.

Measure before and after. Ticket volume for that specific cause, in the month before and the three months after. Without this you cannot tell whether the fix worked, and you will not be given time for the next one.

Repeat quarterly. The top three changes as you fix things. What was fourth becomes first.

Deflection versus prevention

Two different things, often conflated.

Deflection means the user resolves it themselves: self-service password reset, a knowledge base article, a chatbot. The problem still occurs; it costs less to handle.

Prevention means the problem stops happening. The driver is fixed, the workflow is corrected, the access is granted at onboarding.

Prevention is better and harder. Deflection is worth doing for problems that cannot be prevented, but it should not be mistaken for solving them. A support function proud of its deflection rate for password resets has optimised the handling of a problem it could have reduced.

Protecting the time

The recurring obstacle is that improvement work competes with the queue and always loses.

The only thing that reliably works is protecting the time explicitly: a defined portion of someone's week, or a named person on improvement rather than the queue, on a rotation. Whatever the mechanism, it needs to be a commitment rather than an intention, because there is always another ticket.

Organisations that make this commitment find the queue shrinks and the time becomes easier to protect. Organisations that do not find the queue grows and the time becomes impossible to find. Which of those you are in is decided by whether the first three fixes ever get done.