Read Between the Lines to Prevent IT Tickets

Throughout my career as an editor, I am the great breaker of webpages. I find new and exciting ways to make strange things show up for the public to unwittingly see. Consider me the chaos monkey of tech.

Case in point: On one webpage I managed, someone had helpfully pointed out to me that I had a pair of articles showing up that were both titled “test-article”. I had been testing out a few things in the back end of that page, and seemingly had forgotten to erase the results.

But as I went into the back end to delete the offending articles, I had a feeling that I had done this before. Staring at the screen, I grew sure of it.

I deleted the articles. I went back to the screen. Still there.

I published the whole folder again. Still there.

I filed a ticket about the problem. Soon, I was talking with a helpful member of the IT team. It turns out there was a box to check - “publish sub-items” - when republishing the whole year’s folder, and that is the only way to truly delete a published article. Now, I am not smart enough to know why that worked, but I do know that it worked - the “test-articles” were gone.

I mentioned to the IT person that this didn’t seem the most intuitive process, and that people might forget to check this box. The IT person said I could call on them anytime if I did. I thanked them, and the chat closed.

And yet, I again had a weird sense of deja vu. I looked back at my tickets, and discovered that I had filed this ticket before. And the answer that time was, again, that you had to check that box to make the deleted article go away. I had even mentioned at the time that this box seemed non-intuitive to check.

We had recreated a ticket cycle from the past. No one is necessarily to blame for this - in the interval since the first ticket, the IT team had been busy doing magical things to improve the webpage, and I was too busy to stop after the first ticket to ask for an improvement to the process. And yet, an opportunity got missed, and that meant that an error showed up on the page, and that the IT team had to tackle a second, duplicate ticket.

There is never such a thing as an ideal work process for an IT department - too many things break that need fixing, and too many updates need to be made. However, it might be beneficial for everyone involved if there were a more formal way to read between the lines of real-time client feedback about why the ticket was filed, and to analyze whether there are opportunities to improve user experience based on that feedback.

Ideally, the end user will take the initiative to advocate for a change with a formal ticket, but IT support and service shouldn’t solely rely on that.. More often than not, however, the end user may feel chagrined that they even needed help, and don’t want to trouble the IT department more than they already have. Therefore, the root cause of their concern may come out as an aside or a mumble. If IT doesn’t create a process to allow team members to regularly review and capture what was said, opportunities can be lost.

Of course, to do this requires ensuring that your KPIs are best aligned for customer service and not simply for speed of ticket resolution. The business case for this approach, however, can best be described as ticket prevention. While that may be harder to quantify, it may pay off in the long run.

Craig Idlebrook is an editor for Informa Tech.