There is nothing wrong with closing a ticket.
That’s what we’re there to do. If someone can’t work because something isn’t functioning properly, getting them back up and running is important.
What I’ve become more conscious of, though, is what happens when the same issue keeps coming back.
You can fix the individual ticket every time, but eventually you have to ask whether there is something behind the pattern.
A ticket can be fixed and the problem can still exist#
Imagine something breaks.
You investigate it, find the cause, apply a fix and the user is back up and running.
Good. The ticket can be closed.
Then the same thing happens again next week.
You fix it again.
Then it happens to someone else.
At that point, the individual ticket isn’t necessarily the most interesting part anymore. The pattern is.
I’ve become much more aware of this through working in support and studying service management. A recurring issue can be a sign that something else needs looking at.
It might be a configuration issue. It might be a process that isn’t working particularly well. It might be a documentation gap. It might be something owned by another team entirely.
You don’t necessarily know until you start looking at what is happening across the individual incidents.
The support queue can tell you more than you might think#
You don’t always need complicated reporting to notice that something keeps happening.
Sometimes you just recognise it.
You’ve seen the same application issue several times. You’ve answered the same question from different users. You’ve seen the same type of access problem come through again. You might even find yourself giving people the same workaround repeatedly.
Those things start to stand out when you’ve been working in support for a while.
When I notice something like that, I try to think about whether there is anything useful behind it.
If I’m answering the same question repeatedly, perhaps the information isn’t easy enough to find.
If I’m seeing the same type of issue on different devices, perhaps there is something worth raising.
If a process keeps creating confusion, perhaps the process or its documentation could be clearer.
That doesn’t mean every repeated ticket needs to turn into a project.
Sometimes there is nothing that needs changing.
But if you don’t notice the pattern in the first place, you never get the opportunity to decide whether it is worth doing anything about.
I’ve seen this with documentation#
One of the more obvious examples for me has been documentation.
I’ve worked on documentation where the information no longer matched the way the environment actually worked. In particular, I’ve been involved in reviewing Joiner, Mover and Leaver documentation and removing legacy steps that were no longer relevant.
The immediate task was updating the documentation.
But there is a bigger point behind that.
If the information people are relying on isn’t accurate, it can create problems further down the process. Someone following the document might waste time looking for something that no longer exists or take a route that doesn’t reflect how the environment is actually managed.
Updating the document doesn’t necessarily feel like a major technical achievement.
But it removes a source of confusion for the people who need to use it.
That’s the sort of small improvement I’ve started to appreciate more.
Sometimes the answer is simply better information#
I’ve also seen situations where the same information needs to be explained repeatedly.
A user asks a question.
Someone answers it.
Another user asks the same question a few days later.
Then someone else asks it again.
At some point, it’s worth asking whether the answer should exist somewhere that people can find it themselves.
That could mean a knowledge article, better documentation or simply making an existing piece of information easier to find.
The aim isn’t necessarily to stop people contacting support.
There will always be reasons for users to need help.
It’s more about making the information available when it is straightforward and repeatable, while allowing support time to be spent on the things that actually need investigation.
The same thinking applies to processes#
Documentation is only one example.
A process can work perfectly well most of the time and still have a part that regularly causes confusion.
Maybe information isn’t available when someone needs it.
Maybe an approval isn’t clear.
Maybe an escalation route isn’t obvious.
Maybe there is a step that made sense when the process was created but doesn’t really fit the environment anymore.
I’ve come across enough examples of this in my own work to have become more interested in what happens around the technical issue.
The technology might be working exactly as configured.
The difficulty might be in how the work moves around it.
That’s one of the things that studying service management has helped me recognise more clearly.
This is where continual improvement started making more sense to me#
Before studying ITIL, I probably would have thought of improvement as something much bigger.
A new system.
A major project.
A significant process change.
The more I’ve learned about continual improvement, the more I’ve appreciated that it can also be much smaller than that.
Changing a document because it is out of date is an improvement.
Making an escalation clearer is an improvement.
Spotting a recurring issue and raising it with the team responsible for the service is an improvement.
Making information easier to find can be an improvement.
None of these things are particularly dramatic on their own.
But if they make the service easier to support or reduce unnecessary work, they’re still useful.
I’m careful not to assume every repeat issue needs fixing#
There is a balance here.
I don’t think every recurring ticket is automatically evidence of a major underlying problem.
Sometimes things just happen.
Sometimes a user is new and needs the same information that everyone else needed when they started.
Sometimes a problem is unavoidable.
Sometimes the cost of changing something would be greater than the benefit.
That’s why I think the important part is noticing the pattern rather than immediately deciding that something must be changed.
Once you’ve noticed it, you can ask whether it is actually worth investigating.
That feels much more sensible to me than trying to turn every repeated issue into a continual improvement exercise.
What I’m trying to do differently#
When I see something recurring, I try to pause for a moment and think about what might be sitting behind it.
Is there something missing from the documentation?
Could the process be clearer?
Is there information that would help the next person?
Is this something the resolver team should know about?
Is there a wider pattern worth raising?
Sometimes I’ll find that there isn’t anything particularly useful to do.
That’s fine.
Other times, it might be worth making a small change or raising something with the team that owns the service.
The important thing for me is that the question gets asked.
Closing the ticket is still important#
I’m not against ticket closure.
A support team still needs to restore service, keep work moving and make sure issues are dealt with.
The point is that closing the ticket doesn’t always have to be the end of the thinking.
Sometimes the right thing to do is fix the issue, document what happened and move on.
Sometimes you fix it and notice that the same thing has happened several times before.
That’s when I think it’s worth looking a little further.
The individual ticket tells you what happened to one person at one point in time.
A pattern of tickets can tell you something about the service itself.
That’s one of the things I’ve started paying more attention to as I’ve gained experience in support and learned more about service management.
You don’t need to turn every incident into a major improvement project.
Sometimes you just need to notice that something keeps happening, ask why, and decide whether there is anything worth doing about it.