[Work Sample] A Ticketing System Review

As part of the interview process for an IT Support position at a local charter school, I was asked to do a review of their ticketing system. While I was not ultimately offered the position, they did inform me that they implemented some of my suggestions. This post is an overview of my process and recommendations, as well as some thoughts about this type of assessment in the hiring process.

The Ask

The interviewer sent me a .csv file with every single ticket submitted by faculty, staff, and admin over the 2024-2025 school year. This was about 430 tickets. Their current system consists of one Google Form, which is not uncommon for relatively small organizations that don't necessarily need a more robust, full-featured ticketing system. In short, they seemed to be seeking a way to reduce the number of tickets categorized as "other" and the number of tickets classified as "urgent." They also asked for some suggestions for changes to their form, or even proposals for a whole new ticketing system.

I do want to take a moment to discuss the nature of this assessment. This ask gave me pause for several reasons, but as I wanted to remain in consideration for the position, I agreed to complete it. My first issue is that this is pretty plainly a Data Analysis kind of assessment for an IT Support role. I am not a data analyst and am not well versed in statistics. The employer explicitly allowed the use of AI tools in generating graphs, and due to time constraints I opted to use them rather than try to relearn how to make the graphs I wanted with Python. A more general issue is that this assessment amounts to free labor for the school. I kind of experienced the worst-case scenario: my ideas were used without any compensation, and I was not offered the position in the end. Lastly, it was a bit of a haphazard assessment. The instructions were somewhat vague, but more damningly, the tickets that I was sent included email addresses and phone numbers of all the staff members who submitted tickets.

With all that being said, let's talk about the tickets.

The "Other" Tickets

The following graph plainly shows that most tickets that are submitted are classified as "Other." This is a clear problem for people receiving these tickets. Categories help IT staff triage and plan tickets and resolutions; lumping everything together makes it much harder to do this. Furthermore, upon reading the descriptions of many of these issues, they actually did fit into another category. One contributing factor to this issue is lengthy and unclear category names. "Major device malfunction such as: will not turn on, will not charge, etc." is a rather long-winded way of saying "Hardware issues." There were also categories that were very similar to one another. This may have been a case of the categories being changed over the course of the year, then showing up as different categories in the .csv file. "Unable to access a needed website (Go Guardian- It will say this on the Student Screen)" is awfully similar to "Unable to access a needed website (ZScaler- It will say this on your device)", and both of those are somewhat similar to "Unable to log into a G Suite Account (Lost password, Email address issues, etc.)." It's easy to imagine a busy teacher only skimming these options and selecting the wrong one, or simply clicking "Other."

My Solution: Get rid of "Other"

No "Other," no problem, right? If only it were so simple.

My proposal regarding the "Other" issue was to make the categories more succinct and more comprehensive by making a category and subcategory system. As I didn't want to do too much free labor for them, I provided an abridged sample of what this might look like. The big categories would include things like Hardware, Software, Requests, and On/Offboarding. Within each category, there could be several subcategories that cover the majority of common issues. Under Hardware, you might have Broken/Missing Equipment, Projector/Display issues, Printer/Scanner/Document Camera issues, Power/Charging issues, etc. Under the Software category, you would have subcategories such as Email problems, Password forgotten/reset, Email issue, Multifactor Authentication, etc. Hopefully the picture is becoming clear. While you can't list every type of issue, by having a fairly comprehensive list and asking people to pick the item that best fits their issue, you put a little more pressure on the users to find what fits their issue.

Staff Training

The assessment also asked for ideas regarding staff training and Professional Development. Anyone who worked in a school knows that Professional Development sessions happen constantly. I lucked out in this area, because when I was a teacher, we had PD sessions that would work perfectly in this situation. My school system was transitioning from Google Classroom to Canvas, and we had several sessions to train us for the change.

In my proposal, I suggested a PD on the ticketing system (highly discouraging the use of "Other") and on common troubleshooting techniques. Many issues can be solved by power cycling devices. Even more issues can be solved with a quick Google search. I also suggested designating some staff "Power Users." These would be tech savvy staff members who could act as a step 0 of troubleshooting. Before submitting a ticket, these staff members could be available to see if there's a quick and immediate fix to the issue. Finally, I suggested training on some best practices for staff devices. This would include things like avoiding phishing and scams, avoiding installing unnecessary or unknown software, using strong passwords, and proper care of hardware.

Wrapup

There were some other odds and ends in both the ask and my response, but I have covered what I think were the suggestions that were put into practice. On the one hand, I feel that I provided some very pragmatic and reasonable options for this school, but on the other I am frustrated to have done this work for them for free. It's certainly not the first time I've been in this situation, and I'm sure it will not be the last.

Published on: July 19, 2025

Last updated: July 24, 2025

Back to Blog