Having worked on a service desk for the majority of my IT career, there have definitely been some changes over time on how tickets are handled. While the process has improved greatly, there are still some things that could make obtaining service easier and better for all parties. There are three main parts to a service desk. The way (1) tickets are entered into the system, (2) how tickets are assigned to technicians, and finally (3) the process the technician uses to complete the ticket.
1. Submitting Tickets
In the past, a customer would call the help desk for an issue. The technician answering the phone was also the person that would take care of the call, and they would enter the ticket into the system. This method was highly inefficient since a technician could get stuck on a lengthy call, while other clients would remain on hold waiting for their turn with the tech. If the help desk was overwhelmed, some techs could be tempted to take another call and try to multitask the current call. Tickets wouldn't be generated, and documentation of client issues would suffer.
Today, most MSPs offer a few different methods to obtain support. A customer could email their issue, call, or submit a ticket through an online ticketing system. When calling for support, instead of waiting on hold for their turn, a less technical receptionist or tier 1 support personnel can field the call and enter the ticket. If it is a quick issue, they may be able to handle it themselves. If not, they can enter the ticket into one repository for a higher level tech to respond to.
In the future, I can see even more possibilities for obtaining support, where all roads lead to a single ticketing system. Customers are most comfortable requesting support with a platform they utilize the most. If they love to talk on the phone, they will call; if they prefer email they will send one; if they are on Facebook most of the day, they would prefer to submit something through Facebook messenger. I believe the more options you give your customers, the happier they will be. Whether it's from Twitter or a Text, all tickets would end up in the same location and responses to the tickets, although entered into the ticketing system, would appear to the customer on their chosen platform.
2. Assigning Tickets
In the past, tickets would be assigned to whoever was available to answer the call at the moment. Even when one tech might be better equipped to handle that particular call. This is extremely inefficient especially when training new technicians. Something that one tech knows how to fix immediately off the top of their head can take another tech hours to figure out. Knowledge bases helped a great deal with this scenario, but that still requires research on the part of the tech that doesn't know the issue from previous experience.
Today, since tickets are all deposited into the same location, techs can grab the next ticket in the queue as they complete their previous ticket, or they can be manually assigned by a manager or another person based on skill set. While this is definitely more efficient than randomly assigning tickets as the calls come in, some techs could get overwhelmed if multiple tickets come in with the same types of issues. This method also requires an additional person's time figuring out who would be best to handle the ticket.
In the future, tickets can be assigned through AI technology. As the ticket enters the system the program evaluates the category of the issue and matches it with the technicians who are certified in that area. The system would then determine who has the availability and automatically assign the ticket to that person. This not only ensures that tickets are routed to the appropriate skill set, but it also frees up the person who was responsible for assigning tickets to handle other tasks.
3. Managing Tickets
In the past, once you answer the call, you are responsible for entering the ticket and marking it "in progress." There would be several fields you would need to fill out before you even begin tackling the issue at hand. During the call, you are also responsible for taking notes on what steps you are taking to solve the issue. Eventually, once you fix the problem, you marked it as completed and moved on to the next call. I admit that I was terrible at this process. I liked fixing issues. I hated the documentation.
Today, things are pretty similar to how they have always been for moving a ticket through the process. As tickets are assigned to you, you take them one at a time until your queue becomes empty (hopefully). One main problem now is issues that are unable to be resolved right away. I hated tickets that I couldn't close because of waiting for a response from the client or waiting for a call back from a vendor. There are really quite a few reasons for being unable to complete a ticket before you need to move on to the next one.
In the future, I would like more automation throughout the ticket handling process. Since tickets would be coming into the system through multiple pipelines, there would need to be a protocol for matching the ticket with the client requesting it. The system would then also look for keywords throughout the ticket to assign the ticket to different categories and subcategories, such as email-Office 365, or software-accounting. Doing this matching automatically will take the burden off of the technicians managing the ticket. There will be a lot less information for technicians to enter at the beginning, allowing support pros to get right to the meat of the problem.
Often a ticket will come in that has so few details the technician has to take the time to respond just to ask additional follow up questions. Canned responses would help tremendously. If the ticket doesn't have enough details to match it with the appropriate categories, the system would respond with some follow up questions automatically such as "What program are you using when the issue occurs?" "How many times a day does the issue occur?" etc.
Once the technician starts to fix the problem, there should also be system entries built in that are associated with the issue type. The technician could type up their own troubleshooting steps, or enter standard troubleshooting steps already written. For example, if an issue comes in with a printer that isn't working, the built in troubleshooting entries could read "Had user unplug the printer from the power source." Again, making the process of documentation much easier for the technician.
Tickets that are in a waiting state should have reminders automatically generated and built in. As I change the status of a ticket to waiting, a popup should appear asking me when I would like to be reminded to follow up on the ticket. If I am waiting for a client response I could set the date to 24 hours from now to remind me to call the client and attempt to obtain the response again. If I am waiting on a part, I could set the reminder for the date the part is supposed to arrive. This will help to make sure tickets don't slip through the cracks and become forgotten.
A long queue with tickets that are waiting mixed with tickets that are yet to be responded to can overwhelm the technician. The service desk should have filter tabs to toggle between tickets that are waiting to begin, tickets that are in progress, and tickets that are waiting for a customer or other type of response or hardware piece to come in. I hate seeing tickets in the queue that can't be tackled right away. It makes it look cluttered and hard to view tickets that can be handled.
Putting these types of tickets in different areas, that are both easily accessible will help technicians really understand what their workload looks like.
