Help Desk ticketing systems are a way to track open problems and measure how long it takes to resolve those problems. Service Level Agreements or SLAs are the motivation behind this. How long is the ticket open? How long did it take to close? What are the severities of the problems encountered? And how can that data be used to improve response to future problems?
What if trouble tickets could be used to identify trends and allow the Help Desk to take care of problems before they happen? By setting up your Help Desk ticketing system and managing the data input by support teams, a picture of the environment can be built. This picture can then be used to more efficiently manage your support team and address issues before they arrive. This moves support toward a proactive model and can redue the time required to resolve common issues.
Ticketing Systems
There are many products available to automate the Help Desk. These products all point to databases to store current and historical data. Most also contain a front end that can be customized to the customer’s desires.
During the installation phase, Help Desk managers design the system to allow for the collection of data that can be used for reporting and proactive measures. This data is collected and organized in common fields that make up a conceptual framework corresponding to the resources being reported against. These frameworks are often referred to as ‘schemas.’
Some of the most-used schemas are:
- Username
- Hardware/Software
- Priority Level
- Notes
- Resolution
By creating sub-categories to these common schemas, managers can collect useful information with minimal action from whoever is opening the ticket.
Examples
Let’s take a closer look at the Hardware/Software category above. Say a network router is generating log messages stating that route engine mastership is changing intermittently. The network engineer sees the logs, opens a trouble ticket, and investigates the issue. Seeing no issue that can easily be discerned, the mastership is switched back during a maintenance window and the case is closed. A few weeks later the log messages are seen again.
The only way to see an issue with this router may be through the excellent memory of an engineer. But by expanding the amount of data collected through tickets, and using that data for reporting, an issue with this router may be viewable.
At first glance, this is a hardware issue and should be categorized as such. A detailed ticketing system would include subcategories for hardware.
- Hardware
- Chassis
- Juniper MX480
- PIC
- PB-4CHOC12-STM4-IQE-SFP
- PB-1CHOC48-STM16-IQE
- MIC
- MIC-3D-8OC3-2OC12-ATM
- MIC-3D-20GE-SFP
- Routing Engine
- RE-S-1800×2
- RE-S-X6-64G
- Other
- Fan tray
- Power supply
- PIC
- Juniper MX480
- Chassis
Looking at “Hardware,” we can determine the subcategories would include all active hardware in the network environment. This can be a daunting task. But it can be whittled down to hardware still under warranty, and use “Other” for devices not under warranty, or of a generic nature.
So, our newly created ticket states this is a hardware issue. And since the issue concerns the route engine, a new detail is added to the case. As the reporting period approaches, the manager/engineer putting the report together notices an increase in the number of cases involving this router. The fact that the tickets have the route engine in common points to a particular issue instead of multiple problems on a single device.
Acting proactively, a case can now be opened with the vendor. After examination of diagnostic information collected from the router, the vendor identifies a known bug in the router code and recommends an upgrade to a repaired version.
This ticket has just become a software issue.
The next step in our workflow just became apparent. The person doing the reporting needs to make sure the case-closure data is entered and categorized properly. This means reading all case notes and categorizing the case to reflect the actual problem. Turning to the Software list we might see:
- Software
- Code Version
- 2
- 6
- Code Version
Like the devices listed in the Hardware category, Code Versions active in the network need to be tracked as well. As a proactive step, all devices running the affected version of code can now be scheduled for upgrade.
Let’s look at another example.
Prioritization of cases gives the Help Desk engineers the ability to triage and manage their workload. A sample setup for priorities might be:
- Priority 1 – Outages
- Priority 2 – Issues requiring quick attention but not an outage
- Priority 3 – Requests for a hardware refresh or software install/upgrade
- Priority 4 – Information (user has a question or needs assistance)
Now let’s say a user opens a ticket asking for help with a printer problem. The user selects Priority 1 for his ticket. After investigation it is noted this is not an outage. Seeing this as a process issue the priority is modified to a P2 and assistance is provided.
Another ticket is opened by the same user concerning database access. Once again the ticket is opened as a P1. After talking to the user about proper prioritization, the ticket is lowered to a P2 and resolved.
Some users feel the only way to receive attention to their issues is to open them at the highest level possible. What they might not realize is that doing so sounds alarms, people drop the tasks they’re working on, or are jolted out of bed to respond to what should be a real, business-impacting problem.
When reporting time comes around, the number of each priority is generated, and the name of the user is attached to those cases. If multiple users are opening tickets at the wrong priority level, then training may be required. If it’s the same person, individual training or manager intervention may be appropriate. Either way, this becomes an example of reporting leading to proactive management because of trends in the collected data.
Report Creation
The big takeaway is that Help Desk data needs to be managed on a per-case basis and in a consistent manner for it to be meaningful. This massaging of data should be handled by as few hands as possible. Completing the resolution reporting, ensuring that all fields are filled in properly, and designing the schemas so they report information meaningful to the consumers of the report, are all very important.
It may take a few months to put everything together to produce the required output. Building workflows can be helpful for visualizing the way tickets are managed, and for identifying trends in the network as they occur. There’s no need to wait until reporting time to act on an observed trend. As a bonus, while compiling data, the manager will become more familiar with the network and its operations.
A report put into presentation form showing graphical representations of all numeric data is only part of the process. Each case needs to be reviewed for content and resolution. All fields need to be filled in and content must reflect the actual resolution of the case. Remember the hardware case that started out as a hardware issue and was actually a software issue. There are many instances where this will occur but won’t be seen unless all tickets are managed in the same manner.
How often reports are generated is up to management. Best practice might be to do a monthly report and follow up with a quarterly or biannual report. Monthly reporting helps to manage the workload involved in touching each case. All cases should be marked as reviewed and closed at the manager level.
The inclusion of quarterly or longer-term data is what builds the trends. How far back to go with trend data is up the Help Desk manager. Twelve months’ worth of data will obviously develop more exact trends, but it can also move the report backward instead of forward. The focus should be, “What are the trends telling us, and what can we do about them that can help with proactivity?”
Conclusion
Commitment to the success of the Help Desk and the support it provides rests in the hands of management and techs. It’s a true team effort that involves communication between all parties—from techs to end-users, from management to vendors.
Having a single point of truth in reporting allows for a snapshot of the network at any given moment in time. The ability to observe trends, and act on them, elevates the level of service provided to end-users. This in turn helps build trust in the abilities of the service team and creates an environment where users feel confident their issues will be resolved efficiently. The Help Desk should be the first stop for support, not the people you call when you can’t figure it out on your own.
If your company is looking to reorganize its Help Desk or utilize a third party to provide managed services, using collected data can increase the success of your customer service. From designing a new system, or redesigning an existing environment, the Help Desk can be built to provide a deeper understanding of problems in the network. Additionally, it can provide a step towards creating a proactive support system, instead of a reactive one. We at Anexinet would love to have a conversation with you about the best ways to maximize the efficiency of your own Help Desk, so please don’t hesitate to reach out to us with any questions.
Share on 
