Skip to content

YamasakiRhys/ticket-lifecycle

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

3 Commits
 
 

Repository files navigation

osTicket logo

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)
  • Remote Desktop
  • Internet Information Services (IIS)

Operating Systems Used

  • Windows 10 Pro (22H2) at least 2vCPUs, 8GB RAM

Ticket Lifecycle Stages

  • Intake
  • Assignment and Communication
  • Working the Issue
  • Resolution

Working through Tickets

In this project, we'll simulate some helpdesk tickets and work through them to resolution. Before we start anything, make sure the Maintenance department is deleted as tickets somehow get routed here. Login as an admin, hover over agents (big tab) and click on departments. Check the Maintenance department, click More then delete. Now we can begin.

Go to http://localhost/osTicket and open a new ticket. Let's create a ticket about a user named Karen and is reporting that their company's mobile/online banking system is down.


user portal

ticket 1 created

We will try and access this ticket with the John Doe user we created in the Post-Installation project. Looks like we can assign this ticket to others can set the SLA. Online banking being down for a company needs to be looked at urgently so we can set the SLA to Sev-A. Although John could probably resolve this ticket since he's part of the support team, it is more appropriate to assign this to the Online Banking team. Then Jane from the Online Banking team and work the ticket to resolution and close the ticket.


john accessing ticket jane closing ticket

Let's say in another example a ticket is created saying that the Adobe software update is broken in the accounting department. John picks up the ticket and reads through it. The ticket is a bit vague and doesn't specify whether this issue affects the entire department or whether just a few users are affected. We also don't know if the update is due to a faulty patch or Adobe itself. It's best to call the customer up in these cases and verify some details before working through the ticket. However, in this case we'll assume that only a few users were affected. In this case, we set the SLA to Sev-C as it has minor impact on the business as a whole and can respond to the user to try restarting the computers and see if it works. If this actions resolves the problem, we can then close the ticket.

closed 2nd ticket

Now for one final example, let's say the CFO of a company is unable to turn on his laptop. This can be quite serious if the CFO is unable to access critical documents for the business. However the issue may not be as bad as it seems depending on how fast the laptop can be fixed for eg. bad battery (easy fix) vs failed inverter (harder fix). Let's set the priority level to emergency for now and say we may change this once we get more information.


closed 3rd ticket


After getting more information, it turns out the charger was broken so this is a relatively easy fix, we can set the SLA to Sev-B and once we get someone to find a new charger and verify that the laptop can be powered on, we can close the ticket.

Working through tickets takes a bit digging but asking the right questions and knowing who to escalate the ticket to can help immensely.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published