osTicket - Ticket Lifecycle: Intake Through Resolution

This tutorial outlines the lifecycle of a ticket from intake to resolution within the open-source help desk ticketing system osTicket.

Environments and Technologies Used

• Microsoft Azure (Virtual Machines/Compute)
• Remote Desktop
• Internet Information Services (IIS)

Operating Systems Used

• Windows 10 Pro (22H2)

Ticket Lifcycle Stages

• Stage 1
• Stage 2
• Stage 3
• Stage 4

(Images going from left to right)

Installation Steps

Stage 1

After the previous parts of our lab, we are finally ready to simulate a day to day example of a help desk professional and now we are going to make up some tickts as a user with common issues that may occur within their company, business, etc. We do this through Support Center and create a few tickets and put them into their respective category giving us (the ones doing the lab) to be able to differentiate which department and who is responsible for taking care of these tickets.

Stage 2

So we've created our list of tickets and have them all ready to be taken care of. Usually a manager or maybe a lead will assign such tickets, but as our lab is an example/practice for real world issues we will be the 'manager' and assign them to our users or our admin. So, this ticket was assigned to Jane Doe (the system administrator) and the issue was that 'most of her department was having issues with their current tablets' and their question was when are they going to get a hardware refresh? After seeing this, we can determine that this a low priority as it falls under gereral inquiry, which wouldn't severely impact business in this case. Also, for the SLA Plan we could put this as SEV C and this is our longest timeframe to complete this ticket showing us that this again is not our top priority. However, we solved this problem by replying that they are scheduled for a refresh in Q1 and we let them know as well that they could email us if they have any questions.

Stage 3

For the next ticket, Ken was having an issue with the adobe reader not working for the entire account department. Looking through the ticket we can deduce that this is a SEV B in our SLA Plan, which means that we have 4 hours to resolve it on a 24/7 timeframe. We come to this conclusion with the information given inferring that this isn't a top level threat nor a low level one, but instead just right in the middle. Another note, since these tickets are assigned to our different workers we simply log out and log back in as the 'worker' or in this case John Doe and resolve the ticket as them. So logged in as John, we can have back and forth conversations via messaging if we need more information to solve the issue and by doing our own research as well. Furthermore, if its an issue that requires someone with more experience we can also ressign the ticket to a different person in our IT group.

Step 4

For our last ticket, we have our critical or high priority ticket that requires quick to immediate attention. This is our SEV A SLA Plan, which simply means that the ticket needs to be solved as soon as possible and is on a 1 hour 24/7 timeframe for our example. We notice that the help topic is 'Business Critical Outage' and again this lets us know the severity of the issue that we are dealing with. So, we solved this ticket by simply transferring it over to our system admin department as this particular issue was not within our field, but we would let Ken (one who submitted the ticket) know what is going on and explain to him why as well just so there is no miscommunication and so that he is aware of what's happening.