The second of two posts focused on mining your help desk for gold. This post focuses on what features and functions you should look for in a ticketing system.
Now that the flow is down, we need to think about the features. Let's talk a little about what we don't need. We don't need a proprietary solution. We need something that uses normal scripting languages that one of your team can change or configure. A lot of the systems out there have such specialized code that you need to hire a consultant to make small changes. Get one that requires skill sets that you already have on your team. Now, with that out of the way...
- Asset Management: Really just a database table that allows you to enter information about a computer asset. There should be child tables or repositories as well for associating software licenses with the asset. In essence, you want to capture the PC with memory, CPU, warranty info, year purchased and OS. Also include model numbers and serial numbers for the PC and any peripheral over $150. That is just a guideline, but that is typically what your controller wants when they do their annual inventory. It's all about killing many birds with one stone and doing it right from the beginning lets you deal with these one of processes or requests with ease.
- Software License Management: There are smarter people than me that can understand the various licensing options for computer software. OEM or not to OEM? This is just a data store that allows you to capture all of the software licenses and associate the licenses with a particular PC and a user. The volume licensing from Microsoft is convenient, but you will have to judge the cost/benefit. A nice to have feature is one that can go out and discover what applications are on PC's. Even better would be a system that can monitor the PC for application changes, upgrades and additions. It can basically generate a punch-list to go to a user and collect the license
- Active Directory/LDAP Integration: It would be very helpful if the system can leverage the company directory and allow authentication tokens so you do not have to require separate logins. It also makes it easier to start filling in the Asset Management function.
- Issue capture: The web interface needs to be clean and simple with some enforcement rules on fields. I have tried to let the user select the priority in the past by using plain English summary descriptions, but I have had mixed results. Too many of the users would figure out the highest priority and always select that, but leading questions like application problems, access problems, phone problems, etc., all help narrow down the issue and allow the appropriate resource to be tasked with the issue. These come in handy if you are outsourcing some of your applications. At one company we outsourced a compliance application that had to be accessed by every employee once a year. We put the application name in one of the fields and if selected, the ticket alert would be sent to that company's help desk. The system must also take in email requests and associate inbound email addresses to customer records. The ticket number generated by the email must be used in the subject line for all future correspondence so we can keep the various communications associated with the right ticket. All in all, you want to encourage the use of the form as the main channel for submitting issues. Free form issue submission wastes time because it usually takes more than one round of communication to get at the true problem.
- Rules Engine: The system should have an overall rules engine that can be used for event triggers, escalation triggers and service level agreement creation and management. A somewhat generic rules engine is a lot more flexible than traditional procedural constraints. The good part about these rules engines is that they allow for cascading rule sets, dependent rule sets and array-based rule sets. But also note that this level of flexibility is also the bad news. It makes it much easier to shoot yourself in the foot and inadvertently generate Cartesian products in your ticketing database. Tie the triggers to your SLA and communicate your SLA whenever possible. This way, you are taking action according to the expectations you set with the user. Users will always believe that their issue has evaporated into the ether if you don't reach out when you told them you would reach out.
- Work Order: Many tickets may result in work orders and a work order may generate one or more trouble tickets. It is a vicious cycle, but necessary. Work orders are things that are dependent on timing issues outside the control of IT. Example would be waiting a week for a new laptop. Before a work order can be created, a definite deadline must be given as to when the work is going to be done in order to keep customer expectations in line.
- Categorization: Additionally, the ability to re-classify a ticket while keeping the original classification is necessary. I used "Training Issue" as a reclassification option. This denoted that the trouble ticket could have been prevented with some basic PC training. We then worked with HR to notify department heads that certain training may be needed by their employees. In one company, this resulted in HR and IT working together to bring online training courses to employees over our internal network. That way, if there was a training issue, the help desk can point the user in the direction of an online module on Excel Pivot Tables or something along those lines without offending anyone. Overtime, we learned what basic computer training needed to be completed by new employees and nearly eliminated "Training Issue" reclassifications.
- Survey Tool: This is a nice to have especially if your help desk team is being evaluated on customer satisfaction. If your system is flexible enough with a rules engine, you can trigger an email when you close a ticket that includes a link to a simple survey web form. Actually following up with a ticket after it is closed is always a good idea. There have been many times where the help desk tech thought an issue was closed but the user did not. This helps bridge that communication/understanding gap.
- Reporting: This is the bread and butter of the system. This is where you determine the IT project low hanging fruit and see how well you are performing to your internal customers' expectations. If they are not aligned, then some changes need to be made, but the only way to know is to see these in reports. Beware of complex reporting package add-ons. You may need consulting resources to get these off the ground. When creating the reports, remember what you are trying to measure:
- Number of tickets by classification: Determine projects to reduce number of ticket
- Number of tickets within SLA: Are you staffed appropriately? Are there outliers that impacted performance? How can you avoid surprises in the future
- Average ticket resolution time by classification: Do you have the right people taking care of the right issues
- Average work order completion time: How many tickets resulted in work orders? If this number is too high, you may have to make sure that tickets aren't being converted to work orders to make the SLA compliance numbers look better. If these work orders are too long, what can you anticipate in the future to avoid having to create a work order? Example would be a one shot, 33% annual refresh on PCs and laptops instead of handling one of new PC requests
- Number of tickets by user: Are there training opportunities? Is this a power user you can leverage
- Number of tickets by department: What department are you working for the most? Can a new system help alleviate new trouble ticket submissions
- Per ticket cost data: Great metric to include in a business case for a project that will address some root causes and eliminate trouble tickets.
- Asset inventory for finance: Annual asset report.
So with your ticketing system in place, the rest is up to you. Look for the low hanging fruit. A number of network outages may require a network re-design. A ton of printer issues may require a creative outsourced solution. Always look for ways to address the largest number of tickets in order to be proactive.