If you work in IT, you’ll certainly be working with a ticketing system. In this video, you’ll learn about entering tickets, managing categories, escalating events, and much more.
If you work in IT, you’ve almost certainly worked with some type of ticketing system. Ticketing systems provide us with a way to document issues that may be occurring and then assign those issues to someone who may be able to resolve the problem. At that point, we could create reports that show us how many tickets we were able to process, and how many of those issues we were able to resolve.
It’s very common for this ticketing process to begin and end with the help desk. They take the calls from the users, they triage or determine exactly what issues go first and which goes second, they determine the best next step to resolve these particular issues, and then they assign the ticket to the appropriate person and monitor until that ticket is resolved. Although there are many different types of ticketing systems, they’re all very similar in their basic function and structure.
In this video, we’ll look at some of those processes and see how it may be applied to a particular ticketing system. So let’s say that a user calls you and says, I’m having a problem logging in to the intranet. Well now we need to create a ticket so that we can track this problem from the very beginning of the issue all the way until it’s finished through the resolution. We need to determine the user’s name.
And if there is a device that we need to deal with, we need to get specifics on what device may be having the problem. And then we need to detail what the exact description is for this issue. It’s during this initial information gathering phase where we provide context to the problem. We need to determine where the root cause of this issue might lie, and we need to assign the ticket to someone who can resolve those types of issues.
If someone’s calling in saying that an entire network is down, we can categorize that problem as a network issue. We can assign a severity to this problem. In this case, it would probably be a very urgent issue. And then we can determine if we need to escalate this problem. And in the case of outages or downtime, we probably would want to make sure the network team was aware of this as soon as possible.
One of the keys in the help desk is providing information in a very clear and concise manner. The initial problem description needs to be detailed and to the point. If you’re the person who’s adding more information to the ticket, you need to make sure that it is concise. And the final resolution needs to be very straightforward so the next person who has this problem will understand what you did to resolve it.
Before we can create this ticket, we need to understand who’s having the problem. So we need to document who the user is that’s calling or sending a message with this particular issue. It’s very common for this list of users to auto populate itself based on a database of users that already exists in the organization. For example, if you’re running Microsoft’s Active Directory, all of the usernames and information about every user is stored in the Active Directory database, and that database can be queried to auto populate the service ticket.
If this ticket is being submitted electronically either through a web front end or an email, the name can be auto populated within the support ticket. And although it’s very convenient to have all of these fields auto populated, you might want to confirm one last time that the username associated with the ticket was the person who actually submitted it from the beginning. On my computer, I’m running a demo version of the JIRA service management help desk.
And from here we can add new tickets, look at tickets that are already in the database, and make changes to anything that might be there. If someone calls with a problem, we can create a ticket by clicking the button at the top. The first option we have is to define the type of task that we have. This could be to fix an account problem, someone may need a new mobile device, and there are other categories in here as well.
Let’s say that someone’s having a problem logging in to the intranet so they’re having an account problem. We’ll choose that option. And then it requests a summary of this particular issue. And we can put details in here that can define what the user is telling us about this account issue. For this ticket, we put in a very simple and very concise explanation that this user is unable to log in to intranet 01.
In this ticketing system, we can then add the components that are affected by this problem. It could be a VPN server or cloud storage services. But since this problem deals mainly with the intranet, we will choose the intranet as the component. If the user has forwarded a screenshot or any other type of attachment, we could also add that attachment to the support ticket. And if there are other details that might help with this problem, such as specific error codes or other messages that the user is providing to us, we can add that under the description.
And in this help desk we would then add the reporter’s name. I’m not the one calling in. The person calling in is Daniel. So I’ll type in Dan, and I’ll add Daniel to the name of the person who’s calling about this particular problem. If I happen to have all of the rights and permissions to be able to solve this intranet login problem, I could assign this ticket to myself. But you could also click Assignee and put a different person’s name and who would be forwarded this ticket and then they would be responsible for solving the problem.
I’m going to assign this to myself, and then I could choose a priority anywhere between lowest and highest. Right now, the default is set to medium and that would work fine for this particular ticket. Once we’re done with these details, we can click the Create button, and now we’ve created a ticket for this specific problem. During that ticket creation process, there were many fields on the screen that allowed us to provide more detail about this specific problem.
For example, we could have added device information if this problem was specific to this user’s machine, or maybe they had a bad printer, or perhaps they were in a conference room and had a projector that wasn’t working. If this ticket was more involved than someone who simply needed a password reset or an account reset, we would need to provide more detail underneath the description option. This is the part of the ticket that most people will go to find out more details.
And if this is a very complex problem, there will be a lot more information that continues to be added to the description field. Once we have all of this information in the ticket, we now need to make a decision on how to move this ticket to the next step. If this is something we can solve ourselves, we can resolve the issue and immediately close the ticket out. But if this is a network outage, we need to assign this ticket to the network team and we need to give it the priorities that they’ll be able to address this problem as quickly as possible.
For example, we may receive a call where someone is unable to process customer payments. That’s obviously a very significant problem. So in the description field, we’ll specify that payments and transactions team is reporting multiple emails and calls from customers with rejected payments after multiple attempts. This gives the person receiving the ticket exactly the information they need to know to be able to perform the next troubleshooting step.
Most help desk software allows you to set a category for a specific issue. So if somebody’s having a password problem, you might have a category just for password issues. Or if somebody needs to make a change to a system or a network, that can be categorized as a change request. This is a very broad description of how these problems might be categorized. And normally, most issues will already fit into one of these predefined categories.
On our help desk, we had a number of different categories available. And on the left hand menu we can sort or filter by these categories. We have categories for service requests, incidents, problems, changes, and post incident review. So if you wanted to just see the service requests, we can click on that and view the open service requests. And you can see we’ve now filtered by just service requests, and the service requests that we just created is down here at the bottom of this list.
If you wanted to look at a different category, we can go back to our project and let’s choose problems. Now when we filter by the open problems, we can see there are a different group of issues. For example, recurring Sydney VPN access is having errors in the last 60 days, and then we’re getting a trend of higher counts with send mail 404 errors. This broad category allows us to focus in on specific types of problems, and we can then assign those problems to the appropriate people.
We then need to assign a severity to this ticket. It’s very common to see severity such as low, medium, high, or critical. If this is a password reset problem, it may be a low or medium severity. But if someone’s calling in saying that an entire network segment is down, we may want to qualify this as a critical severity. Obviously, the people who will be assigned these tickets will be able to see these severities so they know which ticket to address first, which to address second, and so on.
If you’re working in the help desk, you may not know everyone who works in IT or know exactly who a ticket should be assigned to. But there might be groups of people that you can easily escalate to, and inside the help desk software you can choose those escalation levels. The majority of issues that are presented to the help desk can usually be resolved on the first call.
But there may be issues that are very complex, that involve many different teams in the organization, and may require changes to be able to resolve this problem.
So it’s important to create progress notes, so that anyone who’s reading through this ticket can understand exactly what occurred in the past and what the plans are in the future to resolve this issue. This can quickly become a very large description, especially if it’s a very complex problem, so it’s important to keep that progress information very concise in the ticket. And as more information is discovered and potential fixes are proposed, we can continue to add that information to the support ticket.
And of course when the problem is resolved, you don’t simply close the ticket and move to the next one. You need to document exactly the process that was followed so the next person who has this problem will know exactly how it was resolved originally and can perform the same resolution again. Here’s a ticket that describes where multiple problems can be experienced by different people and multiple parts of the organization may be involved in resolving the issue.
This ticket is a VPN outage network difficulties experience. And the description says remote office employees in the Sydney region are reporting VPN access issues since before close of business yesterday. If we scroll down a bit, you can see there are a number of linked issues, the first one being that there have been recurring Sydney VPN access errors in the last 60 days.
This means if someone does call in regarding a problem relating to the VPN in Sydney, that it could possibly be related to that particular issue. There also might be other tickets that people are calling in and saying they’re unable to log in to the VPN. And once those tickets are assigned to the appropriate folks, they may realize that the VPN needs to be upgraded. And so they have submitted a ticket that says the Sydney VPN needs to be upgraded, and they’re requesting approval as discussed.
You can see how this help desk software allows all parts of the organization to be able to recognize when problems are occurring and work together to resolve those issues.